У AmneziaWG произошёл довольно интересный сдвиг. Ранние версии в основном старались убрать очевидные признаки WireGuard: меняли заголовки, размеры служебных пакетов, добавляли мусор перед рукопожатием. В третьей ветке разработчики пошли дальше и начали менять уже не отдельную сигнатуру, а статистический портрет соединения. Размеры, интервалы между служебными событиями, количество попыток рукопожатия и некоторые метаданные перестают выглядеть одинаково от сессии к сессии.
Я посмотрел документацию Amnezia, исходный код amneziawg-go, утилиты конфигурации и свежие сообщения об ошибках. Главный вывод получился таким. AmneziaWG 3.1 действительно закрывает несколько неприятных способов распознавания WireGuard-подобного трафика, но формулировки про защиту от «поведенческого ИИ-анализа» я бы воспринимал как описание цели разработки, а не как доказанную неуязвимость. Публичного независимого теста, где AmneziaWG 3.1 прогнали против современных классификаторов DPI и показали измеримый процент обнаружения, пока нет.
Версии тоже легко перепутать. Базовые нововведения третьего поколения появились в AmneziaWG 3.0, а актуальная ветка получила номер 3.1 и добавила ещё два механизма. Поэтому дальше под «AmneziaWG 3» я имею в виду всю третью ветку, отдельно указывая, какие функции появились именно в 3.1.
Материал предназначен для легального и ответственного использования сетевых технологий. Учитывайте законодательство своей страны, включая российское. Не применяйте инструкции для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода ограничений.
Почему WireGuard вообще приходится маскировать
Сам WireGuard проектировали не для борьбы с DPI. Протокол получился быстрым, компактным и криптографически аккуратным, но одновременно довольно узнаваемым снаружи. У разных типов служебных сообщений фиксированная структура, а стандартные пакеты рукопожатия имеют характерные размеры. Классический Initiation занимает 148 байт, Response 92 байта, Cookie Reply 64 байта.
Для фильтра необязательно расшифровывать содержимое. Достаточно заметить последовательность UDP-пакетов определённых размеров и интервалов. Более продвинутый анализ добавляет направление пакетов, частоту повторных рукопожатий, keepalive, длительность сессии и реакцию сервера на специально сформированные запросы.
AmneziaWG развивался именно вокруг этой проблемы. В ранних версиях появились параметры Jc, Jmin и Jmax, которые отправляют перед рукопожатием мусорные UDP-пакеты, а S1 и S2 меняли длину двух основных handshake-сообщений. Параметры H1-H4 заменили стандартные идентификаторы типов сообщений.
В AmneziaWG 2.0 разработчики расширили подход. Заголовки H1-H4 стали задаваться диапазонами, появились S3 и S4 для Cookie Reply и транспортных пакетов, а механизм I1-I5 позволил отправлять перед рукопожатием специально построенные пакеты. Я уже подробно разбирал AmneziaWG 2.0, где протокол начал двигаться от простой обфускации к управляемой мимикрии.
| Версия | Что меняется | Против какого анализа помогает |
|---|---|---|
| WireGuard | Стандартные заголовки и тайминги | Маскировки нет |
| AmneziaWG 1.x | Мусорные пакеты, padding, другие типы сообщений | Простые сигнатуры |
| AmneziaWG 2.0 | Диапазоны H1-H4, S1-S4, цепочки I1-I5 | Сигнатуры и часть эвристического анализа |
| AmneziaWG 3.0 | Защита заголовков, дополнительный padding, случайные тайминги | Статистический профиль соединения |
| AmneziaWG 3.1 | Случайные хвосты пакетов и отключение Cookie Reply | Анализ размеров и активное зондирование |
Что именно появилось в AmneziaWG 3
Самая технически интересная функция третьей версии называется HeaderProtectionKey. Раньше AmneziaWG мог заменить стандартный четырёхбайтовый идентификатор пакета случайным значением из диапазона, но остальная структура WireGuard оставалась удобной для статистического анализа. Теперь протокол использует отдельный 32-байтовый ключ защиты заголовка.
В исходном коде механизм реализован поверх быстрого потокового шифрования. Случайные байты из S1-S4 участвуют в формировании одноразового значения для операции над заголовком. Для включённой защиты каждый из параметров S1, S2, S3 и S4 должен составлять не меньше 12 байт. Сервер и клиент должны знать одинаковый HeaderProtectionKey.
Здесь есть тонкость. HeaderProtectionKey не заменяет криптографию WireGuard и не делает пользовательские данные «сильнее зашифрованными». Payload по-прежнему защищает штатная криптография WireGuard с Curve25519 и ChaCha20-Poly1305. Новый ключ закрывает внешний низкоэнтропийный сетевой заголовок, который раньше помогал классифицировать протокол.
В конфигурации третьей версии появились параметры примерно такого класса:
HeaderProtectionKey = ...
ContentPaddingAddition = 10-100
RekeyAfterTime = ...
RekeyTimeout = ...
RejectAfterTime = ...
KeepaliveTimeout = ...
MaxHandshakeAttempts = ...
PersistentKeepalive = 20-30ContentPaddingAddition добавляет случайное количество заполнителя к содержимому. Вместо стабильного правила размера администратор задаёт диапазон, а конкретное значение меняется. Тем самым уменьшается количество повторяющихся размеров UDP-датаграмм.
Ещё интереснее набор параметров времени. Оригинальный WireGuard содержит довольно узнаваемые константы для обновления ключей, повторных попыток рукопожатия, keepalive и прекращения работы старой сессии. AmneziaWG 3 разрешает задавать интервалы диапазонами. Конкретный момент события выбирается внутри диапазона, поэтому две сессии одного клиента уже не обязаны повторять одинаковый ритм.
Именно здесь появляется реальное основание говорить про борьбу с поведенческим анализом. Классификатор может игнорировать содержимое пакетов и изучать временной ряд вида «клиент отправил пакет, через столько-то миллисекунд получил ответ, через столько-то секунд повторил handshake». Если тайминги жёстко зашиты в протокол, последовательность становится хорошим признаком. AmneziaWG 3 снижает стабильность такого признака.
Но фраза «защищает от поведенческого ИИ-анализа» звучит сильнее, чем позволяют утверждать имеющиеся данные. Машинному классификатору никто не мешает учитывать сотни других характеристик, включая распределение длин пакетов, соотношение входящего и исходящего трафика, длительность соединений, сетевую автономную систему сервера и корреляцию потоков. Amnezia усложняет классификацию, но не доказывает невозможность классификации.
Что добавила именно версия 3.1
В AmneziaWG 3.1 появились ещё две настройки, RandomTrailers и DisableCookies.
RandomTrailers решает довольно неприятную проблему фиксированной длины handshake-пакетов. Даже после S1-S4 определённая конфигурация могла снова и снова производить одинаковый размер. Случайный дополнительный хвост делает длину менее предсказуемой. Для наблюдателя пропадает ещё одна удобная «линейка», по которой можно группировать подключения.
DisableCookies позволяет отказаться от отправки WireGuard Cookie Reply. В WireGuard cookie-механизм служит частью защиты сервера от перегрузки и DoS во время большого числа рукопожатий. С точки зрения DPI у Cookie Reply есть неприятное свойство: удалённый наблюдатель может пытаться вызвать характерную реакцию сервера и использовать ответ для распознавания протокола.
Отключение Cookie Reply убирает такой сетевой маркер, но появляется компромисс. Вместе с маркером отключается один из штатных механизмов противодействия handshake-flood. Поэтому DisableCookies нельзя считать безусловным улучшением безопасности. Параметр улучшает скрытность ценой части защиты от перегрузки.
Отдельно я бы поправил формулировку про «расширенный набор параметров для рандомизации pre-shared key». В публичной конфигурации обычный PresharedKey по-прежнему существует как стандартный ключ WireGuard. Новая заметная сущность третьей ветки называется HeaderProtectionKey. Поэтому смешивать два ключа не стоит. Один относится к криптографической схеме WireGuard, второй нужен для маскировки внешней структуры пакетов.
Почему новая схема действительно сложнее для ТСПУ, но не делает VPN невидимым
Сильная сторона AmneziaWG 3.1 не в какой-то одной функции. Проблему DPI разработчики атакуют сразу по нескольким координатам.
- Содержимое заголовков. Предсказуемые поля дополнительно защищены.
- Размеры. S1-S4, дополнительный padding и случайные хвосты уменьшают повторяемость.
- Начало соединения. I1-I5 и мусорные пакеты усложняют поиск момента настоящего handshake.
- Время. Rekey, keepalive и повторные попытки можно рандомизировать.
- Активное зондирование. Отключение Cookie Reply сокращает число характерных ответов сервера.
Получается принципиально более неприятная цель для системы фильтрации. Простое правило «UDP-пакет такого размера плюс такой заголовок» быстро перестаёт работать. Даже классификатору приходится собирать более длинную историю соединения и комбинировать несколько слабых признаков.
Но я бы не повторял рекламную формулу «успешно обходит ТСПУ» как универсальный факт. ТСПУ могут ограничивать целые IP-подсети, конкретные дата-центры, UDP как класс, отдельные направления трафика или применять правила, вообще не зависящие от WireGuard-сигнатуры. При полном белом списке протоколу нечего маскировать, если соединение с произвольным VPS просто не разрешают.
Нельзя забывать и про IP-адрес сервера. Идеально замаскированный UDP не спасёт VPS, подсеть которого уже попала в блокировку. Прошлые сбои Amnezia хорошо показали, что устойчивость VPN складывается из протокола, серверной инфраструктуры, адресного пространства и способности быстро менять точки подключения.
Публикация TechRadar подтверждает интерес международных СМИ к новой архитектуре, но публикация СМИ не заменяет технический аудит. Я не нашёл открытого независимого исследования с набором сетевых трасс AmneziaWG 3.1, контрольной группой WireGuard и измеренной точностью нескольких DPI-классификаторов. Пока корректнее говорить «усложняет детектирование», а не «становится недетектируемым».
Обновление Self-hosted и неприятные ограничения
Для обычного пользователя Premium или Free переход почти незаметен. Актуальный AmneziaVPN использует AmneziaWG 3.1 по умолчанию. Для импортируемых конфигураций разработчики указывают AmneziaVPN 5.0.1.5 или новее, DefaultVPN 2.0.1.1 или новее и совместимые нативные клиенты.
С Self-hosted ситуация сложнее. Официальная инструкция предлагает обновить AmneziaVPN, удалить старый контейнер AmneziaWG и установить протокол заново. Новый контейнер уже разворачивается с 3.1. После переустановки приходится заново создавать пользователей и выдавать новые конфигурации.
Для домашнего сервера с двумя телефонами процедура терпимая. Если на VPS несколько десятков пользователей, обновление превращается в миграцию с потенциальным простоем. В GitHub уже есть запрос от владельцев Self-hosted на возможность держать контейнеры 2.0 и 3.1 параллельно и переводить пользователей постепенно.
Совместимость тоже требует внимания. Сам движок третьей версии способен работать со старыми конфигурациями, пока новые параметры выключены. Но конфигурация, где включены HeaderProtectionKey, RandomTrailers и другие изменения сетевого формата, требует поддержки соответствующей версии на обеих сторонах. Просто удалить незнакомые строки из файла 3.1 и импортировать его как 2.0 не получится.
С роутерами пока ещё менее удобно. В официальной документации Amnezia прямо сказано, что роутерные системы пока не поддерживают AmneziaWG 3.1 нативно, поэтому Premium-конфигурацию нельзя просто загрузить в обычный OpenWrt или Keenetic как старый профиль. Одновременно уже появились сторонние сборки для OpenWrt с поддержкой 3.1. Получается типичная ситуация нового протокола: исходный код уже существует, а экосистема догоняет его неравномерно.
Есть и обычные болезни свежего релиза. В GitHub появились сообщения о проблемах на Windows, включая случаи, когда handshake проходит, но транспортный трафик дальше не работает. Другие пользователи сообщали о неудачном обновлении Self-hosted и несовместимости отдельных способов импорта конфигураций. Такие issue не доказывают системную поломку AmneziaWG 3.1, но я бы пока не удалял рабочий резервный профиль перед проверкой новой версии на каждом нужном устройстве.
Проверять результат лучше не по зелёной кнопке «Подключено». После обновления надо убедиться, что открываются сайты, изменился внешний IP, работают DNS-запросы, нет внезапных обрывов через несколько минут, а передача данных идёт в обе стороны. Для Self-hosted дополнительно полезно сохранить старую конфигурацию и заранее продумать способ отката.
В итоге AmneziaWG 3.1 выглядит не косметическим обновлением WireGuard и даже не просто очередной обфускацией. Разработчики перешли к изменению поведения всего сетевого потока. Заголовок, размер, последовательность и время пакетов теперь можно сделать менее детерминированными, а сервер выдаёт меньше характерных ответов на зондирование. Для сигнатурных и статистических фильтров задача действительно становится сложнее.
Но инженерная гонка на AmneziaWG 3.1 не заканчивается. Протокол остаётся UDP-туннелем к конкретному серверу, а наблюдатель может анализировать инфраструктуру, адреса, корреляцию трафика и новые статистические признаки. Поэтому я бы оценивал третью версию как серьёзное усиление AmneziaWG, но не как «последний протокол, который больше невозможно заблокировать». Как раз сама команда Amnezia в документации уже пишет, что тестирует новые методы и готовит ещё более устойчивые варианты. В нынешней сетевой реальности такая осторожность звучит убедительнее любых обещаний полной невидимости.
Чем AmneziaWG 3.1 отличается от AmneziaWG 3.0?
AmneziaWG 3.0 добавил HeaderProtectionKey, дополнительный padding и настраиваемые диапазоны таймингов. Версия 3.1 дополнила схему параметрами RandomTrailers и DisableCookies, которые уменьшают предсказуемость размеров служебных пакетов и убирают характерные Cookie Reply.
AmneziaWG 3.1 полностью скрывает VPN от DPI?
Нет. Протокол убирает и рандомизирует много признаков, используемых DPI, но наблюдатель может применять статистический анализ, репутацию IP-адреса, характеристики потока и другие методы. Публичного независимого доказательства полной недетектируемости нет.
AmneziaWG 3.1 быстрее обычного WireGuard?
Главная задача AmneziaWG 3.1 не рост скорости, а устойчивость к распознаванию. Криптографическое ядро WireGuard сохранено, но маскировка добавляет служебные байты и пакеты. Реальная скорость зависит от сервера, сети, маршрута и конкретной реализации.
Можно ли использовать конфигурацию AmneziaWG 3.1 в клиенте AmneziaWG 2.0?
Полноценную конфигурацию 3.1 использовать нельзя. Новые параметры меняют формат трафика и должны поддерживаться обеими сторонами. Удаление строк 3.1 из готового профиля не превращает его автоматически в рабочую конфигурацию 2.0.
Нужно ли обновлять Self-hosted с AmneziaWG 2.0?
Если 2.0 работает стабильно, срочность зависит от условий конкретной сети. Amnezia рекомендует переходить на 3.1. Перед миграцией нужно учитывать, что официальный сценарий переустанавливает контейнер и требует заново выдать пользовательские конфигурации.
