Добрый день!
Прошу совета по настройке zapret для обфускации handshake пакета Wireguard в сети Билайн.
DPI билайна распознаёт handshake initiation пакет wireguard’а, и если он идёт к запрещённому VPN провайдеру блокирует ответный пакет handshake response. В некоторых случаях (если долго не было попыток подключения к серверу и DPI “забыл” сигнатуру) один handshake response проходит, остальные блокируются.
Я пытался сделать следующее:
- Поставил режим запуска custom, что бы иметь возможность добавить правило в iptables.
- Сервис запускаю с параметрами:
/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 - В 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.
Саратовская область, Билайн, 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
Не пойму с чем может быть связана проблема. Обход настроен на роутере и там же подключаюсь по 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
В чём еще может быть дело?
у вас ttl fooling на udp
он там не нужен, плюс попробуйте repeats сделать 6-10
Согласен, ttl убрал.
UPD: Заработало, какие-то проблемы с NAT на роутере были.
У меня тоже не работает, вроде же все верно делаю?
nfqws --daemon --dpi-desync=fake --dpi-desync-repeats=10 --dpi-desync-cutoff=d4 --qnum=200
iptables -t mangle -I POSTROUTING -p udp -m mark ! --mark 0x40000000/0x40000000 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:1 -j NFQUEUE --queue-num 200 --queue-bypass
Единственное чем отличается от моего это попробуйте правило добавлять не через -I а через -A
iptables -t mangle -A POSTROUTING ...
Ну и естественно удалить добавленное ранее.
Еще можно убрать --daemon добавить --debug и посмотреть отрабатывает ли вообще правило
Попробовал с -A и --debug, забавно получается, ровно наоборот: при активации туннеля на роутере, в логе пусто. При активации на дектопе, сообщения идут. Вот такие:
packet: id=1 len=176 mark=00000000
IP4: ... => ... proto=udp ttl=127 sport=... dport=...
UDP: ...
desync-cutoff not reached (mode d): 1/4
packet contains wireguard handshake initiation
dpi desync src=... dst=...
sending fake request : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : ................................ ...
reinjecting original packet. len=176 len_payload=148
applying linux postnat conntrack workaround
packet: id=1 pass modified. len=28
Соединение проходит, но потом интернет не работает. При этом, если отключить zapret и воспользоваться известным “мусорным” методом при помощи nping, после этого подключение реально работает.
Да что ты будешь делать, заработало. Правда, не совсем 
На десктопе без изменений, а вот на роутере что-то протухло в старой настройке, удалил подключение и пересоздал заново из файла, и теперь не только соединяется, но и работает. Но в логах (–debug) по прежнему пусто! Но работает, а до этого даже хендшейк не проходил.
Как там у Карцева? Вот и выбирай: либо не работает, но с логами, либо работает, но без логов 
del
Поменял POSTROUTING на OUTPUT, логи появились, но соединение теперь не проходит
“Я слишком стар для этого дерьма” (с)
не надо было, я же удалил пост. mangle postrouting работает и с исходящими и с проходящими пакетами. посмотрите через iptables -t mangle -vnL, проходят ли пакеты через нужное правило (1 столбец, пакеты должны увеличиваться после каждой попытки соединения).
и еще для вашей цели подойдёт amneziaWG, есть и на пк и на мобилу.
вот только что проверил на awg, фейки приходят на сервер и в логе есть запись, подключался с другого устройства в lan со сменой шлюза (кстати может надо ребутнуть девайс из-за кеша таблицы маршрутизации)
/opt/zapret/nfq/nfqws --qnum=250 --dpi-desync-any-protocol=1 --dpi-desync-repeats=20 --dpi-desync=fake --debug=1
iptables -t mangle -A POSTROUTING -p udp -m udp --dport 100 -m connbytes --connbytes 1:1 --connbytes-mode packets --connbytes-dir original -j NFQUEUE --queue-num 250 --queue-bypass
port 100 = awg server
Спасибо, попробую. Про амнезию я знаю, но у меня пока стоит цель претворить в жизнь решения партии и правительства, не прибегая к платным методам Пока недостатка в бесплатных вариантах нет, осталось только разобраться. И для общего развития полезно. Как бесплатные варианты закончатся, уже буду копать в сторону Vision/Reality, все надежней, чем амнезия
дополнил
Между прочим AmneziaVPN поднимает Vision/Reality на вашем сервере за пару нажатий.
Доброе.
Тоже столкнулся с тем что нужно обрусифицировать трафик WG. но мне это нужно делать на роуторе mikrotik.
Есть возможность поставить контейнер или вдруг каким-то чудом сделать это непосредственно средствами самой железки.
Подскажите, zapret существует в виде контейнера?
Добрый день!
Я перехожу на OpenWRT с nftables, с которыми раньше не работал.
Для запуска zapret хочу использовать кастомный init.d (для инъекции правила firewall), но не знаю, как его написать. Подскажите, пожалуйста, как должно звучать правило для zapert “перехватывай и отправляй в zapret первые 4 пакета любого соединения udp на порт 51280” и его модификация “перехватывай и отправляй в zapret первые 4 пакета соединения udp на порт 51280, если оно идёт на адрес <такой-то>”.
Спасибо!
del
cutoff здесь не нужен, потому что nfqws и так распознает wireguard handshake, а к остальным дурение не будет применено, поскольку нет --dpi-desync-any-protocol
В openwrt трогать правила таблиц из init.d - крайне плохой тон, поскольку это чревато гонками с системой управления фаерволом и потерей правил при любых сохранениях или рестартах.
У fw3 с iptables и fw4 с nftables есть свои хуки и инклуды, но разные.
К ним и следует прикручиваться
Полагаю, возникло недопонимание. Под “кастомным init.d” я имел в виду скрипт /opt/zapret/init.d/<архитектура>/custom.
С правилами разобрался. Взял за основу пример из указанной папки и переделал его.
Добрый день. Тестирую в ручном режиме обфускацию только хэндшейка. Пакет уходит в нужную очередь, модифицируется, но после первого пакета пинга соединение зависает. Подскажите, пожалуйста, в какую сторону копать?
Запускаю так:
~ # /opt/zapret/nfq/nfqws --dpi-desync=fake --dpi-desync-repeats=20 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin --qnum=200 --debug=1
IPTABLES:
~ # iptables-save | grep NFQUEUE
-A POSTROUTING -o eth3 -p udp -m multiport --dports 51820 -m mark ! --mark 0x40000000/0x40000000 -m connbytes --connbytes 1:1 --connbytes-mode packets --connbytes-dir original -j NFQUEUE --queue-num 200 --queue-bypass
Результат:
IP4: x.x.x.x => x.x.x.x proto=udp ttl=64 sport=41605 dport=51820
UDP: 01 00 00 00 58 CB FC 6C 1B 29 C7 6A B5 22 7C 28 B7 75 D5 4D F4 6E 0E 43 C3 D6 15 30 AF 8F 92 4A … : …X…l.).j."|(.u.M.n.C…0…J …
desync profile search for hostname=‘’ ipv6=0 tcp_port=0 udp_port=51820
desync profile 1 matches
packet contains wireguard handshake initiation
dpi desync src=x.x.x.x:41605 dst=x.x.x.x:51820
sending fake request : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … : … …
reinjecting original packet. len=176 len_payload=148
applying linux postnat conntrack workaround
packet: id=3 pass modified. len=28
nfqws --qnum=220 --user=daemon --dpi-desync-fwmark=0x40000000 --dpi-desync=fake --dpi-desync-repeats=6
У меня так работает.