Прошу совета по настройке zapret для обфускации handshake пакета Wireguard в сети Билайн.
DPI билайна распознаёт handshake initiation пакет wireguard’а, и если он идёт к запрещённому VPN провайдеру блокирует ответный пакет handshake response. В некоторых случаях (если долго не было попыток подключения к серверу и DPI “забыл” сигнатуру) один handshake response проходит, остальные блокируются.
Я пытался сделать следующее:
Поставил режим запуска custom, что бы иметь возможность добавить правило в iptables.
В 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
Всё это делается на виртуальном ubuntu server (с режимом подключения bridge).
При попытке подключения к серверу wg я вижу, что количество пакетов и байт, захваченным правилом увеличивается, однако трафик через туннель не идёт.
Если же добавить правило для отлавливания просто http/https трафика: такое же, только для протокола TCP и портов 80, 443, - обфускация работает и трафик до запрещённых хостов ходит.
К сожалению, скрипт blockcheck.sh не умеет определять стратегии обхода для udp-пакетов wireguard.
Также, похоже, что debug=1 не отрабатывает или отрабатывает не так, как ожидается: в /var/log/syslog не появляется дополнительной информации.
Подскажите:
Есть ли какая-то рабочая стратегия для обсускации udp-пакета wireguard handshake?
Корректны ли указанные выше настройки или я где-то ошибся?
Как пользоваться параметром 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.
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
Не пойму с чем может быть связана проблема. Обход настроен на роутере и там же подключаюсь по WG - всё работает, а с десктопного клиента WG рукопожатие не проходит.
--dpi-desync=fake --dpi-desync-ttl=7 --dpi-desync-cutoff=d4 -p udp -m mark ! --mark 0x40000000/0x40000000 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:1
В чём еще может быть дело?
Единственное чем отличается от моего это попробуйте правило добавлять не через -I а через -A iptables -t mangle -A POSTROUTING ...
Ну и естественно удалить добавленное ранее.
Еще можно убрать --daemon добавить --debug и посмотреть отрабатывает ли вообще правило
Попробовал с -A и --debug, забавно получается, ровно наоборот: при активации туннеля на роутере, в логе пусто. При активации на дектопе, сообщения идут. Вот такие:
Соединение проходит, но потом интернет не работает. При этом, если отключить zapret и воспользоваться известным “мусорным” методом при помощи nping, после этого подключение реально работает.
Да что ты будешь делать, заработало. Правда, не совсем
На десктопе без изменений, а вот на роутере что-то протухло в старой настройке, удалил подключение и пересоздал заново из файла, и теперь не только соединяется, но и работает. Но в логах (–debug) по прежнему пусто! Но работает, а до этого даже хендшейк не проходил.
Как там у Карцева? Вот и выбирай: либо не работает, но с логами, либо работает, но без логов
