WireGuard довольно быстро стал популярным VPN-протоколом: простой, быстрый, с аккуратной архитектурой и без тяжёлого наследия, он выгодно выделялся на фоне монстров вроде IPsec и OpenVPN. Но, как это часто бывает, сильная сторона со временем стала и слабым местом. Протокол оказался не только удобным и предсказуемым, но и легко узнаваемым, а значит и сравнительно простым для блокировки.
Как только WireGuard начали пытаться блокировать, появились и первые попытки его спрятать. Сначала это были довольно простые приёмы, например, добавить перед хендшейком несколько мусорных UDP-пакетов, чтобы сбить DPI в начале сессии. Потом появилась AmneziaWG, которая пошла дальше и стала менять уже сам внешний вид WireGuard-пакетов: заголовки, размеры, дополнительные junk-данные внутри хендшейка. В AmneziaWG 2.0 пространства для манёвра стало ещё больше: к уже существовавшим S1–S2 добавились S3–S4, и управляемые вставки стало возможно применять не только к хендшейку, но и к другим типам сообщений, включая основной поток данных. Параллельно развивалась и идея имитационных пакетов: перед хендшейком можно было отправлять не просто случайный мусор, а пакеты, похожие на трафик другого протокола, чтобы сбить первичную классификацию.
В этой статье речь пойдёт о следующем шаге в развитии этой идеи. Если раньше имитационные пакеты работали в основном как короткая дымовая завеса перед хендшейком, то теперь имитация переносится в сам поток: транспортные пакеты AmneziaWG на проводе начинают выглядеть как QUIC, DNS, STUN или SIP.
«Простота хуже воровства»
Когда говорят, что DPI узнаёт WireGuard, легко представить себе что-то почти магическое: умная коробка где-то у провайдера вскрывает пакеты, анализирует содержимое, строит сложные модели и только потом выносит вердикт. На практике всё часто проще.
У WireGuard есть фиксированные типы сообщений, предсказуемые размеры начальных пакетов, характерный порядок обмена в начале сессии. Handshake Initiation, затем Handshake Response, потом транспортные данные. Всё это летит поверх UDP, и первые пакеты соединения выглядят достаточно узнаваемо.
Для DPI это удобная ситуация. Достаточно посмотреть на внешние признаки: размер пакетов, порядок, первые байты, поведение UDP-сессии. Если они складываются в знакомую картину, поток можно пометить как WireGuard. А дальше с ним уже можно делать всё что угодно: блокировать, замедлять, рвать после хендшейка или просто отправлять в отдельную категорию для дальнейшего анализа.
В этом смысле WireGuard слишком «честно» представляется. Он аккуратный, минималистичный и предсказуемый. Для протокола это достоинство, но в сетях с агрессивной фильтрацией такая предсказуемость превращается в серьёзный недостаток.
«За деревьями леса не видеть»
Первая идея была простой: если DPI ловит WireGuard по характерному началу сессии, нужно сделать так, чтобы это начало перестало быть таким заметным.
Перед настоящим хендшейком клиент отправляет несколько UDP-пакетов со случайными данными. Они не несут никакой смысловой нагрузки, а просто создают шумовой фон. В результате Handshake Initiation уже не появляется первым пакетом в пустом потоке, а теряется среди других датаграмм.
На серьёзную стеганографическую защиту это, конечно, не похоже. Но сама идея важная: клиент больше не просто надеется, что DPI его не узнает, а начинает сам формировать картину, которую увидит наблюдатель.
Против простых фильтров такой подход действительно может работать. Особенно если блокировка завязана на первые пакеты UDP-сессии. Увидели Handshake Initiation на чистом месте, пометили поток как WireGuard и заблокировали. Не увидели, значит у соединения есть шанс пройти дальше.
Но у случайного шума есть понятный предел. Если перед VPN-сессией внезапно появляется набор пакетов со случайным содержимым, это тоже становится признаком. Да, это уже не чистый WireGuard. Но это и не нормальный прикладной протокол. Обычные протоколы редко начинают разговор с бессмысленного набора байтов без какой-либо структуры.
Шум может сбить с толку простой классификатор, но сам по себе он не делает трафик похожим на что-то разрешённое. Он скорее говорит: «я не WireGuard, я просто что-то странное». А в сетях с жёсткой фильтрацией «что-то странное» тоже не самая удачная маска.
AmneziaWG: стереть отпечатки WireGuard
Следующим заметным шагом стала AmneziaWG. Если первые попытки маскировки прятали WireGuard за шумом перед сессией, то AmneziaWG пошла глубже и начала менять уже сам внешний вид пакетов.
Идея простая: если DPI узнаёт протокол по характерным признакам, нужно сделать эти признаки менее стабильными. Поэтому AmneziaWG может добавлять junk-пакеты перед хендшейком, менять значения заголовков типов сообщений и добавлять дополнительные данные внутрь хендшейка, чтобы он не выделялся привычным размером.
В результате маскируется уже не только начало сессии, но и сами пакеты, по которым раньше было удобно определять WireGuard. DPI больше не видит эталонный хендшейк: размеры меняются, типы пакетов выглядят иначе, сигнатуры размываются.
На практике self-hosted AmneziaWG во многих случаях действительно оказывается заметно устойчивее обычного WireGuard. И всё же это по-прежнему игра в сокрытие: сделать WireGuard менее похожим на самого себя.
AmneziaWG 2.0: больше места для манёвра
В AmneziaWG 2.0 идея маскировки получила больше пространства. Если раньше основные вставки касались хендшейка, то теперь управляемая добавка появилась и для других типов сообщений.
С практической точки зрения это четыре поля S1–S4. Каждое из них отвечает за свой тип WireGuard-пакета:
S1 для Handshake Initiation;
S2 для Handshake Response;
S3 для Cookie Reply;
S4 для Transport Data.
Рядом с ними идут H1–H4. Это значения, которыми AmneziaWG заменяет стандартный заголовок типа сообщения WireGuard. Причём во второй версии их можно задавать не только конкретными числами, но и диапазонами. В результате пакет становится менее стабильным внешне: перед ним появляется управляемая вставка, а привычный WireGuard-заголовок перестаёт быть таким очевидным.
Однако, на мой взгляд, самое интересное расширение AmneziaWG 2.0 это S4, который относится к Transport Data, то есть к основному потоку данных. Это значит, что пространство для маскировки появляется не только в начале соединения, а на протяжении всей жизни туннеля.
И тут возникает естественный вопрос: если в каждом пакете уже есть место для управляемой вставки, обязательно ли заполнять его случайными байтами? Почему бы не использовать это место так, чтобы пакет стал похож не на случайный шум, а на другой протокол?
От случайности к имитации
Итак, идея в том, чтобы заменить случайный шум в S1–S4 осмысленной структурой, похожей на трафик другого протокола. А в сочетании с правильно сгенерированными имитационными и мусорными пакетами это помогает сформировать более правдоподобный внешний профиль соединения.
Очевидно, для полноценной двусторонней имитации нужны обе стороны VPN-туннеля. На сервере за это отвечает amneziawg-proxy: отдельный UDP-прокси, который ставится перед AmneziaWG-сервером. Сам AmneziaWG при этом уводится на loopback, например на 127.0.0.1, а публичный UDP-порт занимает прокси. Именно этот порт видит DPI снаружи, и именно с ним взаимодействуют внешние проверки.
Задача серверного прокси состоит в двух вещах. Во-первых, он отвечает на активные пробники как настоящий сервис. Если на порт приходит QUIC Initial, DNS-запрос, STUN Binding Request или SIP-запрос, прокси возвращает ожидаемый ответ соответствующего протокола: для QUIC это Version Negotiation, для DNS это DNS-ответ, для STUN это Binding Success, для SIP это 100 Trying.
Это важно, потому что пассивной маскировки уже недостаточно. Фильтр может не только смотреть на проходящий трафик, но и сам проверять подозрительный порт: действительно ли там QUIC, DNS, STUN или SIP. Если порт молчит или отвечает не так, как должен отвечать настоящий сервис, маска быстро слетает.
Во-вторых, прокси работает с серверным направлением трафика. AmneziaWG-пакеты уже содержат управляемые S-вставки, и прокси может перезаписать это место не случайными байтами, а байтами, характерными для выбранного протокола. В результате ответные пакеты со стороны сервера начинают выглядеть как QUIC, DNS, STUN или SIP, хотя внутри по-прежнему остаётся зашифрованная нагрузка AmneziaWG.
Но это только половина картины. Чтобы имитация была двунаправленной, клиент тоже должен уметь формировать пакеты в том же стиле. Эту часть реализует WireSock Secure Connect 3.5+. Он создаёт клиентские имитационные пакеты и заполняет S-вставки на своей стороне так, чтобы направление от клиента к серверу выглядело не как обычный AmneziaWG, а как трафик выбранного протокола.
Именно связка WireSock Secure Connect 3.5+ и amneziawg-proxy делает подход полноценным. Прокси отвечает за серверную сторону, probe responses и маскировку ответного потока. WireSock Secure Connect берёт на себя клиентскую сторону. Вместе они меняют внешний вид датаграмм на проводе так, чтобы для стороннего наблюдателя это был не WireGuard и не «обфусцированный WireGuard», а трафик выбранного протокола: QUIC, DNS, STUN или SIP.
Этот подход развивает идею имитационных пакетов I1–I4 и переносит её на следующий уровень. Сами эти параметры, на мой взгляд, не самые удобные для пользователя, поэтому в WireSock Secure Connect я заменил их более понятной схемой: домен, протокол и профиль браузера. Но идея эффективная: вместо случайного шума перед хендшейком показать DPI трафик, похожий на другой протокол. А если сервер ещё и отвечает на эти пакеты как настоящий сервис, а последующий поток продолжает выглядеть как выбранный протокол, то маска получается намного убедительнее.
QUIC-режим на публичном порту сервера. Wireshark разбирает поток как обычный QUIC: Initial с CRYPTO, затем Handshake и Protected Payload. Внутри при этом остаётся AmneziaWG-туннель, а внешняя форма пакетов задаётся amneziawg-proxy и Wiresock Secure Connect.
Почему имитация лучше шума
Случайный padding помогает спрятать узнаваемые признаки, но не делает трафик похожим на нормальный протокол. Он скорее создаёт неопределённость: это уже не чистый WireGuard, но и не что-то привычное для сети.
Протокольная имитация работает иначе. Её задача не просто убрать сигнатуру WireGuard, а подставить на её место более правдоподобную картину. Чтобы пакет выглядел не как набор случайных байтов, а как QUIC, DNS, STUN, SIP или что-то еще.
Для DPI это уже другая ситуация. Пакет не просто перестаёт быть похожим на WireGuard, а начинает выглядеть как нормальный пакет выбранного протокола. В начале датаграммы появляется осмысленная структура QUIC, DNS, STUN или SIP, а не случайные байты, которые просто маскируют WireGuard-заголовок.
Конечно, это не делает трафик невидимым. Но меняется стоимость анализа. Одно дело заблокировать всё, что похоже на WireGuard или на странный UDP-шум. Другое дело начать агрессивно подозревать трафик, который выглядит как QUIC, DNS, STUN или SIP, и при этом не задеть настоящие сервисы, использующие те же протоколы.
В сетях, где ложные срабатывания нежелательны, это уже совсем другая игра.
Режимы имитации
На данный момент в amneziawg-proxy доступны несколько режимов имитации: QUIC, DNS, STUN, SIP и auto. В режиме auto протокол имитации выбирается отдельно для каждого клиента по первому пакету, который приходит от него на публичный порт.
QUIC выглядит наиболее естественным выбором по умолчанию. Современный интернет и так полон QUIC/HTTP3-трафика: он ходит поверх UDP, зашифрован, высокоэнтропиен и обычно не выглядит как старый добрый текстовый протокол. Если нужно выбрать маску «по умолчанию», QUIC выглядит логично.
Другой интересный вариант это DNS. С одной стороны, DNS часто разрешён даже в довольно строгих сетях. С другой стороны, DNS-трафик обычно ожидается на 53-м порту, и его поведение могут внимательно контролировать. Поэтому здесь особенно важно, чтобы пакет не выглядел как WireGuard со случайной вставкой в начале, а нормально разбирался как DNS-сообщение.
DNS-режим. На захвате видны обычные DNS-запросы и ответы: A/AAAA/HTTPS-записи, поддомены, OPT-записи. При включённой пересылке DNS-пробники могут получать реальные ответы upstream-резолвера, поэтому порт выглядит не просто как заглушка, а как рабочий DNS-сервис.
STUN полезен там, где в сети ожидается WebRTC или другой NAT traversal-трафик. В таком режиме пакеты выглядят как обычные Binding Request / Binding Success Response. Это не самый универсальный камуфляж, но в подходящей среде он хорошо вписывается в ожидаемую картину.
STUN-режим. Клиентские пакеты выглядят как Binding Request, серверные — как Binding Success Response с XOR-MAPPED-ADDRESS. Для наблюдателя это похоже на обычный NAT traversal/WebRTC-подобный обмен.
SIP выглядит самым необычным режимом. Идея маскировать VPN под VoIP-сигнализацию на первый взгляд кажется странной, но на практике картина получается довольно убедительной: текстовые SIP-заголовки, запросы INVITE, OPTIONS, REGISTER, SUBSCRIBE и привычные ответы вроде 100 Trying или 200 OK. Этот режим хорошо показывает, насколько далеко мы ушли от простого случайного padding: трафик уже не просто прячется, а пытается сыграть роль вполне конкретного сервиса.
SIP-режим. В захвате видны INVITE, CANCEL, NOTIFY, OPTIONS, REGISTER, SUBSCRIBE и ответы вроде 100 Trying, 180 Ringing, 200 OK. На проводе такой поток выглядит как сигнализация VoIP-инфраструктуры.
Режим auto нужен для сценария, когда один и тот же сервер принимает клиентов с разными режимами имитации. В этом режиме прокси не фиксирует один протокол заранее, а смотрит на первый пакет от каждого клиента. Если пакет похож на QUIC, DNS, STUN или SIP, прокси запоминает этот протокол для данной сессии и дальше использует его для ответного трафика. Если первый пакет не похож ни на один известный режим, сессия остаётся в состоянии none и работает как обычный проброс AmneziaWG без протокольной имитации со стороны прокси.
Зачем здесь WireSock Secure Connect 3.5+
amneziawg-proxy работает на сервере. Он закрывает серверную часть задачи: принимает трафик на публичном UDP-порту, отвечает на активные пробники и маскирует ответный поток от сервера к клиенту.
Но для полноценной имитации этого мало. Если клиент отправляет обычные AmneziaWG-пакеты, а сервер отвечает уже замаскированными, картина получается односторонней. Снаружи это выглядит лучше, чем обычный AmneziaWG, но направление от клиента к серверу всё равно остаётся слабым местом.
Для двусторонней имитации клиент тоже должен участвовать в игре. Он должен формировать имитационные пакеты перед хендшейком и заполнять S-вставки не случайными байтами, а структурой выбранного протокола. Эту часть как раз реализует WireSock Secure Connect 3.5+.
Поэтому полноценный сценарий строится на связке двух компонентов. amneziawg-proxy отвечает за серверную сторону, probe responses и маскировку ответного потока. WireSock Secure Connect берёт на себя клиентскую сторону. Вместе они позволяют сделать так, чтобы для стороннего наблюдателя трафик выглядел не как WireGuard или обфусцированный WireGuard, а как QUIC, DNS, STUN или SIP.
Как это выглядит в web-панели
Есть ещё одна практическая деталь, которую хочется отдельно отметить: за всем этим можно наблюдать не только через логи и tcpdump.
В amneziawg-install вместе с прокси развивается web-панель. Она показывает состояние пиров, последний handshake, счётчики RX/TX, uptime сервера и время его загрузки. А ниже отдельным блоком выводятся активные proxy-сессии: реальный адрес клиента, публичный порт прокси, целевой порт AmneziaWG, распознанный протокол и время последней активности.
Веб-панель AmneziaWG. Сверху видны версии компонентов и uptime сервера, ниже — список пиров, последний handshake и счётчики RX/TX. Отдельный блок Active proxy sessions показывает реальные proxy-сессии: удалённый адрес клиента, proxy port, target port, распознанный protocol и время последней активности.
На скриншоте видно две активные сессии: одна определена как sip, другая как none. Это хороший пример для режима auto: часть клиентов может использовать полноценную протокольную имитацию, а часть идти через обычный AmneziaWG-проброс без распознанной маски.
Раньше такую картину пришлось бы собирать руками: смотреть логи, запускать tcpdump, сопоставлять адреса и порты. Теперь основные детали доступны прямо из браузера.
Конечно, web-панель не заменяет нормальную диагностику. Если нужно понять, что именно происходит на проводе, всё равно пригодятся tcpdump и Wireshark. Для клиентской стороны полезен и консольный WireSock Secure Connect: он умеет записывать трафик туннеля в PCAP-файлы, которые потом можно открыть и разобрать в Wireshark. Но для повседневного контроля web-панель всё же заметно удобнее, чем постоянная работа с логами и дампами трафика.
Почему это важно
В борьбе с DPI не бывает финальной победы. Это не та область, где можно один раз придумать красивый трюк и навсегда закрыть тему.
Любой массовый метод рано или поздно начинают изучать. Сначала фильтр узнаёт WireGuard по очевидным признакам хендшейка. Потом, когда появляются обфускация и случайный junk, он начинает смотреть шире: на тайминги, объёмы, повторяемость, поведение сессии, реакцию на активные проверки. Если конкретная имитация станет массовой, её тоже будут анализировать.
Поэтому главный вопрос не в том, можно ли сделать трафик абсолютно необнаружимым. Скорее всего, нельзя. Гораздо важнее другое: насколько дорого и рискованно становится его выделять.
Заблокировать чистый WireGuard сравнительно просто. Заблокировать подозрительный UDP-шум тоже можно, особенно в агрессивно фильтруемой сети. А вот начать блокировать трафик, который достаточно убедительно выглядит как QUIC, DNS, STUN или SIP, уже сложнее. Можно задеть настоящие сервисы, сломать приложения, получить ложные срабатывания и жалобы.
Именно здесь протокольная имитация поднимает планку. Она не делает туннель невидимым, но меняет экономику детекта: отличить такой трафик от легитимного становится сложнее, дороже и рискованнее с точки зрения побочных эффектов.
Ограничения, о которых лучше сказать сразу
Не хочется, чтобы эта статья читалась как обещание «теперь всё работает везде». Так не бывает.
Эффективность всегда зависит от конкретной сети. DPI у разных операторов настроен по-разному. Где-то достаточно спрятать хендшейк, где-то помогает junk, где-то нужна полноценная имитация, а где-то выбранный режим может вообще не дать заметного выигрыша. Есть и сценарии, где протокольная имитация не поможет в принципе: например, сети с белыми списками, где разрешены только заранее утверждённые адреса или сервисы, а также прямая блокировка IP-адреса сервера. В таких случаях трафик может сколько угодно выглядеть как QUIC, DNS, STUN или SIP, но это не изменит саму сетевую политику. Универсального профиля, который одинаково хорошо работает во всех условиях, здесь нет.
У любой имитации остаётся поведенческий след. Даже если отдельная датаграмма красиво разбирается как DNS, QUIC, STUN или SIP, остаются тайминги, объёмы, длительность сессии, распределение размеров пакетов, реакция на повторные проверки. Настоящий DNS-сервер, настоящий SIP-сервис и VPN-туннель, который под них маскируется, могут быть похожи на уровне одного пакета, но не обязаны вести себя одинаково на уровне длинной сессии.
Прокси тоже не бесплатен с точки зрения ресурсов. Это дополнительный слой в userspace: он принимает UDP, ведёт сессии, отвечает на probe-пакеты, переписывает padding и форвардит трафик дальше. Для домашнего VPS или небольшой инсталляции накладные расходы, скорее всего, будут приемлемыми. Но на скоростях около гигабита уже стоит смотреть на CPU, системные вызовы и масштабирование по ядрам.
Скриншоты Wireshark в этой статье тоже нужно воспринимать правильно. Они показывают, что трафик чисто разбирается как выбранный протокол. Это важная часть задачи, но не доказательство необнаружимости. Реальный DPI может смотреть не только на один пакет, но и на поведение потока в целом.
И наконец, это технология двойного назначения. Она полезна для приватности, доступа к собственным серверам и устойчивости связи в сетях с агрессивной фильтрацией. Но, как и почти любой сетевой инструмент, её можно использовать по-разному. Этот выбор остаётся на совести того, кто её применяет.
Вместо заключения
Если коротко, эволюция выглядит так.
Сначала WireGuard пытались спрятать от DPI за шумом перед хендшейком. Потом появилась AmneziaWG, которая стала менять уже сами признаки протокола: заголовки, размеры и junk внутри хендшейка. AmneziaWG 2.0 дала больше пространства для управляемых вставок через S1–S4, включая основной поток данных.
Следующий шаг напрашивался сам собой. Если в пакете уже есть место, которое можно контролировать, его можно заполнить не случайными байтами, а структурой другого протокола.
Именно здесь и начинается «игра в имитацию».
WireGuard на проводе должен выглядеть не как WireGuard, а как обычный QUIC, DNS, STUN или SIP. Имитация больше не ограничивается несколькими пакетами перед хендшейком. Выбранная маска сохраняется и в рабочем потоке, а сервер при этом отвечает на probe-пакеты так, как ответил бы настоящий сервис.
В этой схеме WireSock Secure Connect 3.5+ берёт на себя клиентскую сторону, а amneziawg-proxy закрывает серверную: отвечает на probe-пакеты, маскирует ответный поток и помогает собрать правдоподобную картину с обеих сторон туннеля.
Партия против DPI на этом, конечно, не заканчивается. Это всего лишь очередной ход в длинной игре. Но, на мой взгляд, ход логичный: от идеи «спрятать VPN в случайности» мы постепенно переходим к более зрелой идее, где туннель становится частью ожидаемого сетевого пейзажа.
Описанный проект является независимой community-разработкой и не связан с Amnezia, amnezia.org, приложением Amnezia VPN или сервисом Amnezia Free VPN. Он использует открытый протокол AmneziaWG и связанные с ним инструменты. Названия «Amnezia», «AmneziaWG» и связанные с ними товарные знаки принадлежат их правообладателям и используются здесь только для идентификации.