Всем привет!
На связи команда разработчиков Amnezia. Сегодня хотим рассказать о важном обновлении нашего протокола – AmneziaWG 2.0, а также о том, как с его помощью можно развернуть собственный VPN на своем сервере.
AmneziaWG – это наш вариант протокола WireGuard. Первая версия вышла в 2023 году, и с тех пор мы последовательно его развивали. Теперь AmneziaWG 2.0 – это уже не просто набор новых параметров в конфигурации, а заметный технологический шаг вперед в вопросе восстановления доступа к свободному интернету.
Новая версия уже поддерживается в клиенте AmneziaVPN для десктопных приложений и Android у пользователей self-hosted. Репозиторий протокола также доступен в нашем GitHub. Для пользователей Free и Premium пока используется версия AWG 1.5, поддержку AWG 2.0 для этих продуктов мы добавим чуть позже.
Чтобы поднять VPN на собственном сервере с AWG 2.0, достаточно скачать или обновить приложение AmneziaVPN со cтраницы загрузки (или зеркала) до версии 4.8.12.9 и выше, затем заново установить протокол. Дополнительная настройка не потребуется.
Подробную инструкцию по использованию мы подготовили в отдельном гайде.
Кстати, вместе с обновлением приложения, необходимым для работы AmneziaWG 2.0, вы также получите новые функции и исправления ранее найденных багов.
Реальность такова, что там, где интернет-пространство накрывают «цифровым куполом», выживают не самые мощные, а самые ловкие. За последние два года ситуация с интернет-цензурой серьёзно изменилась. Системы глубокого анализа трафика (DPI) становятся умнее, методы блокировок - изощреннее, а простой маскировки заголовков уже недостаточно. Провайдеры научились детектировать не только стандартный WireGuard, но и многие обфусцированные протоколы по статистическим паттернам, размерам пакетов и временным характеристикам трафика.
AmneziaWG 2.0 - это наш ответ на эти вызовы. Мы сохранили всё лучшее из первой версии и добавили возможности, которые позволяют не просто маскировать VPN-трафик, а мимикрировать под любой легитимный UDP-протокол. Теперь ваше соединение может выглядеть как DNS-запросы, QUIC-соединения или SIP-звонки - выбор за вами.
А в этой статье мы расскажем:
Что нового появилось в версии 2.0 по сравнению с первой версией
Как работает система CPS (Custom Protocol Signature) для создания сигнатур протоколов
Примеры готовых конфигураций
! Важно: в статье не будет глубокого погружения в код или детальной реализации. Мы сосредоточимся на практическом применении и понимании принципов работы "из жизни".
AmneziaWG 2.0: что нового
В версии 1.0 AmneziaWG умел:
Отправлять мусорные пакеты перед handshake (Jc, Jmin, Jmax)
Изменять размеры handshake пакетов через padding (S1, S2)
Заменять стандартные WireGuard заголовки на фиксированные значения (H1-H4)
Этого было достаточно против простых signature-based DPI.
Версия 2.0 добавляет возможности для полной мимикрии под легитимные протоколы.
Signature Packets (i1-i5): притворяемся легитимным протоколом
Самое значительное нововведение в AmneziaWG 2.0 - это signature packets. Представьте, что перед каждым настоящим WireGuard handshake ваш клиент отправляет серверу до пяти специальных пакетов, которые выглядят как начало обычного DNS-запроса, QUIC-соединения или любого другого протокола.
Как это работает:
Обычный WireGuard:
Клиент → [WireGuard Handshake] → Сервер ↑ DPI видит: "Это WireGuard!" → БЛОКИРОВКА
AmneziaWG 2.0:
Клиент → [Пакет похожий на DNS] → Сервер Клиент → [Ещё данные DNS] → Сервер Клиент → [WireGuard Handshake с обфускацией] → Сервер ↑ DPI видит: "DNS трафик, всё нормально" → ПРОПУСК
Технически:
Вы можете настроить до 5 signature packets (i1, i2, i3, i4, i5)
Каждый пакет описывается в формате CPS (Custom Protocol Signature) - специальном языке для создания "поддельных" пакетов
Пакеты отправляются перед каждым WireGuard handshake (который происходит раз в 2 минуты)
Если i1 не настроен - signature packets не отправляются (обратная совместимость с 1.0)
Пример простой конфигурации:
# Один signature packet, имитирующий DNS i1 = <b 0x1a2d0100000100000000000109696e666572656e6365...><t><r 15>
Мы детально разберём формат CPS и как создавать свои сигнатуры в разделе 3. Пока важно понять главное: i1-i5 позволяют вашему трафику начинаться как любой легитимный протокол.
Расширенный padding: S3 и S4
В версии 1.0 мы могли изменять только размеры handshake пакетов (S1 и S2). Но handshake происходит редко - раз в 2 минуты. Основной объём вашего трафика - это data пакеты (загрузка сайтов, видео, файлы), и они оставались с предсказуемыми размерами.
AmneziaWG 2.0 добавляет padding для всех типов пакетов.
S3 - Cookie Reply Padding
Cookie Reply - это специальный пакет, который WireGuard сервер отправляет клиенту, когда находится под нагрузкой (защита от DoS атак). Стандартный размер - ровно 64 байта, что является отличным индикатором для DPI.
Когда работает: Только когда сервер под нагрузкой и отправляет cookie reply
Пример: S3 = 32 - к 64 байтам добавится 32 случайных байта
S4 - Transport Data Padding
Это самый важный новый параметр. S4 добавляет случайные байты к зашифрованным транспортным пакетам, несущим фактический интернет трафик.
Когда работает: Постоянно, для всех data пакетов
Компромисс: Маскировка vs скорость
Аналогия из жизни:
Представьте, что вы отправляете посылки (data пакеты). В версии 1.0 мы меняли размер только "конверта" для первой посылки (handshake). Но все остальные посылки имели стандартные размеры - легко узнать.
В версии 2.0 мы добавляем случайное количество упаковочного материала (S4) к КАЖДОЙ посылке. Теперь все они разного размера, и понять что внутри - намного сложнее.
Пример конфигурации:
S1 = 68 # Handshake init padding (было в 1.0) S2 = 149 # Handshake response padding (было в 1.0) S3 = 32 # Cookie reply padding (НОВОЕ в 2.0) S4 = 16 # Data padding (НОВОЕ в 2.0)
В WireGuard каждый пакет начинается с 4-байтового идентификатора типа:
Type=1 - Handshake Initiation
Type=2 - Handshake Response
Type=3 - Cookie Reply
Type=4 - Transport Data
AmneziaWG 1.0 позволял заменить их на свои значения через параметры H1-H4, но эти значения были фиксированными для всех пакетов.
Проблема версии 1.0:
H1 = 1234567890 # Все handshake init пакеты имеют заголовок 1234567890 H4 = 9876543210 # Все data пакеты имеют заголовок 9876543210
DPI может запомнить паттерн пакетов с учетом этих значений и снова заблокировать трафик.
Решение в версии 2.0 - диапазоны:
H1 = 471800590-471800690 # 101 возможный вариант! H4 = 1769581055-1869581055 # 100 миллионов вариантов!
Как это работает:
При отправке: Для каждого пакета случайно выбирается значение из указанного диапазона
При приёме: Принимается любое значение из настроенного диапазона
Результат: Каждый пакет имеет уникальный заголовок
Аналогия из жизни:
Это как пропуск в охраняемое здание. Раньше (версия 1.0) у всех был пропуск с номером 1234567890 - охрана быстро запомнила и начала проверять. Теперь (версия 2.0) каждый раз вы получаете пропуск со случайным номером от 1000000000 до 1000000100. У охраны нет шансов запомнить все 101 вариант, а проверять каждый индивидуально - слишком долго.
Важное ограничение: Диапазоны H1, H2, H3 и H4 не должны пересекаться. Иначе невозможно будет понять, какой тип пакета пришёл.
Хороший пример:
H1 = 471800590-471800690 # От 471,800,590 до 471,800,690 H2 = 1246894907-1246895000 # От 1,246,894,907 до 1,246,895,000 H3 = 923637689-923637690 # От 923,637,689 до 923,637,690 H4 = 1769581055-1869581055 # От 1,769,581,055 до 1,869,581,055
Диапазоны не пересекаются
Плохой пример:
H1 = 1000-2000 H2 = 1500-2500 # Пересекается с H1 в зоне 1500-2000!
Визуализация работы range-based заголовков:
Стандартный WireGuard (всегда одинаковые): Пакет 1: [Type=4] Data... Пакет 2: [Type=4] Data... Пакет 3: [Type=4] Data... ↑ DPI: "Всё время вижу Type=4, это WireGuard!" AmneziaWG 1.0 (фиксированное значение): Пакет 1: [H4=1234567890] Data... Пакет 2: [H4=1234567890] Data... Пакет 3: [H4=1234567890] Data... ↑ DPI: "Всё время 1234567890, запомню и заблокирую" AmneziaWG 2.0 (диапазон): Пакет 1: [H4=1769634522] Data... Пакет 2: [H4=1823947612] Data... Пакет 3: [H4=1791283445] Data... ↑ DPI: "Каждый раз разное, невозможно отследить!"
Порядок отправки пакетов в AmneziaWG 2.0
Теперь, когда мы разобрали все нововведения, давайте посмотрим как они работают вместе. Вот полный порядок отправки пакетов при установке соединения:
При каждом handshake (раз в 2 минуты):
1. i1 → i2 → i3 → i4 → i5 (если настроены signature packets) ↓ 2. Junk packets × Jc (мусорные пакеты) ↓ 3. [S1 padding | H1(random) 4 bytes | Handshake Initiation 144 bytes] ↓ 4. [S2 padding | H2(random) 4 bytes | Handshake Response 88 bytes]
При нагрузке на сервер (если происходит):
5. [S3 padding | H3(random) 4 bytes | Cookie Reply 60 bytes]
Весь data трафик (постоянно):
6. [S4 padding | H4(random) 4 bytes | Transport Data payload] [S4 padding | H4(random) 4 bytes | Transport Data payload] [S4 padding | H4(random) 4 bytes | Transport Data payload] ...
Ключевые моменты:
i1-i5 отправляются только если настроены
Junk packets отправляются всегда перед handshake
S1/S2 применяются к handshake пакетам
S3 применяется к cookie reply (редко, только под нагрузкой)
S4 применяется к КАЖДОМУ data пакету (ваш основной трафик)
H1-H4 с ranges - каждый пакет получает уникальный заголовок
CPS - язык маскировки трафика
Что такое CPS простыми словами
CPS (Custom Protocol Signature) - это специальный формат для описания того, как должны выглядеть signature packets (i1-i5). Можно сказать, это "конструктор" для создания поддельных пакетов.
Аналогия из жизни:
Представьте театральную постановку. Ваш VPN-трафик - это актёр, который должен пройти мимо охранника (DPI система). CPS - это сценарий и костюм. Вы пишете: "надень полицейскую форму, покажи бейдж с номером, скажи 'патруль №47'". Охранник видит полицейского и пропускает, не проверяя что под формой.
Как это работает:
DPI система смотрит на начало пакета (первые 50-200 байт) и ищет знакомые паттерны протоколов. Если видит, например, начало DNS запроса - пропускает как легитимный трафик. Настоящий WireGuard handshake идёт следом, после нашей "маски".
Доступные теги CPS
CPS состоит из тегов - специальных команд, которые описывают из чего собрать пакет:
Тег | Что делает | Пример |
<b 0xHEX> | Вставляет точные байты | <b 0x1a2d8180> |
<t> | Timestamp (4 байта) | Unix time |
<r N> | N случайных байт | <r 20> |
<rc N> | N случайных букв/цифр [A-Za-z] | <rc 10> → "aB3dEf9H2k" |
<rd N> | N случайных цифр [0-9] | <rd 5> → "13654" |
Общий принцип работы на примере:
i1 = <b 0xc700000001><rc 8><t><r 50>
Давайте разберём по частям что получится:
<b 0xc700000001> - вставляем точные байты (это начало QUIC Initial packet)
<rc 8> - добавляем 8 случайных букв/цифр, например "aB3dEf9H" (имитация Connection ID)
<t> - добавляем текущее время, например 1732377600 (23 ноября 2025)
<r 50> - добавляем 50 случайных байт (payload)
Результат: Пакет выглядит как начало QUIC соединения (HTTP/3). DPI система распознаёт его как легитимный QUIC трафик и пропускает.
Зачем разные теги:
<b> - это "скелет" сигнатуры, магические байты протокола
<t> - добавляет уникальность каждому пакету
<r> - бинарные данные для размера и энтропии
<rc> и <rd> - для текстовых протоколов (домены, URL, порты)
Пример реальной сигнатуры: QUIC
i1 = <b 0xc700000001><rc 8><t><r 50>
Что здесь происходит:
<b 0xc700000001> - начало QUIC пакета:
0xc7 - тип пакета (QUIC Initial)
0x00000001 - версия QUIC v1
0x0 - начало Connection ID
<rc 8> - 8 случайных символов для Connection ID
Каждое соединение будет выглядеть по-разному: "aB3dEf9H", "xY7zK2mN", "pQ9rS4tU"
<t> - временная метка (разная для каждого handshake)
<r 50> - 50 случайных байт payload
Почему это работает:
DPI видит первые байты 0xc7 0x00000001 - характерные для QUIC
Connection ID выглядит правдоподобно благодаря <rc>
Размер пакета адекватный (~70-80 байт)
Wireshark определяет это как "QUIC" протокол
DPI пропускает как HTTP/3 трафик
Важные моменты при работе с сигнатурами
Критерии выбора протокола
Не все протоколы одинаково подходят для мимикрии:
Хороший выбор:
DNS - универсальный, работает везде
QUIC - современный, HTTP/3, растёт популярность
SIP - VoIP звонки, много легитимного трафика
STUN - WebRTC, видеозвонки
Плохой выбор:
TCP-протоколы (HTTP/1.1, SMTP, FTP)
Экзотические протоколы (мало кто использует)
Слишком короткие пакеты (<32 байт)
Как проверить сигнатуру
Простой тест перед использованием:
# 1. Конвертируйте hex в бинарный файл echo "c7000000010..." | xxd -r -p > test.bin # 2. Откройте в Wireshark wireshark test.bin
Что должно быть: Wireshark должен показывать название протокола (DNS, QUIC, SIP), а не просто “UDP”
Рекомендуемый размер:
Минимум: 100+ байт (меньше выглядит подозрительно)
Оптимум: 100-500 байт (баланс между правдоподобностью и скоростью)
Максимум: 1200 байт (ограничение MTU)
Слишком короткие пакеты легко выделяются на фоне реального трафика, а пакеты больше 1200 байт могут вызвать фрагментацию и проблемы с передачей.
Применение на практике
Полная конфигурация AmneziaWG 2.0
Давайте посмотрим как выглядит полная конфигурация AmneziaWG 2.0 с использованием всех нововведений.
Пример конфигурации клиента:
[Interface] Address = 10.8.1.2/24 PrivateKey = YOUR_PRIVATE_KEY DNS = 1.1.1.1, 1.0.0.1 # ========================================== # Junk packets (из версии 1.0) # ========================================== Jc = 7 # Количество мусорных пакетов Jmin = 50 # Минимальный размер Jmax = 1000 # Максимальный размер # ========================================== # Padding для всех типов пакетов # ========================================== S1 = 68 # Handshake init padding (1.0) S2 = 149 # Handshake response padding (1.0) S3 = 32 # Cookie reply padding (NEW в 2.0) S4 = 16 # Transport data padding (NEW в 2.0) # ========================================== # Range-based заголовки (NEW в 2.0) # ========================================== H1 = 471800590-471800690 # Handshake Init (101 вариант) H2 = 1246894907-1246895000 # Handshake Response (94 варианта) H3 = 923637689-923637690 # Cookie Reply (2 варианта) H4 = 1769581055-1869581055 # Transport Data (100 миллионов!) # ========================================== # Signature packets - мимикрия под QUIC (NEW в 2.0) # ========================================== i1 = <b 0xc700000001><rc 8><t><r 100> i2 = <b 0xf6ab3267fa><t><rc 20><r 80> [Peer] PublicKey = SERVER_PUBLIC_KEY Endpoint = your-server.com:51820 AllowedIPs = 0.0.0.0/0, ::/0 PersistentKeepalive = 25
Конфигурация сервера:
На сервере параметры должны совпадать с клиентом:
[Interface] PrivateKey = SERVER_PRIVATE_KEY Address = 10.8.1.1/24 ListenPort = 52010 # Те же параметры обфускации что и на клиенте Jc = 7 Jmin = 50 Jmax = 1000 S1 = 68 S2 = 149 S3 = 32 S4 = 16 H1 = 471800590-471800690 H2 = 1246894907-1246895000 H3 = 923637689-923637690 H4 = 1769581055-1869581055 i1 = <b 0xc700000001><rc 8><t><r 100> i2 = <b 0xf6ab3267fa><t><rc 20><r 80> [Peer] PublicKey = CLIENT_PUBLIC_KEY AllowedIPs = 10.8.1.2/32
Важно: Параметры S1-S4, H1-H4 должны совпадать на клиенте и сервере
Проверка работоспособности
После настройки проверьте подключение:
В приложении AmneziaVPN:
Импортируйте конфигурацию
Подключитесь к серверу
Если трафик идёт (сайты открываются) - всё работает!
Если не работает:
Проверьте что параметры обфускации одинаковые на клиенте и сервере
Убедитесь что порт открыт на сервере
Попробуйте уменьшить S4 (влияет на скорость)
Заключение
AmneziaWG 2.0 представляет собой значительный шаг вперёд в технологии обхода блокировок. Мы перешли от простой обфускации заголовков и размеров к полноценной мимикрии под легитимные протоколы.
Что мы получили в версии 2.0:
Signature packets (i1-i5) - возможность маскировать трафик под DNS, QUIC, SIP или любой другой UDP-протокол
Range-based заголовки (H1-H4) - каждый пакет с уникальным заголовком из диапазона
Расширенный padding (S3/S4) - обфускация для всех типов пакетов, включая основной data-трафик
Новые CPS теги (<b>, <t>, <r>, <rc>, <rd>) - инструменты для создания реалистичных сигнатур протоколов
Протокол стал мощнее, но при этом не потерял в простоте использования. Вы можете начать с базовой конфигурации и постепенно добавлять сложность по мере необходимости.
Важно помнить:
Начинайте с простых сигнатур и тестируйте их работоспособность
Параметры обфускации должны совпадать на клиенте и сервере
Балансируйте между безопасностью и производительностью (особенно S4)
Экспериментируйте с разными протоколами для мимикрии
Мы будем рады вашему фидбеку!
Тестируйте AmneziaWG 2.0, пробуйте разные сигнатуры и делитесь результатами в комментариях. Если у вас возникнут вопросы по настройке self-hosted, вы всегда можете обратиться в нашу поддержку через телегам-бот или почту support@amnezia.org.
Следите за нашими анонсами в Telegram, X и Reddit, читайте новые материалы в блоге Amnezia. Вместе мы делаем интернет свободнее!
