Обфускация только wireguard handshake: нужна помощь в настройке

Добрый день!

Прошу совета по настройке zapret для обфускации handshake пакета Wireguard в сети Билайн.
DPI билайна распознаёт handshake initiation пакет wireguard’а, и если он идёт к запрещённому VPN провайдеру блокирует ответный пакет handshake response. В некоторых случаях (если долго не было попыток подключения к серверу и DPI “забыл” сигнатуру) один handshake response проходит, остальные блокируются.

Я пытался сделать следующее:

  1. Поставил режим запуска custom, что бы иметь возможность добавить правило в iptables.
  2. Сервис запускаю с параметрами:
    /opt/zapret/nfq/nfqws --user=tpws --dpi-desync-fwmark=0x40000000 --debug=1 --qnum=200 --dpi-desync=fake,udplen --dpi-desync-ttl=7 --dpi-desync-udplen-increment=6 --dpi-desync-any-protocol=1
  3. В iptables добавляю правило:
    Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 NFQUEUE udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 51820 mark match ! 0x40000000/0x40000000 connbytes 1:4 connbytes mode packets connbytes direction original ! match-set nozapret dst NFQUEUE num 200 bypass
  4. Всё это делается на виртуальном ubuntu server (с режимом подключения bridge).

При попытке подключения к серверу wg я вижу, что количество пакетов и байт, захваченным правилом увеличивается, однако трафик через туннель не идёт.
Если же добавить правило для отлавливания просто http/https трафика: такое же, только для протокола TCP и портов 80, 443, - обфускация работает и трафик до запрещённых хостов ходит.

К сожалению, скрипт blockcheck.sh не умеет определять стратегии обхода для udp-пакетов wireguard.
Также, похоже, что debug=1 не отрабатывает или отрабатывает не так, как ожидается: в /var/log/syslog не появляется дополнительной информации.

Подскажите:

  1. Есть ли какая-то рабочая стратегия для обсускации udp-пакета wireguard handshake?
  2. Корректны ли указанные выше настройки или я где-то ошибся?
  3. Как пользоваться параметром debug=1 - куда пишутся логи в этом случае?

Для udp можно безболезненно сделать только отсылку фейк пакетов перед handshake initiation.
На летних блокировках требовалось то ли 4, то ли 5 фейков (dpi-desync-repeats)
для ipv6 можно попытаться поиграться с дополнительными хедерами ipv6 протокола.
udplen для wireguard категорически не годится. любая модификация будет молча отброшена сервером.
Есть вариант ipfrag2, но может сработать только на белом IP клиента со своим сервером, и то не факт. К тому же там есть сложности с iptables, лучше использовать nftables

логи не пишуется никуда. они выводятся в stdout. для тестирования следует отказаться от скриптов запуска и делать все вручную.

если сервер свой, то существует amnezia vpn. это поделие на базе wg с широкими возможностями издевательств над базовым протоколом. к сожалению, пока только tun версия
опять же, если сервер свой, можно использовать легковесное, но сложное решение, ipobfs. модуль ядра, ксорящий ip пейлоады по заданным правилам
или какой-нибудь udp прокси-обфускатор, но это user mode, что не лучшим образом скажется на скорости

Спасибо!
Эта стратегия сработала! Буду пользоваться.
И с логами разобрался - nfqws корректно определяет пакет.
Если что - VPN не свой собственный (не на своём сервере), а покупной (как сервис). Поэтому я в манёврах ограничен.

Как вы определили, что блокируют ответ? Такие блокировки редки, машина цензора выбирает кратчайший путь до блокировки. При этом, как правило, исходящие не учитывают, поэтому клиентские трюки там не работают. Это не значит, что такое невозможно, но проверять исходящие, блокируя входящие – расточительство.

Я подключил Wireshark и смотрел как проходит соединение.
Если соединения давно не было, то в ответ на handshake initiation приходит пакет handshake response, но трафик через тоннель не идёт. Все последующие handshake initiation остаются без ответа. Если соединение было недавно, и затем происходит повторно то и на первый пакет initiation не приходит response.
Я сделал такой вывод (о блокировке ответов на основе первого пакета initiation). Хотя что на самом деле там происходит - сказать не могу. У меня нет глубоких знаний в том, как соединения отслеживаются и блокируются.
В итоге сработала стратегия --dpi-desync=fake,disorder --dpi-desync-fooling=md5sig --dpi-desync-any-protocol=1 --dpi-desync-repeats=4
Чему я очень рад, поскольку не нужно теперь пробивать какие-то обходные пути через ещё один сервер (VPS).

disorder и md5sig относятся только к tcp, для wireguard это не имеет смысла
но если 1 и тот же nfqws используется для разных целей, то норм

летом блокировали только по исходящим пакетам , анализируя только несколько первых

DPI устроено так. есть таблица типа conntrack. туда заносится протокол и туплы ip:port src/dst и признак allow/deny/check
если allow/deny, то решение принимается сразу. бывает аппаратный offload на эту таблицу, а бывает где-то в глубине ядра софтварно. но быстрее, чем дальше проверять.
если check, то идем на проверку. чекер может вынести вердикт
они стараются сделать так, чтобы чека было как можно меньше, чтобы сэкономить ресурсы
это все называется stateful DPI. stateless - это когда нет состояний и чек каждый пакет

если начнут проверять и входящие, то на своем сервере тоже можно подвесить nfqws

Большое спасибо за объяснение!

Тогда выходит, что действительно исходящие блокируются - но я это уже не вижу, т.к. трафик ушел дальше, т.е. за границу перехвата пакетов wireshark’ом.

Что касается tcp - я планирую оставить в команде запуска на случай если понадобится. А какой трафик обфусцировать - это разруливать с помощью iptables.

Саратовская область, Билайн, wireguard и openvpn udp работает после одного фейка в nfqws:

–dpi-desync=fake --dpi-desync-cutoff=d4 --dpi-desync-any-protocol=1

P.S. quic тоже работает этой стратегией, использование dpi-desync-repeats ломает quic, но vpn’ы работают

Уже довольно давно nfqws распознает wireguard hanshake initiation, так что можно без any protocol

Hi @bolvan , there is a fork of wireguard-go that can unblock wg hadshake in my region. so some network experties user(s) maybe inspire from it:

I have a question:
Does it possible use a trick as same as above trick with --dpi-desync-fake-wireguard zapret or something like that?

Thank you.

Probably yes.
Wireguard does not allow tampering with their packets but allow inserting any garbage before or between them. Garbage is silently ignored.
Any software giving more options is likely incompatible with original WG

You should redirect first UDP packet in “connection” to nfqws (connbytes filter 1:1) and use --dpi-desync=fake
That’s all