AWG 2.0 VPN: что это, как работает и почему он обходит DPI там, где WireGuard бессилен

Разбираем AmneziaWG 2.0: динамические заголовки, случайный padding, мимикрию под DNS и QUIC, сравнение с WireGuard и OpenVPN, установку на свой сервер и ответы на частые вопросы.

Что такое AWG 2.0 и зачем он нужен

AmneziaWG 2.0 (сокращённо AWG 2.0) — это форк протокола WireGuard, разработанный командой Amnezia VPN. Первая версия появилась в 2023 году, а вторая стала ответом на ужесточение интернет-цензуры и развитие систем глубокого анализа трафика (DPI).

WireGuard — один из самых быстрых и безопасных VPN-протоколов: он использует проверенную криптографию (Curve25519, ChaCha20-Poly1305), работает в ядре операционной системы и потребляет мало ресурсов. Однако у него есть критический недостаток: его трафик легко идентифицировать. Каждый пакет WireGuard начинается с фиксированного 4-байтового заголовка, а размеры handshake-пакетов всегда одинаковы (148 и 92 байта). DPI-системы используют эти признаки для мгновенной блокировки.

AWG 2.0 сохраняет криптографическое ядро WireGuard, но полностью меняет транспортный уровень. Вместо фиксированных заголовков — случайные значения из диапазонов, вместо предсказуемых размеров пакетов — случайный padding, а перед handshake отправляются «декоративные» пакеты, имитирующие легитимные протоколы. В результате трафик AWG 2.0 не имеет единого сигнатура, по которой DPI мог бы его заблокировать.

Протокол уже поддерживается в клиенте AmneziaVPN для десктопов и Android (начиная с версии 4.8.12.9). Пользователям Free и Premium версий пока доступна AWG 1.5, но поддержка 2.0 планируется позже. Для self-hosted пользователей всё работает уже сейчас.

Почему WireGuard легко блокируется DPI

Системы DPI (Deep Packet Inspection) анализируют не только IP-адреса, но и содержимое пакетов. Для WireGuard существует простой эвристический алгоритм: UDP-пакет + известное значение заголовка (1–4) + предсказуемый размер = WireGuard.

Handshake Initiation всегда имеет размер 148 байт, Handshake Response — 92 байта. Эти инвариантные размеры — настоящая находка для цензоров. DPI-боксы, установленные у провайдеров, могут мгновенно пометить такое соединение и заблокировать его, задушить скорость или просто «молча» отбрасывать пакеты.

В России, например, с середины 2025 года стандартный WireGuard практически перестал работать: TSPU (технические средства противодействия угрозам) научились распознавать его и блокировать на уровне каждого крупного провайдера. Пользователи замечали, что handshake просто не завершается — без ошибок и таймаутов, пакеты исчезают бесследно.

Аналогичная ситуация в Иране (потери пакетов до 98%), Китае (блокировка в считанные секунды), а также в Египте, Туркменистане, Мьянме, Пакистане, ОАЭ, Турции, Беларуси, Узбекистане и Казахстане. Даже если WireGuard не блокируется полностью, его часто троттлят (искусственно замедляют).

Именно поэтому возникает потребность в протоколах с обфускацией, которые маскируют VPN-трафик под что-то другое.

Как AWG 2.0 обходит DPI: динамические заголовки

В стандартном WireGuard каждый пакет начинается с 4-байтового идентификатора типа: 1 — handshake initiation, 2 — handshake response, 3 — cookie reply, 4 — transport data. Эти значения фиксированы, и DPI легко их запоминает.

AWG 1.0 позволял заменить их на свои фиксированные значения через параметры H1–H4. Но это лишь временное решение: DPI может выучить и новые константы.

AWG 2.0 пошёл дальше — заголовки теперь выбираются случайно из заданных диапазонов. Например:

  • H1 = 471800590–471800690 (101 возможный вариант для handshake init)
  • H2 = 1246894907–1246895000
  • H3 = 923637689–923637690
  • H4 = 1769581055–1869581055 (100 миллионов вариантов для data-пакетов)

При отправке каждый пакет получает случайное значение из своего диапазона, при приёме — принимается любое значение из настроенного диапазона. В результате каждый пакет выглядит уникальным, и DPI не может найти постоянный паттерн.

Важное ограничение: диапазоны H1–H4 не должны пересекаться, иначе протокол не сможет отличить один тип пакета от другого. Например, если H1 = 1000–2000, а H2 = 1500–2500, то пакет с заголовком 1700 может быть интерпретирован и как handshake, и как response — это приведёт к ошибкам соединения.

Случайный padding: S1–S4

Помимо заголовков, DPI анализирует размеры пакетов. Стандартный WireGuard имеет фиксированные размеры для handshake-пакетов, что является надёжным признаком.

AWG 1.0 позволял изменять размеры только handshake-пакетов через параметры S1 и S2. Но handshake происходит раз в две минуты, а основной трафик — это data-пакеты, которые оставались предсказуемыми.

AWG 2.0 добавляет padding для всех типов пакетов:

  • S1 — padding для handshake init (было в 1.0)
  • S2 — padding для handshake response (было в 1.0)
  • S3 — padding для cookie reply (новое в 2.0). Cookie reply — это пакет, который сервер отправляет при защите от DoS-атак. Его стандартный размер ровно 64 байта, что является отличным индикатором для DPI. S3 добавляет случайные байты к этому пакету.
  • S4 — padding для каждого transport data пакета (новое в 2.0). Это самое важное нововведение: теперь каждый пакет с данными получает случайное количество «мусорных» байт, что делает размеры пакетов непредсказуемыми.

Пример конфигурации: S1 = 68, S2 = 149, S3 = 32, S4 = 16.

Есть один нюанс: S1 + 56 не должно равняться S2. Почему? Потому что разница между стандартными размерами handshake init и response составляет 56 байт (148 – 92). Если padding подобран так, что размеры совпадут, DPI снова получит паттерн.

Signature packets (i1–i5): мимикрия под легитимные протоколы

Самое значительное нововведение AWG 2.0 — это signature packets. Перед каждым настоящим WireGuard handshake клиент отправляет до пяти специальных пакетов, которые имитируют начало легитимного протокола: DNS-запроса, QUIC-соединения, SIP-звонка и т.п.

Как это работает:

  1. Клиент отправляет пакет, который выглядит как начало DNS-запроса.
  2. DPI видит «DNS» и пропускает.
  3. Затем клиент отправляет ещё несколько таких «декоративных» пакетов.
  4. После них идёт настоящий handshake AWG 2.0, уже обфусцированный.

Параметры i1–i5 определяют содержимое этих пакетов с помощью языка CPS (Custom Protocol Signature). Если i1 не настроен, signature packets не отправляются — это обеспечивает обратную совместимость с AWG 1.0.

CPS использует теги для описания структуры пакета:

  • ** — вставляет точные байты (например, магические байты протокола)
  • `` — N случайных байт
  • `` — N случайных буквенно-цифровых символов [A-Za-z0-9]
  • `` — N случайных цифр [0-9]
  • `` — текущая UNIX-метка времени (4 байта)
  • `` — счётчик пакетов (4 байта)

Пример сигнатуры QUIC:

i1 = **

Здесь ** — начало QUIC Initial packet (0xc7 — тип, 0x00000001 — версия QUIC v1), ` — 8 случайных символов для Connection ID, — временная метка, ` — 50 случайных байт payload. DPI видит характерные байты QUIC и классифицирует трафик как легитимный HTTP/3.

Junk packets и полный порядок отправки пакетов

Ещё один механизм обфускации — junk packets (мусорные пакеты). Перед каждым handshake клиент отправляет Jc пакетов со случайными размерами в диапазоне от Jmin до Jmax. Это создаёт дополнительный «шум», который затрудняет анализ паттернов соединения.

Полный порядок отправки пакетов при установке соединения в AWG 2.0 выглядит так:

  1. Signature packets i1 → i2 → i3 → i4 → i5 (если настроены)
  2. Junk packets × Jc (всегда)
  3. Handshake Initiation: [S1 padding | H1(random) 4 bytes | 144 байта]
  4. Handshake Response: [S2 padding | H2(random) 4 bytes | 88 байт]
  5. При нагрузке на сервер: Cookie Reply: [S3 padding | H3(random) 4 bytes | 60 байт]
  6. Все data-пакеты: [S4 padding | H4(random) 4 bytes | payload]

Ключевые моменты:

  • Signature packets отправляются только если настроены i1–i5.
  • Junk packets отправляются всегда перед handshake.
  • S1/S2 применяются к handshake-пакетам.
  • S3 применяется к cookie reply (редко, только под нагрузкой).
  • S4 применяется к каждому data-пакету — это основной трафик.
  • H1–H4 с диапазонами делают каждый пакет уникальным.

Такая многоуровневая обфускация делает трафик AWG 2.0 практически неотличимым от случайного UDP-трафика или легитимных протоколов.

Сравнение AWG 2.0 с WireGuard, OpenVPN и другими решениями

Чтобы понять место AWG 2.0 среди VPN-протоколов, полезно сравнить его с альтернативами.

WireGuard — самый быстрый и простой, но не имеет защиты от DPI. В странах с цензурой он просто не работает.

OpenVPN + obfs4 — медленный (обфускация добавляет ~10% оверхэда, общий оверхэд ~25–28%), но имеет среднюю DPI-стойкость. Работает в пользовательском пространстве, что снижает производительность.

Shadowsocks — прокси, а не полноценный VPN-туннель. Имеет низкую DPI-стойкость, легко детектируется.

VLESS+Reality — очень высокая DPI-стойкость, но это тоже прокси, а не VPN. Не обеспечивает полную туннельную маршрутизацию.

AWG 2.0 — занимает промежуточное положение: высокая DPI-стойкость (благодаря мимикрии), скорость почти как у WireGuard (оверхэд <12% в теории, ~3% на практике), работает в ядре (через DKMS), является полноценным VPN-туннелем.

Сравнительная таблица:

| Протокол | DPI-стойкость | Скорость | Оверхэд | Полный туннель | Работа в ядре | |---|---|---|---|---|---| | WireGuard | Нет | Очень высокая | ~4% | Да | Да | | AWG 2.0 | Высокая | Высокая | <12% | Да | Да | | OpenVPN+obfs4 | Средняя | Низкая | ~25–28% | Да | Нет | | Shadowsocks | Низкая | Средняя | Средний | Нет (прокси) | Нет | | VLESS+Reality | Очень высокая | Средне-высокая | Средний | Нет (прокси) | Нет |

Важно понимать: если WireGuard в вашей стране не блокируется, нет смысла переходить на AWG 2.0 — он лишь добавляет оверхэд. Но если WireGuard мёртв, AWG 2.0 — это разница между 92 Мбит/с и 0 Мбит/с.

Как развернуть AWG 2.0 на своём сервере

Установка AWG 2.0 вручную — задача нетривиальная: нужно собрать модуль ядра, сгенерировать 10+ параметров обфускации с учётом ограничений, настроить firewall и т.д. К счастью, существует автоматизированный установщик amneziawg-installer.

Требования:

  • Чистый сервер на Ubuntu 24.04/25.10 или Debian 12/13
  • Root-доступ по SSH
  • ~1 ГБ RAM (подойдёт любой VPS за $2–4 в месяц)

Установка:

wget -O install_amneziawg_en.sh https://raw.githubusercontent.com/bivlked/amneziawg-installer/main/install_amneziawg_en.sh
chmod +x install_amneziawg_en.sh
sudo bash ./install_amneziawg_en.sh

Скрипт выполняет 8 шагов:

  1. Системная оптимизация (удаление лишних пакетов, настройка BBR, swap)
  2. Сборка модуля ядра AWG через DKMS (из PPA Amnezia)
  3. Настройка firewall (UFW, deny-all по умолчанию, rate-limiting SSH)
  4. Генерация всех параметров AWG 2.0 с корректными ограничениями
  5. Создание конфигураций сервера и клиентов, QR-кодов
  6. Запуск сервисов (Fail2Ban, awg-quick@awg0)

В процессе установки будет две перезагрузки (для обновления ядра и загрузки модуля). Скрипт сохраняет состояние, поэтому после каждой перезагрузки нужно просто запустить его снова.

Управление клиентами:

# Добавить клиента
sudo bash /root/awg/manage_amneziawg.sh add my_phone

# Список клиентов
sudo bash /root/awg/manage_amneziawg.sh list

# Удалить клиента
sudo bash /root/awg/manage_amneziawg.sh remove my_phone

# Временный клиент на 7 дней
sudo bash /root/awg/manage_amneziawg.sh add guest --expires=7d

# Статистика трафика
sudo bash /root/awg/manage_amneziawg.sh stats

# Бэкап конфигов
sudo bash /root/awg/manage_amneziawg.sh backup

Подключение клиентов: используйте AmneziaVPN (>= 4.8.12.7) или AmneziaWG (>= 2.0.0) для Windows, а также VeilBox для Windows/macOS.

Производительность и реальные результаты

Один из главных вопросов — не снижает ли обфускация скорость. В сети можно встретить цифру «65% оверхэда», но она относится к пользовательской реализации на Go (amneziawg-go), а не к самому протоколу. При использовании модуля ядра (через DKMS) оверхэд минимален.

Сравнение на реальном тесте (без цензуры):

  • WireGuard: 95 Мбит/с
  • AWG 2.0: 92 Мбит/с

Разница всего 3% — практически незаметна. В условиях цензуры сравнение выглядит иначе: 92 Мбит/с против 0 Мбит/с (если WireGuard заблокирован).

Энергопотребление тоже сопоставимо: при 4 часах стриминга AWG 2.0 расходует на 1% больше батареи, чем WireGuard (19% против 18%), тогда как OpenVPN — около 25%.

Криптографическая безопасность не изменилась: используются те же алгоритмы (Curve25519, ChaCha20-Poly1305), что и в WireGuard, поэтому все аудиты WireGuard применимы и к AWG 2.0.

Полевые испытания показывают, что AWG 2.0 успешно работает в России, где TSPU блокирует стандартный WireGuard с середины 2025 года. Однако в некоторых случаях, когда блокировка идёт на уровне AS (например, Hetzner AS24940), может потребоваться настройка I1 для имитации QUIC с allowlisted SNI. Это операторо-зависимо, поэтому возможен метод проб и ошибок.

Ограничения и важные замечания

Несмотря на все преимущества, у AWG 2.0 есть ограничения, о которых стоит знать.

Диапазоны H1–H4 не должны пересекаться. Это критично для корректной работы протокола. Если диапазоны пересекаются, пакеты могут быть неправильно интерпретированы.

S1 + 56 ≠ S2. Если padding подобран так, что размеры handshake init и response совпадают, DPI снова получает паттерн.

Signature packets не гарантируют 100% обход. Если DPI настроен на блокировку конкретного протокола (например, QUIC), имитация QUIC может не помочь. В некоторых случаях требуется подбор SNI.

Скорость зависит от реализации. Пользовательская реализация на Go (amneziawg-go) значительно медленнее модуля ядра. Установщик использует DKMS, поэтому скорость близка к WireGuard.

Поддержка в клиентах. Для работы с AWG 2.0 нужны клиенты с поддержкой этого протокола. AmneziaVPN для self-hosted уже поддерживает, но Free/Premium версии пока используют AWG 1.5.

Юридические аспекты. Использование VPN для обхода блокировок может быть запрещено в некоторых странах. Перед использованием убедитесь в соответствии с местным законодательством.

Не является панацеей. Если DPI-система анализирует статистические характеристики трафика (временные интервалы, объёмы), даже AWG 2.0 может быть обнаружен. Однако на данный момент это один из самых эффективных инструментов против DPI.

Вопросы и ответы

Чем AWG 2.0 отличается от обычного WireGuard?

AWG 2.0 — это форк WireGuard с изменённым транспортным уровнем. Криптография осталась той же (Curve25519, ChaCha20-Poly1305), но заголовки пакетов теперь выбираются случайно из диапазонов, добавляется случайный padding ко всем типам пакетов (включая data), а перед handshake отправляются signature-пакеты, имитирующие легитимные протоколы. В результате трафик AWG 2.0 не имеет постоянных сигнатур, по которым DPI мог бы его заблокировать.

Насколько AWG 2.0 медленнее WireGuard?

При использовании модуля ядра (DKMS) оверхэд составляет менее 12% в теории и около 3% на практике. В реальном тесте на некцензурированной сети WireGuard показал 95 Мбит/с, а AWG 2.0 — 92 Мбит/с. Разница практически незаметна. Пользовательская реализация на Go (amneziawg-go) значительно медленнее, поэтому рекомендуется использовать модуль ядра.

Какие клиенты поддерживают AWG 2.0?

AWG 2.0 поддерживается в клиенте AmneziaVPN для десктопов и Android (начиная с версии 4.8.12.9) для self-hosted пользователей. Также есть лёгкий менеджер туннелей AmneziaWG для Windows (>= 2.0.0) и open-source клиент VeilBox для Windows/macOS. Пользователи Free и Premium версий AmneziaVPN пока используют AWG 1.5, поддержка 2.0 будет добавлена позже.

Можно ли использовать AWG 2.0 на обычном VPS за $2–4?

Да, для работы AWG 2.0 достаточно ~1 ГБ RAM и чистого сервера на Ubuntu 24.04/25.10 или Debian 12/13. Установщик amneziawg-installer автоматизирует процесс: сборку модуля ядра, настройку firewall, генерацию параметров и конфигураций. Подойдёт любой недорогой VPS.

Что такое CPS (Custom Protocol Signature) в AWG 2.0?

CPS — это язык описания signature-пакетов (i1–i5), которые отправляются перед handshake и имитируют легитимные протоколы. Он использует теги: ** для вставки точных байт, ` для случайных байт, для случайных буквенно-цифровых символов, для случайных цифр, для временной метки. Например, сигнатура QUIC выглядит как **`.

Поможет ли AWG 2.0, если DPI блокирует весь UDP-трафик?

AWG 2.0 работает поверх UDP, поэтому если DPI блокирует весь UDP без исключений, протокол не поможет. Однако в большинстве случаев DPI блокирует только известные сигнатуры, а не весь UDP, так как это нарушило бы работу DNS, QUIC и других легитимных сервисов. Signature-пакеты позволяют замаскировать трафик под DNS или QUIC, что обычно проходит фильтрацию.