Сюда буду сбрасывать информацию о последних изменениях в проекте

КОМПЛЕКТ ДЛЯ WINDOWS : GitHub - bol-van/zapret-win-bundle: zapret and blockcheck binary bundle for windows

Опишу кратко назначение.
Проект нацелен на прозрачный обход блокировок и замедлений веб сайтов http(s) на Windows, Linux, FreeBSD, OpenBSD, частично MacOS, в том числе на роутерах на базе openwrt. Может применяться и для противодействия сигнатурному анализу произвольных tcp и udp протоколов
Он состоит из следующих компонент :

1. Скрипты для автоматизации получения списка заблокированных ip и хостов и их обработки (ipset, ip2net, mdig).
2. Программы для обхода DPI на http и https : nfqws,dvtws,winws,tpws,
3. Скрипты задействования этих программ + фаервола на разных системах - openwrt, sysv, systemd, macos (init.d)
4. blockcheck - средство проверки рабочих методов обхода DPI
5. То, что не автоматизировано. Описательная часть для продвинутых пользователей : как организовать выборочное прозрачное проксирование соединений, заворот на VPN, способы модификации существующих VPN решений для изменений их стандартного протокола с целью скрытия от DPI

Изменения май-июнь 2019
Проект был существенно доработан.

Сделана максимально упрощенная установка для пользователей основных дистрибутивов linux и openwrt через скрипт install_easy.sh.
Вариант по умолчанию ставит сплиттер http запросов + Host => HOST
Переписаны скрипты для debian и openwrt.
Убрана вся каша с провайдерами, потому что все равно не буду следить за актуальностью что на каком провайдере.
Теперь все более логично. Вы выбираете что использовать : tpws или nfqws, их параметры.
Можно легко самому добавлять в скрипты запуск дополнительных демонов или их копий с разными параметрами.
Добавление правил firewall вынесено в отдельные процедуры, которые можно использовать при модификации скрипта.
Добавление правил firewall под openwrt вынесено в отдельный firewall include /etc/firewall.zapret, чтобы /etc/firewall.user использовать для своих целей и не смешивать команды.
Настройки вынесены из init скриптов в отдельный файл “config”.
Все выглядит проще и лаконичней imho
Листы РКН разрослись до мегабайтов. Теперь они хранятся в сжатом виде, что уменьшает в разы требования свободного места на роутере.
Новая программа ip2net позволяет в 2-3 раза уменьшить ipset-ы, объединяя ip в подсети.
Многопоточный ресолвер mdig делает снова реальным самостоятельный ресолвинг реестра через get_reestr.sh.
Добавлены бинарики для arm64, mips64, ppc.
Бинарики для всех архитектур, кроме mips64, запакованы в upx. Это уменьшает их размер в 2 раза.
Сделан автоматический распознаватель архитектуры и установщик бинариков - install_bin.sh
install_easy.sh в случае необнаружения подходящих бинариков может сам их собрать при условии наличия gcc,make и необходимых -dev пакетов
Можно запустить install_easy с параметром “make”, чтобы форсировать сборку.
Сделана поддержка ipv6. Она и раньше была в tpws, nfqws, но сейчас она пронесена через все компоненты.
tpws получил дополнительные функции для привязки к определенным IP и возможности по ожиданию готовности интерфейсов,
возможность чтения hostlist-ов в формате gzip
Логика управления соединениями в tpws переписана на использование неблокирующих сокетов, устранены многочисленные потенциальные проблемы кода, унаследованного у взятого где-то в сети примера не лучшего качества
nfqws больше не требует рута для работы, ограничиваясь сбросом capabilities до CAP_NET_ADMIN.
В tpws и nfqws кроме --user добавлена возможность установки uid:gid через параметр --uid. Это полезно на android, поскольку там нет /etc/passwd.
Написана документация по настройке policy based routing на примере wireguard.
Описан метод модификации wireguard для противостояния возможным попыткам заблокировать VPN протоколы на DPI (суверенный рунет).

Изменения сентябрь 2019

Выяснилось откуда в реестре появляется миллион+ IP и этот список неудержимо растет.
Автоматическое распознавание телеграм прокси.
Вот вы сидите в метро через wifi, тыкаетесь в новонайденный телеграм прокси.
А вас снифают. И сливают инфу РКН.
Переработаны скрипты получения ipset.
Добавлена поддержка листов с https://antifilter.network на замену get_antizapret.
умные префиксированныо-вычищенные листы оставляют нас всего лишь с десятками тысяч префиксов, что запросто потянет роутер с 64 Mb RAM
Переработано получение листов непосредственно из реестра (get_reestr_*.sh)
бывший get_reestr.sh переименован в get_reestr_resolve.sh. Это скрипт для самостоятельного ресолва доменов из реестра через mdig.
На смену get_combined.sh пришел get_reestr_combined.sh. Теперь он работает только с реестром, не используя другие листы.
get_reestr_ip.sh подтягивает IP в том виде, в каком они значатся в реестре
get_reestr_ip, get_reestr_combined поддерживают теперь ipv6. Оба убирают мусор , которым на данный момент считается телеграм
В ip2net добавлена поддержка ipv6 и настройка параметров через командную строку. create_ipset.sh обновлен до поддержки этой функции.
Параметры ip2net вынесены в config

Добавлена поддержка режима socks4/5
Он не требует повышенных привилегий, рута
может использоваться на нерутированных android устройствах с программами, поддерживающими socks или через хитрые методы прозрачного заворота через tun

Для разработки программы, которая бы использовала zapret, можно взять исходный код программы Intra или какого-нибудь проксификатора (например, shadowsocks). Почти все подобные программы используют badvpn tun2socks.

Лично у меня совсем нет опыта в android development, и вряд ли я начну делать аппликуху сам. Но если кто желает, пожалуйста.
Хотя, если так подумать, то при таком подходе зачем нужен бинарик tpws ? Ведь можно то же самое и на яве соорудить. Не зависеть от платформы.
С tpws преимущество разве что в скорости немного. Но я не думаю, что это существенно для мобильников

Можно сделать универсальную аппликуху для рута и без рута. Если рут, то адвансед моде и тпвс в транспарент режиме, иначе через выкрутасы

В tpws добавлена опция --hostpad=
Добавляет паддинг-хедеров перед Host: на указанное количество байтов
Полезно против DPI, выполняющих реассемблинг TCP с ограниченным буфером.
Если техника работает, то после некоторого количества bytes http запрос начнет проходить до сайта.
Если при этом критический размер padding около MTU, значит скорее всего DPI не выполняет реассемблинг пакетов, и лучше будет использовать обычные опции --split-…
Если все же реассемблинг выполняется, то критический размер будет около размера буфера DPI. Он может быть 4K или 8K, возможны и другие значения.

Реализована атака десинхронизации DPI для http и https. За основу взята идея от ValdikSS.

Очень крутая и полезная вещь, у нескольких хостеров (включая Селектел) отлично работает, что позволяет пользоваться запрещёнкой без оверхеда на VPN с большим RTT.
Спасибо!

Речь про десинхронизацию или другие опции ?
Пока про десинхронизацию у меня нет отзывов, тестирование было крайне ограниченным

Да, речь про десинхронизацию и она прекрасна своей изящностью в сочетании с минимальным оверхедом.

Добавлен выбор режима десинхронизации DPI.
На текущий момент это может быть

• поддельный пакет с разрешенным запросом : --dpi-desync без параметра или --dpi-desync=fake
• пакет сброса соединения : --dpi-desync=rst

Добавлен режим disorder для dpi-desync.

В этом режиме пакет с http request или tls client hello разбивается на 2 части. Отсылка идет следующим образом :

1. 2-й сегмент
2. поддельный 1-й сегмент
3. 1-й сегмент
4. поддельный 1-й сегмент

цель атаки - максимально усложнить DPI реконструкцию сообщения, по которому принимается решение о блокировке

Исправлен баг, при котором была невозможна отправка поддельных пакетов ipv4 и ipv6 с одного процесса nfqws. Для 4 и 6 теперь используются разные raw сокеты.

Добавлен режим --dpi-desync-fooling=badseq. Испорченные sequence numbers в поддельных пакетах.
Возможно сочетание любых режимов через запятую : --dpi-desync-fooling=badseq,badsum,md5sig

Отработана схема использования nfqws на мобильных модемах Huawei.
Проверено на E8372. Вероятно работает на E3372 с минимальными модификациями.
Возможно, на других устройствах.

Изменение window size в nfqws считается устаревшим и более не поддерживается в скриптах.
На замену ему приходит более быстрая альтернатива --dpi-desync=split2, лишенная других недостатков wsize (типа невозможности заменить регистр Host: при --wsize=3 на пакетах от linux клиента)

В свете последних изменений переписана вводная часть readme.

Не планируете интеграцию наработок https://github.com/Kkevsterrr/geneva ?

Универсальный тампер движок портировать с питона не планирую
Но по мере необходимости готов добавлять новые стратегии, работающие в exUSSR

Изменение поведения опций сплита в tpws.

Теперь tpws в состоянии распознавать не только http, но и TLS ClientHello.
split-http-req может применяться совместно с split-pos. Если блок данных является http запросом, будет применяться split-http-req, в ином случае split-pos.
split-pos по умолчанию работает только с http и TLS ClientHello. Если вам нужно сплитать все остальное, укажите --split-any-protocol.
–hostlist так же теперь работает со SNI из TLS ClientHello.

В config параметры TPWS_OPT_HTTP и TPWS_OPT_HTTPS удалены, вместо них единый TPWS_OPT.

Простой инсталятор и скрипты запуска адаптированы, чтобы более не запускать по отдельному инстансу на http и https. Добавлен режим tpws_hostlist_https.

В продолжение предыдущего.

В tpws добавлена возможность биндаться на множество адресов.
Параметры --bind-addr и --bind-iface* начинают новый бинд. Следующие параметры --bind-wait*, --bind-linklocal относятся к последнему бинду.
Если хотите указывать link-local явно в --bind-addr, то теперь к нему надо добавлять %interface_name.
Например : fe80::1111:2222:3333:4444%br-lan
Если явно не создан ни один бинд, то в целях совместимости параметров создается бинд по умолчанию на все адреса.

init скрипты адаптированы, чтобы запускать только 1 tpws в любых случаях. Ранее их могло быть до 6 шт.
Особую проблему это представляло при использовании hostlist. Каждый инстанс подгружал свой hostlist. RAM это съедало до 6 раз больше, чем могло бы быть. На soho роутерах и листах от РКН это означало невозможность использования в такой конфигурации

8 posts were merged into an existing topic: Обсуждение

Сделана экспериментальная поддержка flow offloading в openwrt , включая простой инсталятор
В openwrt flow offloading работает только глобально. Либо включено, либо выключено. nfqws не работает с включенным offloading.
Скрипты zapret теперь сами в состоянии выборочно управлять трафиком, который идет на offload, отключая при этом системную установку. То есть в люси у вас будет чекбоксик выключен, но оффлоад на самом деле будет работать там, где он не мешает nfqws

Тестировалось только на software flow offloading, на hardware возможности проверить нет
Если кто-то может проверить, буду благодарен.

Сделал рефакторинг системы управления режимами. Вместо впихивания нескольких опций в один строковый параметр MODE, эти опции теперь разделены по разным переменным.
Поддержка keep alive в nfqws больше не требует custom скрипта. Она теперь вшита в основной функционал.

# CHOOSE OPERATION MODE
# MODE : nfqws,tpws,filter,custom
# nfqws : use nfqws
# tpws : use tpws
# filter : no daemon, just create ipset or download hostlist
# custom : custom mode. should modify custom init script and add your own code
MODE=tpws
# apply fooling to http
MODE_HTTP=1
# for nfqws only. support http keep alives. enable only if DPI checks for http request in any outgoing packet
MODE_HTTP_KEEPALIVE=0
# apply fooling to https
MODE_HTTPS=1
# none,ipset,hostlist
MODE_FILTER=none

Добавлена проверка на подмену DNS в простой инсталятор install_easy.sh
Инсталятор сам не будет решать проблему DNS за вас, но предупредит о возможной подмене

Было замечено, что virtualbox и vmware ломает большинство техник nfqws, если сеть настроена в режиме NAT.
Принудительно заменяется TTL на ttl хоста, не проходят фейковые ретрансмиссии
Необходимо настраивать VM в режиме bridge
Ожидаемо так же не работает и GoodbyeDPI с --set-ttl

В nfqws добавлена возможность комбинирования режимов десинхронизации
Режим 1-й фазы может быть fake,rst,rstack. Режим 2-й фазы может быть disorder,disorder2,split,split2.
Пишем через запятую : --dpi-desync=fake,split
Может быть полезно, когда у провайдера стоит не один DPI.
–dpi-desync без параметров раньше приравнивался к fake. Теперь это больше не поддерживается, требуется явное указание режима.

Ограниченная поддержка систем FreeBSD и OpenBSD
работают mdig, ip2net, tpws
на FreeBSD полностью работоспособны скрипты ipset/*.sh. Они заполняют ipfw lookup tables.
тестировалось на FreeBSD 12.2 и OpenBSD 6.8. на значительно более старых скорее всего будут проблемы
портирование nfqws напрямую невозможно. nfqueue в BSD отсутствует в принципе. нужно искать другой аналогичный механизм

Добил поддержку FreeBSD и OpenBSD.
На замену nfqws пришел dvtws. Это nfqws, собираемый под divert sockets.
Работает почти точно так же, как nfqws. Разница только в способах перенаправления трафика.
ipfw команды или pf.conf вместо iptables

Экспериментально. Тестируйте, кто может.

Ограниченная поддержка MacOS.
Яблочники там убрали все самое вкусное, поэтому dvtws и tpws в прозрачном режиме не завести.
Работает tpws socks. Его можно сделать прозрачным через приложение Proxifier (на не совсем новых версиях macos ставит свой модуль ядра).
Скрипты ipset/*.sh работают после установки через brew некоторых GNUшных программ взамен устаревшим имеющимся в macos.
Описание в docs/bsd.txt

Прозрачный режим tpws в MacOS.
Яблочники убрали net/pfvar.h, где находятся определения, необходимые для получения оригинального адреса в прозрачном режиме.
Взял из старых версий яблочного SDK. Сработало. Они изменили некоторые структуры, поэтому вариант из BSD не работал.
Но теперь это недокументировано, и запросто могут еще что-нибудь поубирать в будущих версиях.

Сделан install_easy.sh для MacOS
Поддерживается весь стандартный набор, но только для tpws
Internet sharing не поддерживается !! При его включении PF начинает функционировать странно.
Редиректы не работают. При выключении все лишние anchor-ы убираются, состояние становится как до включения, но редиректы уходят в никуда.
Лечится только через pfctl -f /etc/pf.conf. В причинах пока не разобрался. Возможно, какие-то хитрости яблочников, выходящие за пределы стандартного поведения PF

В простой инсталятор внесен режим socks.

Редизайн выбора LAN и WAN интерфейсов на десктопных системах.
В этом процессе есть ряд важных нюансов, которые нужно осознавать, включая фильтрацию по интерфейсам.
Они описаны в readme в разделе “простая установка”

Новая схема дурения DPI, которые секут не только TLS ClientHello, но и ServerHello.
Как же с этим бороться ? Сложно заставить сервер посылать не то, на что он запрограммирован.
Лучшее решение было бы всем перейти на TLS 1.3, где ServerHello шифрован.
Но переход идет вяло. Владельцы серверов годами остаются на давно настроенных и стабильных системах. Потому там может быть только TLS 1.2.
Но кое-что все-таки сделать можно. Почему бы не возродить старую идею со сменой winsize, только наоборот ?
В nfqws добавлен параметр --wssize=<window_size>[:<scale_factor>]
Он позволяет менять window size и scale factor для сервера до тех пор, пока не будет отослан запрос, на который должен придти фрагментированный ответ, затем перестать менять winsize, чтобы вернуть скорость.
Менять winsize и scale factor надо во всех пакетах от начала соединения до отсылки TLS ClientHello, иначе это не сработает на linux серверах.
Типичное использование --wssize=1:6. scale_factor - это степень двойки, на которую умножается winsize.
Чем он больше, тем потом будет выше скорость, однако если его сделать слишком большим, то не будет достигнута цель, а если слишком малым - потом будут тормоза.
Для http такая схема бесполезна, поэтому заодно введена возможность в скриптах отдельно настраивать опции дурения nfqws для http и https

Код:

NFQWS_OPT_DESYNC="--dpi-desync=fake --dpi-desync-ttl=0 --dpi-desync-fooling=badsum"
#NFQWS_OPT_DESYNC_HTTP="--dpi-desync=split --dpi-desync-ttl=0 --dpi-desync-fooling=badsum"
#NFQWS_OPT_DESYNC_HTTPS="--wssize=1:6 --dpi-desync=split --dpi-desync-ttl=0 --dpi-desync-fooling=badsum"

Для http берется NFQWS_OPT_DESYNC_HTTP, если он пустой - NFQWS_OPT_DESYNC
Для https берется NFQWS_OPT_DESYNC_HTTPS, если он пустой - NFQWS_OPT_DESYNC
Схема себя показала эффективной против ТСПУ, даже без fake, но со split

Режим десинхронизации synack. Отсылаем SYN,ACK перед SYN.
Попытка убедить DPI , что роли клиента и сервера перепутаны.
Работает только если между атакующим девайсом и DPI нет NAT.
Если верить geneva, возможно сработает в KZ (если уже не пофиксили)

Добавил поддержку openrc в install_easy.sh
Проверено на nitrux и alpine.
alpine - сильно обрезанная система, отсутствуют по умолчанию ip(6)tables
Делать автоустановку не стал, чтобы не привязываться к специфической для обрезанной системы пакетной базе : apk add iptables ip6tables
Должно работать и на gentoo при условии ручной установки ipset : emerge ipset

Более надежное определение systemd. Некоторые дистрибутивы оставляют systemctl и юниты, хотя systemd там отсутствует

Для облегчения интеграции с обрезанными системами и прошивками sysv init доработан до поддержки максимально спартанских условий. Может теперь работать с разными adduser/useradd или вовсе без них. Поддержка readonly root.
Имея rw /opt, туда можно установить entware, необходимые проги, и все, что не дает использовать zapret на полную, это лишь отсутствующие модули ядра. Тут ничем помочь не могу.

Сделан собственный скрипт для автоматизации проверки стратегий обхода DPI через nfqws - blockcheck.sh
Его следует запускать, когда любые инструменты обхода блокировок неактивны.
Проверка подмены DNS убрана из install_easy.sh и перенесена в blockcheck.sh

Реализовано задание раздельных опций nfqws для http и https и для версий ip протоколов 4,6 :

NFQWS_OPT_DESYNC_HTTP="--dpi-desync=split --dpi-desync-ttl=0 --dpi-desync-fooling=badsum"
NFQWS_OPT_DESYNC_HTTPS="--wssize=1:6 --dpi-desync=split --dpi-desync-ttl=0 --dpi-desync-fooling=badsum"
NFQWS_OPT_DESYNC_HTTP6="--dpi-desync=split --dpi-desync-ttl=5 --dpi-desync-fooling=none"
NFQWS_OPT_DESYNC_HTTPS6="--wssize=1:6 --dpi-desync=split --dpi-desync-ttl=5 --dpi-desync-fooling=none"

Если какая-то из переменных NFQWS_OPT_DESYNC_HTTP/NFQWS_OPT_DESYNC_HTTPS не определена, берется значение NFQWS_OPT_DESYNC.
Если какая-то из переменных NFQWS_OPT_DESYNC_HTTP6/NFQWS_OPT_DESYNC_HTTPS6 не определена, берется значение NFQWS_OPT_DESYNC_HTTP/NFQWS_OPT_DESYNC_HTTPS.
Значит, если определено только NFQWS_OPT_DESYNC, то все 4 специализированные переменные берут это значение.
Зачем это надо : вряд ли ttl будет одинаковым для ipv4 и ipv6. Если для ipv4 он окажется 9, то таким ttl вы вполне можете начать рубить сайты на ipv6

Скрипты всеми силами стараются минимизировать количество процессов nfqws, чтобы сохранить память. Для роутеров это важно, а если используется hostlist, то 4 процесса nfqws легко забьют и 256 Mb. Если для разных вариантов используются одни параметры, то запускается только один процесс с ними.

В nfqws добавлен параметр --dpi-desync-ttl6, задающий отдельное значение для ipv6 hop limit.
Если --dpi-desync-ttl6 не указан, то берется значение --dpi-desync-ttl. Чтобы отключить hop limit на ipv6 используйте --dpi-desync-ttl6=0.
Параметр позволяет не запускать лишний процесс nfqws, когда стратегия обхода для ipv4 и ipv6 отличается лишь ttl.

В blockcheck.sh добавлена поддержка FreeBSD через фаервол ipfw
Необходима загрузка модулей ipfw.ko и ipdivert.ko

В nfqws добавлена возможность настройки дурения badseq.
Можно указать инкремент seq и ack_seq в виде знакового десятичного числа или знакового hex числа (1000,-1000,0x8000,-0x8000)

--dpi-desync-badseq-increment=<int|0xHEX> ; badseq fooling seq signed increment. default -10000
--dpi-desync-badack-increment=<int|0xHEX> ; badseq fooling ackseq signed increment. default -65000

Изменены значения по умолчанию. Раньше инкремент для обоих параметров был 0x80000000.
Как оказалось, на некоторых провайдерах дурение badseq работает только в пределах ограниченного окна от текущего seq.

В nfqws добавлен параметр --dpi-desync-fake-unknown=<filename>
в нем указывается файл, который будет отсылаться в качестве фейка при --dpi-desync=fake --dpi-desync-any-protocol
и обработке не http запроса и не TLS ClientHello вместо стандартного пакета из 256 нулей

cutoff теперь имеет 3 варианта ограничителя
n - номер пакета, начиная с 1
d - номер пакета с данными, начиная с 1
s - relative sequence number. он равен количеству переданных от клиента байтов + 1
Отсечение происходит, если параметр равен или больше заданного значения.

--wssize-cutoff=[n|d|s]N               ; apply server wsize only to packet numbers (n, default), data packet numbers (d), relative sequence (s) less than N
--dpi-desync-cutoff=[n|d|s]N           ; apply dpi desync only to packet numbers (n, default), data packet numbers (d), relative sequence (s) less than N

Вкратце поясню зачем вся эта котовасья.
Представьте , что настал очередной печальный день в истории рунета, и РКН решил заблокировать SMTP (тут можете подставить ваш любимый протокол, телеграм, допустим). Шлите почту только через авторизованные сервисы, где сидит тов. майор. SMTP протокол распознается и режется на ТСПУ.

Задача точно такая же, как и в случае http/https. Сделать так, чтобы DPI не понял, что это SMTP.
Но так случилось, что абы чего DPI не пропускает. Левые протоколы тоже стали резать.
Надо подсунуть что-то безобидное. Например, http запрос.
И делать это до того момента, как начнется шифрованная фаза (ведь вы конечно же не будете слать почту без TLS ?)
Обычно при отсылке почты через SMTP клиент выдает 2 открытых сообщения “EHLO servername” и “STARTTLS”, потом идет TLS handshake.

nfqws --qnum=250 --dpi-desync-any-protocol --dpi-desync-cutoff=d4 --dpi-desync=fake,split2 --dpi-desync-ttl=5 --dpi-desync-fake-unknown=/opt/zapret/files/fake/fake_http_req_example.bin

Будут обработаны первые 3 исходящих пакета TCP соединения с данными (то есть не будут в нумерации учтены пустые пакеты с ACK)
Будут отосланы следующие сообщения : Будут отосланы следующие сообщения :

фейк : GET / HTTP/1.1 ... Host: iana.org
реал : EH
реал : LO mail.myserver.com
фейк : GET / HTTP/1.1 ... Host: iana.org
реал : ST
реал : ARTTLS
фейк : TLSClientHello от w3.org
реал : TLSClientHello от mail.myserver.com - первые 2 байта
реал : TLSClientHello от mail.myserver.com - остальные байты

после этого наступает состояние desync-cutoff (отсечение desync).
nfqws больше не трогает это соединение, чтобы не замусоривать канал всякой ерундой и не снижать скорость

если добавите --debug, все станет понятно из лога nfqws

Разумеется, описанный сценарий пока чисто гипотетический, он служит лишь для иллюстрации техники. Будет ли это работать и с какими нюансами - покажет время.
Если тупо забанят 25 порт или по IP startmail, protonmail, … - не сработает точно

Реализован задел для десинхронизации udp протоколов.
Нацелено прежде всего всего на quic и dht, хотя далеко не только.
Поддерживается только режим десинхронизации fake, поскольку фрагментация udp невозможна на транспортном уровне. Возможна только ip фрагментация - она пока не реализована.
Fake нацелен на атаку на stateful DPI и бесполезен для stateless.

quic - новый протокол для доступа к сайтам по http3. Полностью шифрован. DPI вынужден будет расшифровывать непростым алгоритмом каждый пакет, чтобы хотя бы выдернуть SNI. Слишком дорого для stateless анализа и слишком опасно быть за-ddos-еным. Потому если ему скормить фейк, это может решить вопрос. Пока еще тестировать не на чем, но все впереди. Возможно, будут просто резать quic.

DHT бутстрап выполняется по UDP. Уже однажды пытались его заблокировать. Исследователи сообщали, что если перед запросом скормить левый udp пакет с теми же source/dest port, то DPI отстает от UDP канала до истечения таймаута неактивности.

Задействование атаки на первый исходящий пакет данных :

iptables -t mangle -I POSTROUTING -p udp --dport 443 -j NFQUEUE --queue-num 200 --queue-bypass
nfqws --qnum=200 --dpi-desync-any-protocol --dpi-desync=fake --dpi-desync-ttl=5 --dpi-desync-cutoff=d2

Фулинг работает только по ttl и badsum. Другое к udp неприменимо.
Можно заменить fake payload так : --dpi-desync-fake-unknown-udp=/opt/zapret/files/fake/fake_quic_initial_example.bin

Реализована фрагментация ipv4 и ipv6 на уровне ip : --dpi-desync=ipfrag2
К сожалению, это не прорыв, а скорее научный интерес. Современная сеть крайне враждебна к IP фрагментации.
Фрагментированные пакеты часто застревают или пересобираются/перефрагментируются по пути.
Часто их отбрасывают принимающие узлы, возможно как мера против ddos атак.
Linux всегда пересобирает проходящие (forwarded) фрагментированные ipv6, если это возможно.
Но как последнее средство для какой-то конкретной цели при соблюдении определенных условий теоретически может сработать
Можно проверить с некоторой долей вероятности сработает ли обход на конкретном ресурсе через команду ping с размером пакета >1472.
Если обычный пинг ходит, а длинный не ходит, то фрагментация режется.

IP фрагментация доступна для tcp и udp протоколов.
Возможно, с cutoff хороший вариант для доступа к своему wireguard серверу в случае блокировки wireguard протокола, если провайдер и хостер не режут фрагменты

Обеспечена совместимость с последними версиями pfsense.
Добавлены бинарики , собранные на FreeBSD 11 x64. Они должны работать на системах с ядром FreeBSD 11 и выше.
Хотя они и запускаются как минимум на FreeBSD 10, бинарик dvtws нельзя использовать на этих системах !
В коде присутствует условная компиляция , исправляющая баг/фичу FreeBSD 10.x и более старых.
На более старых системах нужно собирать самостоятельно, при этом скорее всего придется обновлять и компилятор CLang не из репозитория. Эти системы уже out-of-support, могут быть даже проблемы с удаленными с серверов репозиториями. Лучше проапгрейдиться

Для запуска в pfsense требуется выполнить ряд действий, описанных в docs/bsd.txt

Только для ipv6 режим десинхронизации hopbyhop, fooling hopbyhop,hopbyhop2.

Fooling : добавляется ipv6 extenstion header “hop-by-hop options” во все фейки.
В варианте hopbyhop2 добавляются 2 хедера, что является нарушением стандарта и гарантированно отбрасывается стеком протоколов во всех ОС. Один хедер hop-by-hop принимается всеми ОС, однако на некоторых каналах/провайдерах такие пакеты могут фильтроваться и не доходить. Расчет идет на то, что DPI проанализирует пакет с hop-by-hop, но он либо не дойдет до адресата всилу фильтров провайдера, либо будет отброшен сервером, потому что хедера два.

Desync: (не путать с fooling !) заключается в добавлении хедера “hop-by-hop options” во все оригинальные пакеты, попадающие под десинхронизацию. Здесь надо обязательно понимать, что добавление хедера увеличивает размер пакета, потому не может быть применено к пакетам максимального размера. Это имеет место при передаче больших сообщений. В случае невозможности отослать модицифированный пакет дурение будет отменено, пакет будет выслан в оригинале.
Расчет идет на то, что DPI увидит 0 в поле next header основного заголовка ipv6 и не будет скакать по
extension хедерам в поисках транспортного хедера. Таким образом не поймет, что это tcp или udp, и пропустит пакет без анализа. Возможно, какие-то DPI на это купятся.
Может сочетаться с любыми режимами 2-й фазы.
Например, “hopbyhop,split2” означает разбить tcp пакет на 2 сегмента, в каждый из них добавить hop-by-hop.
При “hopbyhop,ipfrag2” последовательность хедеров будет : ipv6,hop-by-hop,fragment,tcp/udp.
При поступлении пакета ipv4 режим hopbyhop игнорируется, но работает десинхронизация 2-й фазы, если таковая имеется.
Может применяться как к tcp, так и к udp.

Добавлены режимы десинхронизации ipv6 destopt и ipfrag1.
Заключаются в добавлении хедеров “destination options” и “fragment” (фрагмент единственный).
В thc-ipv6 toolkit есть прога firewall6. Она пытается применить различные экзотические комбинации extension headers для проверки что пропускается, а что нет.
hopbyhop часто режется. на 2 провайдерах проверил. destopt и единственный фрагмент обычно не режутся.
остается понять как будут DPI воспринимать эти хедеры. будут ли они реагировать.
пока не на чем проверить

По поводу режима ipfrag1 внимательно читать комментарии по IP фрагментации в readme.txt
Обычно для ухода фрагментов ipv6 с локальной системы (OUTPUT) достаточно занести эти пакеты в notrack, но если фрагмент только один, fragment header может быть молча убран модулем nf_defrag_ipv6.
Как повезет. На некоторых системах это случается, на некоторых нет. Гарантии может дать только загрузка модуля ip6table_raw с параметром raw_before_defrag=1.
В openwrt нужно изменить файл вот так :

cat /etc/modules.d/ipt-raw6
ip6table_raw raw_before_defrag=1

и ребутнуть систему.

Проведен мощный рефакторинг скриптов запуска с целью поддержки nftables.
Основная мотивация - переход будущей версии OpenWRT на firewall4+nftables.
iptables уходят из мейнстрима openwrt, хотя могут быть доустановлены и использованы параллельно с nftables.
Но есть и некоторая нерешаемая боль, связанная с nftables, о которой можно почитать здесь :

https://github.com/bol-van/zapret/blob/master/docs/nftables_notes.txt

nftables можно использовать на linux с достаточно новыми версиями ядра и утилиты nft.
На OpenWRT nftables можно использовать, начиная с 21.xx. На более старых скорее всего будут проблемы.
На OpenWRT 21.xx в nftables недоступен hardware flow offloading и не будет работать software flow offloading,если есть названия интерфейсов , начинающихся с цифры. Обычно это происходит, когда включен ipv6 и имеется 6to4,6in4. (fixed в snapshot версиях после 21.x)

На более новых системах, где уже основной фаервол firewall4+nftables, можно переключить zapret на iptables.
Плюс - возможность использования больших ip lists на роутерах, минус - отсутствие поддержки flow offloading в любом варианте.

Что нужно понимать про скрипты запуска в OpenWRT : на системах с firewall3 при использовании iptables производится интеграция в fw3, как это было и раньше.
/etc/init.d/zapret {start,stop} не трогают фаервол
Вместо этого правила применяются через firewall include в /etc/config/firewall : /etc/firewall.zapret
При использовании nftables, либо iptables на системах с firewall4, управление фаерволом происходит в init скрипте, как это делается на традиционных linux.
В custom скриптах появилась отдельная функция для применения фаервола nft
В openwrt custom теперь в iptables функции требуется и стартовать, и останавливать правила, как это сделано в традиционном linux.
Функция стала полностью совместима с версией из sysv.
Еще одно небольшое новшество - написан openrc адаптер для запуска sysv init.
Оказалось, что некоторые системы с openrc (alpine linux), не автозапускают скрипты из /etc/init.d, если они не #!/sbin/openrc-run

Новости про nftables.

Выпустили, наконец, релиз nft 1.0.2.
Пофиксена проблема с кавычками в flowtable

Боль с количеством RAM и nfset-ами по прежнему там. Создал баг в багзилле netfilter.

В связи сами знаете с чем банят известные ресурсы типа МОРДО КНИГИ
Они используют QUIC. QUIC базируется на UDP и полностью зашифрован. Для DPI довольно сложно расшифровать QUIC , чтобы распознать домен. Потому начали на ТСПУ блочить QUIC. Видимо на все IP адреса, кроме whitelist (на ВКОНТАКТ QUIC не блокируется)
Точно блокируется на youtube, google, facebook.

Я сделал поддержку UDP в nfqws упреждающе (см выше мои посты). Она сработала как надо.
Вот это решает проблему :

iptables -t mangle -I POSTROUTING -p udp --dport 443 -m mark ! --mark 0x40000000/0x40000000 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:3 -j NFQUEUE --queue-num 205 --queue-bypass
nfqws --qnum=205 ---dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d4

Небольшое изменение в custom скриптах. Теперь необходимо указывать протокол “-p tcp” в фильтре zapret_custom_firewall
Написан custom скрипт custom-nfqws-quic4all, который наследует режим MODE=nfqws и включает обход блокировки QUIC на все адреса, вне зависимости от фильтра ipset/hostlist.

Как оказалось, движок QUIC от chromium ловит не только UDP, но и ICMP ttl expired in transit, связанные со своими UDPшками. Они приходят от фейк-пакетов с низким TTL. Как только броузер славливает такой ICMP, сеанс считает порванным, дальше ничего не проходит. Mozilla этим НЕ страдает.
Лечение : либо резать ttl expired in transit (нехорошо, поломаете трейсилки), либо отказаться от ttl fooling и заменить на любой другой, который сработает. Например, badsum.
А можно вообще убрать fooling. В этом случае фейки будут доходить до сервера, но поскольку там трэш, они будут отбрасываться процессом веб сервера.
Но если вы вдруг используете badsum и что-то на пути будет дропать пакеты с badsum (роутеры mediatek, заводские прошивки с linux), то обход не сработает
Проще и надежнее убрать fooling

В последнее время начали банить крупные сайты по типу facebook. У них прыгающий IP. Если ресолвить facebook.com и добавлять в ip list, то очень быстро перестает работать.
Можно использовать некоторые листы с antifilter.download, где эта проблема решена (например, allyouneed). Если это не вариант, теперь можно самому закидывать дополнительные ip из скрипта IPSET_HOOK в конфиге. Этот скрипт вызывается при каждом заполнении ipset/nfset/table с параметром $1=имя таблицы. IP адреса или подсети должны быть выведены в stdout.
Проблема пересечения интервалов в nfset решается автоматически. Об этом думать не нужно.
Если задана переменная LISTS_RELOAD, IPSET_HOOK будет вызван 1 раз без параметров.

Пример как добавить в таблицу zapret все IPv4 адреса из автономной системы facebook/instagram :

#!/bin/sh

# AS32934 - facebook,instagram

AS="32934"

aslist()
{
    whois -h whois.radb.net -- "-i origin AS$1" | sed -nre 's/^route: *(.*)/\1/p'
}

[ "$1" = "zapret" ] && {
    for as in $AS; do
        aslist $as
    done
}

Номера автономных систем перечисляются в переменной AS через пробел

реализовано определение протокола QUIC
теперь не обязательно указывать --dpi-desync-any-protocol, чтобы работать по QUIC initial
расшифровка QUIC initial и извлечение имени хоста, чтобы работал --hostlist, не поддерживается

К сожалению, было замечено на одном из провайдеров с ТСПУ, что начало QUIC сеанса устанавливается успешно, но пакеты вскоре внезапно перестают ходить, так что качество броузинга становится значительно хуже с таким QUIC, чем без него
причины пока не ясны

Еще немного по поводу IP фрагментации.

При использовании iptables и NAT, похоже, что нет способа прицепить обработчик очереди после NAT.
MASQUERADE является финальным таргетом, после него NFQUEUE не срабатывает.
Проходящий пакет попадает в nfqws с source адресом внутренней сети, затем фрагментируется и уже не обрабатывается NAT.
Так и уходит во внешюю сеть с src ip 192.168.x.x. Следовательно, метод не срабатывает.
Видимо единственный рабочий метод - отказаться от iptables и использовать nftables.
Хук должен быть с приоритетом 101 или выше.

В nftables скриптах от zapret реализован перехват пакетов в NFQUEUE после NAT. Там это сделать достаточно просто.
Но при этом если сгенерированные в nfqws пакеты не вводить в состояние notrack, то они заново процессятся NAT, происходит подмена src port. Потому добавлен хук predefrag, где эти пакеты помечаются как notrack. Дополнительно открывается путь , чтобы отсылать ipv6 фрагменты на ядрах 4.16+

Сделал расшифровку и анализ QUIC initial crypto frames в nfqws.
Теперь работает hostlist и видно куда лезем в режиме --debug

Алгоритм довольно сложный. Требует крипто библиотеки. Чтобы не тащить тяжелые зависимости, минимально необходимый код понадерган из разных исходников + написано своего
Нежатый бинарик вырос примерно на 20 кб

Реализованы режимы десинхронизации fakeknown и udplen
fakeknown - это то же самое, что fake, только применяется исключительно к распознанным протоколам, даже если выставлено --dpi-desync-any-protocol. При этом вторая фаза десинхронизации применяется как раньше.
udplen - режим, относящийся только к udp. Пакет увеличивается в размере, дополняясь нулями, на указанное в --dpi-desync-udplen-increment количество байт. По умолчанию - 2. Нацелено на обман DPI, ориентирующихся на размеры пакетов. Может сработать при условии, что протокол приложения не завязан жестко на размер udp payload и не обижается на изменение размера.
К сожалению, обмануть таким образом статистическое застревание QUIC на ТСПУ не удается

Сделал инструкцию для быстрого старта

nfqws теперь учитывает fwmark пакетов, попадающих к нему на обработку
если в результате обработки пакета nfqws генерит свой пакет, его fwmark будет не 0x40000000, а 0x40000000 | <original_fwmark>

добавлен алгоритм лечения проблемы неверного выбора исходящего интерфейса для сгенерированных пакетов
параметры --bind-fix4 и --bind-fix6
лечение идет через вызов bind() на raw socket и setsockopt SO_BINDTODEVICE
интерфейс назначения берется из NFQUEUE. куда оригинальный пакет уходил, туда и отправляем сгенеренные. это возможно как для OUTPUT, так и POSTROUTING
linux не был бы linux-ом, если бы это не работало по разному для ipv4 и ipv6

в случае отсутствия опции bind-fix для соответствующего семейства ip отправка идет так, как было раньше. то есть система решает сама
Проблема неверного выбора интерфейса может случиться, когда у вас несколько аплинков или присутствует policy routing на базе source ip.
Причина - особенности маршрутизации пакетов , отправленных через raw sockets.
Для сценария стандартного роутера LAN-WAN это не актуально

Удалось забороть хаотические зависания QUIC на ТСПУ при пробивке udp фейком.
Всего лишь вместо нулей надо слать достаточно длинный пакет с quic short header вместо нулей.

nfqws --qnum=210 --user=daemon --dpi-desync-fwmark=0x40000000 --dpi-desync=fake --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_short_header.bin
iptables -t mangle -I POSTROUTING -p udp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:3 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 210 --queue-bypass

Если использовать скрипты, то вариант custom с файлом custom-nfqws-quic4all
и параметром config

NFQWS_OPT_DESYNC_QUIC=“–dpi-desync=fake --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_short_header.bin”

Шифрованное содержимое особого значения не имеет, потому что DPI все равно не способен его расшифровать. Важен лишь первый байт, а точнее 2 его старших бита, и общая длина пакета.

Обновил инструкции по настройке policy routing openwrt → vps на базе wireguard .
Добавлены правила nftables и способ их прикрутки для новых версий openwrt.
Учтен новый статус wireguard. Он был включен в ядро linux 5.6.
Так же обновлен вариант для redsocks.

Информация для любителей кинетиков на стоковой прошивке, где есть entware.

NDMS имеет проприетарное ядро, где в параллель со стандартными средствами маркировки mark и ct mark имеется в skbuff еще 1 марк - проприетарный ndmmark.
Он был сделан, чтобы управлять логикой iptables, оставляя основной марк полностью свободным для юзера.

В частности, ndmmark используется для ограничения маскарада. Только пакеты с определенным ndmmark идут на маскарад. См iptables-save -t nat

Если вы пытаетесь обойти блокировку quic через nfqws, то nfqws в этом случае дропает первый UDP пакет с quic initial, затем отправляет фейк своими средствами, ничего не зная о ndmmark. Первый пакет создает запись в conntrack, и она будет без маскарада.
Все дальнейшие пакеты будут уходить на внешний интерфейс с source ip 192.168.x.x и дропаться провайдером.

Таким образом, вы заставляете nfqws работать не на обход, а на блокировку QUIC.
И это даже иногда делает экспиренс лучше, если вдруг у провайдера DPI плохо блокирует QUIC, позволяя сеансу пройти дальше initial, а затем обрывая поток.
Того же эффекта вы можете достичь просто блокируя порт udp:443 на выход. Для этого nfqws не нужен.

Для лечения посмотрите как устроены ваши цепочки и добавьте в нужную цепочку маскарад на исходящий интерфейс WAN. Это может быть , например, ppp0, если у вас pppoe.

Если используются скрипты от zapret в варианте sysv, то можно добавить лечение в custom.
Как-то так, но смотрите какие у вас реально цепочки (я за версии прошивок не ручаюсь), и какой внешний интерфейс.
Пример лечащей добавки в скрипт custom-nfqws-quic4all

zapret_custom_firewall()
{
        # $1 - 1 - run, 0 - stop

        local MODE_OVERRIDE=nfqws
        local f
        local first_packets_only="-m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:3"
        local desync="-m mark ! --mark $DESYNC_MARK/$DESYNC_MARK"

        zapret_do_firewall_rules_ipt $1

        f="-p udp --dport 443"
        fw_nfqws_post $1 "$f $desync $first_packets_only" "$f $desync $first_packets_only" $QNUM2

        # fix NDM kernel masquerade for nfqws
        ipta_add_del $1 _NDM_MASQ -t nat -o ppp0 -j MASQUERADE
}

Попал мне девайс Irbis TZ797 на android 8.1
Если запускать обработчик очереди NFQUEUE на пакеты с интерфейса с сотовой сети, при этом кабель USB не воткнут (нет зарядки), то ядро очень быстро частично виснет, так что перестают работать тач и физические кнопки. При этом в броузере может продолжать анимироваться картинка.
Выяснил, что проблема связана с UID. По умолчанию nfqws назначает себе UID 0x7FFFFFFF. Видимо, в более новых ведроидах (на 5 точно такого не было), процессы с такими UID могут ложиться в suspend, что блокирует обработку очереди , а на это завязаны вызовы ядра. И получаем то, что видим.
Лекарство : nfqws --uid 1
Перепробовал несколько вариантов из низких uid. Все не виснут.
Для nfqws не нужны специальные uid 3003,3004,3005.
Дело в том, что nfqws назначает себе привилегии cap_net_raw, cap_net_admin. Это необходимо для работы с nfqueue и raw sockets. Для android это является одним из разрешающих условий для доступа к сети, вне зависимости от uid.

Добавлена возможность усекания пакетов в режиме udplen (отрицательный increment). Более, чем до 1 байта, усечение не работает.
Может быть полезно, когда прога добавляет паддинг в пакет, который ни на что не влияет, не проверяется, однако DPI проверяет размер пакета на минимальную длину.
Усечение пакетов от стандартных программ может помочь.

Поддержка множественных листов включения и исключения.
Альтернативой ipset является использование tpws или nfqws со списком доменов.
Оба демона принимают неограниченное количество листов include (–hostlist) и exclude (–hostlist-exclude).
Все листы одного типа обьединяются, и таким образом остаются только 2 листа.
Прежде всего проверяется exclude list. При вхождении в него происходит отказ от дурения.
Далее при наличии include list проверяется домен на вхождение в него. При невхождении в список отказ от дурения.
Пустой список приравнивается к его отсутствию.
В иных случаях происходит дурение.
Нет ни одного списка - дурение всегда.
Есть только exclude список - дурение всех, кроме.
Есть только include список - дурение только их.
Есть оба - дурение только include, кроме exclude.
В системе запуска это обыграно следующим образом.
Присутствуют 2 include списка :
ipset/zapret-hosts-users.txt.gz или ipset/zapret-hosts-users.txt
ipset/zapret-hosts.txt.gz или ipset/zapret-hosts.txt
и 1 exclude список
ipset/zapret-hosts-users-exclude.txt.gz или ipset/zapret-hosts-users-exclude.txt
При режиме фильтрации MODE_FILTER=hostlist система запуска передает nfqws или tpws все листы, файлы которых присутствуют.
Если вдруг листы include присутствуют, но все они пустые, то работа аналогична отсутствию include листа.
Файл есть, но не смотря на это дурится все, кроме exclude.
Если вам нужен именно такой режим - не обязательно удалять zapret-hosts-users.txt. Достаточно сделать его пустым.
Поддомены учитываются автоматически. Например, строчка “ru” вносит в список “*.ru”. Строчка “*.ru” в списке не сработает.
Список доменов РКН может быть получен скриптами ipset/get_reestr_hostlist.sh или ipset/get_antizapret_domains.sh - кладется в ipset/zapret-hosts.txt.gz.
При фильтрации по именам доменов демон должен запускаться без фильтрации по ipset.
tpws и nfqws решают нужно ли применять дурение в зависимости от хоста, полученного из протокола прикладного уровня (http, tls, quic).

Обнаружилось, что в openwrt на базе nftables на самой типичной конфигурации реального роутера (bridge lan/wlan), не срабатывала схема включения hardware offload. Причина - проверка, чтобы все компоненты моста поддерживали hw offload. wlan его не поддерживает. Сделал, чтобы из моста выбирались только поддерживающие интерфейсы, и только они добавлялись в flowtable.

Интересная проблема обнаружилась с hardware flow offloading.
Стабильная версия openwrt 22.03 имеет ядро 5.10.
Только начиная с ядра 5.13 автоматически определяются физические интерфейсы под мостами, pppoe и vlan. До этого надо было как-то вручную определять порты моста, базовый ethernet device под vlan или pppoe, и только их совать в flowtable.
Для мостов и VLAN особых проблем нет. /sys/class/net/<iface_name> содержит ссылки lower_* на нужные интерфейсы. common/nft.sh из zapret умеет с таким работать. В случае hardware offload нижние девайсы определяются автоматом и засовываются в flowtable. Скрипт пытается туда засунуть и верхние, и нижние девайсы. Что проглотит - то и хорошо.

Но в случае pppoe не так все просто. Видимо нет очевидного способа определить что лежит под pppoe. В fw4 девайс определяется через вызов к netifd
“ifstatus wan” возвращает
“l3-device”: “pppoe-wan”
“device”: “eth0”
он и берется для засовывания в flow table

Пришлось и мне сделать нечто подобное. Но это работает только в openwrt.
Если вдруг каким-то образом у вас старенькая традиционная linux система с hw offload, которая не умеет засовывать в hw offload pppoe, то вам придется самому вписать добавление в flowtable физического интерфейса. Например, через hook. Впрочем, это весьма маловероятный случай
Лучшим решением будет проапгрейдить ядро.

Другое изменение : для традиционных linux и macos в конфиге теперь можно использовать отдельный список IFACE_WAN6 для исходящих ipv6 интерфейсов.

В правила nft внесен тестовый счетчик для проверки flow offload

nft list chain inet zapret  flow_offload

table inet zapret {
        chain flow_offload {
                oifname @wanif tcp dport 80 ip daddr @zapret ip daddr != @nozapret return comment "direct flow offloading exemption"
                oifname @wanif tcp dport 443 ct original packets 1-4 ip daddr @zapret ip daddr != @nozapret return comment "direct flow offloading exemption"
                meta l4proto { tcp, udp } flow add @ft
                meta l4proto { tcp, udp } counter packets 1227 bytes 75527 comment "if offload works here must not be too much traffic"
        }
}

Посмотрите текущий counter. Запустите speedtest. counter не должен увеличиваться сильно. Не должно быть никаких увеличивающихся мегабайтов.
Если они там есть - offload не работает.
Посмотрите какие интерфейсы занесены в flowtable.
Для software offload должны быть высокоуровневые интерфейсы (мосты, pppoe, vpn, …). Для hardware могут потребоваться лежащие под ними низкоуровневые интерфейсы (lan1, lan2, lan3, lan4). Общее правило - должны быть и входящие, и исходящие интерфейсы.
Если там их нет - значит что-то работает не так.

nft list flowtable inet zapret ft
table inet zapret {
        flowtable ft {
                hook ingress priority filter - 1
                devices = { br-lan, wan }
        }
}

Решил сделать свой сервис по обработке выгрузки реестра РКН.
Главная мотивация - отсутствие ipv6 в решениях от antifilter.network
Для получения листов используйте get_reestr_preresolved.sh и get_reestr_preresolved_smart.sh
Подробности тут https://github.com/bol-van/zapret/issues/130

В mdig добавлены опции --log-resolved и --log-failed
для создания логов успешных и провальных доменов

На http://list.nethub.fi появились листы проверенных доменов из реестра РКН, которые ресолвятся по ipv4, ipv6 и “ipv4 или ipv6” .
Как оказалось, примерно половина доменов из реестра не ресолвятся никак, фактические являясь трэшем

Блокировка QUIC все больше начала оформляться у провайдеров во что-то законченно-логичное вместо хаотических попыток что-то там заткнуть или заткнуть вообще весь протокол или порт.

На большинстве провайдеров сделана блокировка по SNI (идет расшифровка на DPI) как на ipv4, так и на ipv6, по списку заблокированных доменов.
Однако, модули распознавания QUIC initial видимо еще старые и кривые, потому могут сечь, например, curl с nghttp3 и chromium, но не сечь curl с quiche или firefox, потому блокировка может быть не видна с первого взгляда.
Как правило блокировки QUIC по SNI - stateful, поскольку анализировать каждый пакет в соединении чревато гигабитным флудом и залеганием DPI в bypass. Расшифровка QUIC - непростая операция. Это значит, что если DPI в сеансе UDP первым пакетом не видит ничего осудительного, то все остальное не анализируется.

Итак, QUIC внесен полностью в основные скрипты и инсталятор с поддежкой фильтрации по ipset/hostlist, аналогично http/https.
Особого смысла менять режим десинхронизации нет. Просто выбираете MODE=nfqws и отвечаете yes или no на “enable QUIC”. Дальше все само. По понятным причинам QUIC работает только с nfqws и не работает с tpws.

К сожалению, пока внести автопроверку на QUIC в blockcheck не представляется возможным, поскольку поддержка quic экспериментальна, и стандартные курлы http3 не поддерживают.
Потому можно посмотреть по F12 в броузере на facebook.com перешел ли он на HTTP3 после включения обхода.
Или лучше всего через curl --http3-only или посмотреть в wireshark udp port 443.
Прекомпиленые бинарики с поддержкой http3 можно загуглить для linux x86_64 и windows.
Если не обходится - выключайте.

Неплохой проект ByeDPI
Работает как прокси и не требует дополнительных привилегий в системе, тем не менее реализует режимы disorder2 и fake (последний может быть ненадежно).
Тем не менее содержит очень интересные идеи, до которых я бы раньше не догадался. Спасибо разработчику.
Вариант --disorder перенесен в tpws, обновлен blockcheck.
tpws имеет преимущества : работает в MacOS и не требует привилегий в режиме socks
Режим работает не так, как хотелось бы, в FreeBSD, OpenBSD и Windows вследствие особенностей ядра.

От переноса fake в tpws пока воздержался. Необходимо тестировать как он себя поведет на разных системах, поскольку используются потенциально ненадежные хаки.

Добавил в nfqws определение wireguard handshake initiation.
По крайней мере с тем блоком, что был недавно включен на ТСПУ, больше не потребуется --dpi-desync-any-protocol.
Что касается openvpn, то глубоко не изучал особенности его блокировки. Включат опять - будут смотреть имеет ли смысл добавлять определение протокола в nfqws

Заодно проверил работает ли увеличение длины пакета с wireguard. Не работает. Wg отбрасывает эти пакеты, так что --dpi-desync=udplen для wg не подходит. А было бы здорово, если бы работал. Диссектор из NDPI четко проверяет udplen==148

Сегодня стали блочить DHT.
Блокируются исходящие udp пакеты с длиной 101…399 , начинающиеся с “d1” и заканчивающиеся на “e”, с номерами src port 1025…65536. <=1024 не блокируются.
Блокировка stateful, но только в одну сторону. После пробивки с одной стороны аналогичные пакеты с другой стороны ходить не начинают.
Возможно, это связано с несколькими ТСПУ на пути : у исходящего провайдера, у входящего провайдера и на магистрали.
Некоторые DHT все же доходят с разных IP адресов. Предполагаю, что не на всех путях установлен ТСПУ, который считает пакет исходящим. Бывает не доходит даже из-за бугра, где нет ТСПУ (но может быть на магистрали).

Создан custom script custom-nfqws-dht4all.

nftables фильтр : ct original packets 1 meta length 109-407 meta l4proto udp @th,64,16 0x6431
iptables фильтр : -p udp -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:1 -m length --length 109:407 -m u32 --u32 ‘0>>22&0x3C@8>>16=0x6431’
ip6tables фильтр : -p udp -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:1 -m length --length 109:407 -m u32 --u32 ‘48>>16=0x6431’
nfqws : --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d2 --dpi-desync-ttl=5

(длина считается вместе с udp заголовком 8 байт)

Возможно, ситуация связана с выборами, и скоро отключат, но надо быть готовым

Сделал поддержку параметра nfqws --dpi-desync-udplen-pattern.
Можно задать файл или hex строку, которой добиваются udp пакеты при режиме десинхронизации udplen.
Теперь везде, где nfqws раньше читал файл, можно указывать как имя файла, так и HEX строку, которая начинается с 0x

Сделал распознавание протокола DHT. Распознается как udp, начинающийся с d1, кончающийся e (соответствует фильтру ТСПУ).
Новый режим десинхронизации tamper.
Этот режим предназначен для корректной модификации известных пейлоадов, чтобы DPI их не распознавал, но пейлоад оставался корректным и нес ту же смысловую нагрузку.
Для DHT это вставление строки “2:001:x” после “d” в начале. Вставляется ничего не значащий элемент в bencode dictionary с длиной ключа 2, вместо 1. Таким образом dht начинается с d2.

Этот метод может помочь, если вдруг сделают блокировку stateless. fake против stateless не работает

Нашел средство обьединять подсети.
ip2net работает только с отдельными IP адресами, пропуская подсети как есть.
Это позволило существенно сократить размер листов с list.nethub.fi
Для роутеров с nft и обьемом памяти <256 Mb это крайне актуально

Принципиально новый способ дурения через tpws : --tlsrec
Разбиение ClientHello на уровне TLS Record. Одну TLS record нарезаем на две в одном TCP сегменте (при желании потом и это можно разделить на 2 tcp сегмента через --split-pos и перепутать порядок пакетов --disorder).
Режем или прямо по хосту в SNI, что исключает бинарный поиск паттерна без парсинга протокола, или на указанной байтовой позиции.
Говорят, работает даже на китайском фаерволе.

Метод хороший, но ломает различные ddos защиты, потому где-то 10% сайтов обломаются. gosuslugi не работают. Без фильтра использовать нецелесообразно.

В России не работает на TLS 1.2, поскольку rdp-шный DPI еще смотрит на сертификат из ответа сервера TLS ServerHello. Это можно обойти через комбо с nfqws --wssize.

Удивительно, но многие серьезные сайты все еще не поддерживают TLS 1.3
Среди них сбер, другие банки, гос услуги, mail.ru
Среди заблокированных точно не поддерживает lostfilm.tv

Вышел недавно openwrt 23.05.
Принципиальных изменение по сравнению с 22.03.05 в нем не так много.
Но есть одно, касающееся zapret.
openwrt перешел по умолчанию на mbedtls вместо wolfssl. mbedtls не поддерживает TLS1.3
Следовательно при использовании штатного curl не работают методы проверки TLS 1.3 в blockcheck. Сам blockcheck предупреждает, что libcurl не поддерживает TLS1.3.

Что можно сделать для решения этой проблемы :

1. Взять статический бинарик с GitHub - bol-van/bins: precompiled static binaries for android
   и заменить им родной. если у вас почти нет места, можно записать его в какую-нибудь директорию в /tmp, затем добавить в PATH в начало эту директорию. временное решение только для проверки blockcheck
2. Пересобрать openwrt с libcurl, базированном на другой tls library. Например, openssl. Заодно поискать какие пакеты зависят от wolfssl или mbedtls и заменить там preferred tls library. Так можно попытаться вообще убрать mbedtls, чтобы он не занимал места.
3. Не пересобирать весь openwrt, а взять SDK одноименной версии, собрать libcurl с другой TLS library, взять из bin ipk пакеты только самого libcurl и его зависимости , установить на openwrt, замещая текущие. Проверить, что ничего не сломалось.
4. Не запускать blockcheck на роутере, а вместо этого использовать виртуалку с linux, отключив предварительно zapret на роутере. Не забыть, что найденные TTL следует уменьшить на 1, чтобы стратегия была корректной для рутера.

TLS1.2 - более жесткий случай. Если какие-то стратегии работают на 1.2, они будут работать и на 1.3.
Проверка 1.3 нужна только, если не удалось найти рабочий вариант для 1.2. Чтобы хоть как-то работало.

Режим фильтрации autohostlist

Этот режим позволяет проанализировать как запросы со стороны клиента, так и ответы от сервера.
Если хост еще не находится ни в каких листах и обнаруживается ситуация, похожая на блокировку,
происходит автоматическое добавление хоста в список autohostlist как в памяти, так и в файле.
nfqws или tpws сами ведут этот файл.
Чтобы какой-то хост не смог попась в autohostlist используйте hostlist-exclude.
Если он все-же туда попал - удалите запись из файла вручную и перезапустите tpws/nfqws
или дайте им сигнал HUP, чтобы они перечитали листы.
tpws/nfqws сами назначают владельцем файла юзера, под которым они работают после сброса привилегий, чтобы иметь возможность обновлять лист.

В случае nfqws данный режим требует перенаправления в том числе и входящего трафика.
Крайне рекомендовано использовать ограничитель connbytes, чтобы nfqws не обрабатывал гигабайты.
По этой же причине не рекомендуется использование режима на BSD системах. Там нет фильтра connbytes.

Как вообще могут вести себя DPI, получив “плохой запрос” и приняв решение о блокировке :

1. Зависание : просто отмораживается, блокируя прохождение пакетов по TCP каналу.
2. RST : отправляет RST клиенту и/или серверу
3. Редирект : (только для http) отправляет редирект на сайт-заглушку
4. Подмена сертификата : (только для https) полный перехват TLS сеанса с попыткой всунуть что-то
   свое клиенту. Применяется нечасто, поскольку броузеры на такое ругаются.

nfqws и tpws могут сечь варианты 1-3, 4 они не распознают.
Всилу специфики работы с отдельными пакетами или с TCP каналом tpws и nfqws распознают эти ситуации по-разному.
Что считается ситуацией, похожей на блокировку :

1. [nfqws] Несколько ретрансмиссий первого запроса в TCP сеансе, в котором имеется hostname.
2. [nfqws,tpws] RST, пришедший в ответ на первый запрос с хостом.
3. [nfqws,tpws] HTTP редирект, пришедший в ответ на первый запрос с хостом, на глобальный адрес с доменом 2 уровня, не совпадающим с доменом 2 уровня оригинального запроса.
4. [tpws] закрытие соединения клиентом после отправки первого запроса с хостом, если не было на него ответа со стороны сервера. Это обычно случается по таймауту, когда нет ответа (случай “зависание”).

Чтобы снизить вероятность ложных срабатываний, имеется счетчик ситуаций, похожих на блокировку.
Если за определенное время произойдет более определенного их количества, хост считается заблокированным и заносится в autohostlist. По нему сразу же начинает работать стратегия по обходу блокировки.

На практике работа с данным режимом выглядит так.
Первый раз пользователь заходит на сайт и получает заглушку, сброс соединения или броузер подвисает, вываливаясь по таймауту с сообщением о невозможности загрузить страницу.
Надо долбить F5, принуждая броузер повторять попытки. После некоторой попытки сайт
начинает работать, и дальше он будет работать всегда.

С этим режимом можно использовать техники обхода, ломающие значительное количество сайтов.
Если сайт не ведет себя как заблокированный, значит обход применен не будет.
В противном случае терять все равно нечего.
Однако, могут быть временные сбои сервера, приводящие к ситуации, аналогичной блокировке.
Могут происходит ложные срабатывания. Если такое произошло, стратегия может начать ломать
незаблокированный сайт. Эту ситуацию, увы, придется вам контролировать вручную.
Заносите такие домены в ipset/zapret-hosts-user-exclude.txt, чтобы избежать повторения.

Скрипты zapret ведут autohostlist в ipset/zapret-hosts-auto.txt.
install_easy.sh при апгрейде zapret сохраняет этот файл.
Режим autohostlist включает в себя режим hostlist.
Можно вести ipset/zapret-hosts-user.txt, ipset/zapret-hosts-user-exclude.txt.

Удалось ускорить blockcheck. Для этого требуется sleep с возможностью спать меньше секунды.
В openwrt этого по умолчанию нет. На новых openwrt, где есть ucode, удалось извернуться. Для более старых требуется установка coreutils-sleep. Внесено предолжение по установке coreutils-sleep в install_easy.sh в случае необходимости

Собственно, зачем нужен микро sleep.
Проверка осуществляется так. Сначала устанавливается общее правило перенаправления трафика, которое не меняется на время тестирования всего блока параметров.
При тестировании каждого параметра запускается nfqws/dvtws или tpws, параметр тестируется , затем nfqws/dvtws или tpws прибиваются.
Им требуется какое-то время для инициализации. Если послать запрос раньше, в случае tpws получим полный облом - connection refused, в случае nfqws/dvtws если система достаточно медленная, получим отброс первого пакета и ретрансмиссию. Это все ведет к задержкам при тестировании каждого параметра. На деле ждать 1 секунду избыточно. Вполне достаточно 100 мсек. Но вот беда, в openwrt бизибокс, собранный без поддержки float sleep и без usleep, и нечем вызвать syscall nanosleep().
Благо, ucode все-таки это может. Есть функция запуска процесса с таймаутом. Но ucode появился вместе с fw4 в 22-й версии openwrt. В более старых нет. Потому там надо устанавливать coreutils-sleep, который умеет спать с дробями секунды. Благо, он весит всего 40-50K. Зато блокчек в разы шустрее пробегает.
Используется 4 варианта поспать мало. Если никакой из них не сработал - спим 1 секунду

В tpws и nfqws добавлена возможность логгинга положительных решений по autohostlist.
Можно разобраться когда и по какой причине что-то попало в лист.
Через скрипты проведено как переменная AUTOHOSTLIST_DEBUGLOG.
При значении “1” ведется лог в ipset/zapret-hosts-auto-debug.log

09.11.2023 12:42:39 : dostfilms.site : incoming RST
09.11.2023 12:42:39 : dostfilms.site : fail counter 1/2
09.11.2023 12:42:39 : dostfilms.site : incoming RST
09.11.2023 12:42:39 : dostfilms.site : fail counter 2/2
09.11.2023 12:42:39 : dostfilms.site : adding
09.11.2023 12:43:30 : sun9-33.userapi.com : incoming RST
09.11.2023 12:43:30 : sun9-33.userapi.com : fail counter 1/2
09.11.2023 12:43:31 : sun9-75.userapi.com : incoming RST
09.11.2023 12:43:31 : sun9-75.userapi.com : fail counter 1/2
09.11.2023 12:43:31 : sun9-61.userapi.com : incoming RST
09.11.2023 12:43:31 : sun9-61.userapi.com : fail counter 1/2
09.11.2023 14:20:04 : sun9-46.userapi.com : incoming RST
09.11.2023 14:20:04 : sun9-46.userapi.com : fail counter 1/2
09.11.2023 14:20:04 : sun9-28.userapi.com : incoming RST
09.11.2023 14:20:04 : sun9-28.userapi.com : fail counter 1/2
09.11.2023 14:20:04 : sun9-5.userapi.com : incoming RST
09.11.2023 14:20:04 : sun9-5.userapi.com : fail counter 1/2
09.11.2023 14:21:53 : sun9-33.userapi.com : incoming RST
09.11.2023 14:21:53 : sun9-33.userapi.com : fail counter 1/2
09.11.2023 14:25:08 : hd-rezka.pro : redirect to another domain
09.11.2023 14:25:08 : hd-rezka.pro : fail counter 1/2
09.11.2023 14:25:11 : hd-rezka.pro : redirect to another domain
09.11.2023 14:25:11 : hd-rezka.pro : fail counter 2/2
09.11.2023 14:25:11 : hd-rezka.pro : adding
09.11.2023 14:25:43 : films1080.best : redirect to another domain
09.11.2023 14:25:43 : films1080.best : fail counter 1/2
09.11.2023 14:25:44 : films1080.best : redirect to another domain
09.11.2023 14:25:44 : films1080.best : fail counter 2/2
09.11.2023 14:25:44 : films1080.best : adding
09.11.2023 14:29:48 : tv1.lordfilm.black : redirect to another domain
09.11.2023 14:29:48 : tv1.lordfilm.black : fail counter 1/2
09.11.2023 14:29:49 : tv1.lordfilm.black : redirect to another domain
09.11.2023 14:29:49 : tv1.lordfilm.black : fail counter 2/2
09.11.2023 14:29:49 : tv1.lordfilm.black : adding

Из примера видно, что разные поддомены незаблокированного userapi.com периодически дают RST. Это можно списать на перегруженность серверов. Устойчивой картины нет, поэтому порог срабатывания 2 фейла за 60 секунд не достигается. Домены не заносятся в лист.
Другие домены дают устойчивую картину, потому заносятся в лист
Порогами срабатывания можно играться

09.11.2023 12:41:23 : www.kinozone.online : tcp retrans threshold reached
09.11.2023 12:41:23 : www.kinozone.online : fail counter 1/2
09.11.2023 12:41:26 : www.kinozone.online : tcp retrans threshold reached
09.11.2023 12:41:26 : www.kinozone.online : fail counter 2/2
09.11.2023 12:41:26 : www.kinozone.online : adding
09.11.2023 12:42:03 : hd-rezka.pro : tcp retrans threshold reached
09.11.2023 12:42:03 : hd-rezka.pro : fail counter 1/2
09.11.2023 14:24:05 : hd-rezka.pro : tcp retrans threshold reached
09.11.2023 14:24:05 : hd-rezka.pro : fail counter 1/2
09.11.2023 14:24:06 : hd-rezka.pro : tcp retrans threshold reached
09.11.2023 14:24:06 : hd-rezka.pro : fail counter 2/2
09.11.2023 14:24:06 : hd-rezka.pro : adding
09.11.2023 14:28:59 : kinogo.io : tcp retrans threshold reached
09.11.2023 14:28:59 : kinogo.io : fail counter 1/2
09.11.2023 14:29:00 : kinogo.io : tcp retrans threshold reached
09.11.2023 14:29:00 : kinogo.io : fail counter 2/2
09.11.2023 14:29:00 : kinogo.io : adding

Из этого примера видно, что провайдер не шлет RST, а отмораживается на плохие домены. Сеансы виснут. Клиент пытается слать ретрансмиссии, не получая ACK. Достигнув порога в 3 ретрансмиссии происходит срабатывание события “похоже на блокировку”. 2 раза так подвисли за 60 секунд - занесли в лист
К hd-rezka.pro пробовали обращаться в 12:42. Страница подвисла, но передалбливаться не стали. Долбанулись только 1 раз и расслабились. Порог достигнут не был. Потом в 14:24 начали долбиться более настойчиво, что вызвало срабатывание.

Обратили мое внимание на штуку, о которой знать не знал.
chrome://flags kyber
Это постквантовая штука для TLS , которая раздувает ClientHello до 2 TCP frames.
Следовательно, nfqws ломается. Он в принципе не занимается реассемблингом TCP frames. А DPI занимается и корректно блокирует.
Если вдруг хромисты начнуть дефолтить эту фичу, придется доделывать nfqws

Кстати, это так же пинок в адрес GoodbyeDPI
У него та же проблема. Или нет ? Если вдруг он не парсит целую TLS запись, а ищет паттерн, то ему все равно.
НО. Chrome засовывает SNI в разные места ClientHello. Попадает то в 1-й пакет, то во 2-й. 2-й пакет вообще не содержит сколько нибудь вразумительного начала.

Предполагаемый способ решения проблемы в nfqws.

1. Разрешить partial ClientHello. Это поможет проанализировать 1-й пакет, даже если он порезан на середине. Если SNI находится там, вопрос решен
2. Если все-же SNI находится не в 1-м сегменте, то придется делать реассемблинг до тех пор, пока не обнаружится SNI. И тогда делать desync не на 1-й пакет , а на тот, где находится SNI. Ведь это и есть цель. Делать на все не есть хорошо, потому что есть фильтры hostlist, и вообще неясно есть ли SNI в TLS сообщении. Но что тогда ? Запоминать все пакеты, пока не будет возможность принять решение, и потом их выплевывать ? Можно, хотя и сложновато

в tpws этой проблемы ожидаемо нет

Сделана поддержка работы с TLS ClientHello, размазанными на несколько пакетов

РЕАССЕМБЛИНГ TCP
nfqws поддерживает реассемблинг некоторых видов tcp запросов.
На текущий момент это TLS ClientHello. Он бывает длинным, если в chrome включить пост-квантовую
криптографию tls-kyber, и занимает как правило 2 пакета.
chrome рандомизирует фингерпринт TLS. SNI может оказаться как в начале, так и в конце, то есть
попасть в 1 или 2 пакет. stateful DPI обычно реассемблирует запрос целиком, и только потом
принимает решение о блокировке.
nfqws реагирует десинхронизацией на каждый пакет из TLSClientHello, если задана опция
–dpi-desync-skip-nosni=0. В противном случае десинхронизация идет на сам пакет,
включающий SNI, и все последующие.

РЕАССЕМБЛИНГ QUIC
tls-kyber может так же размазываться по 2 пакетам QUIC Initial.
Пока их реассемблинг не реализован, поскольку русский DPI не реагирует на такие пакеты.
Идет десинхронизация полных hello в одном пакете и частичных hello, где SNI попал в 1-й пакет.
Можно только гадать как будут рубить сеанс, если вдруг блокировщики реализуют поддержку подобных hello.
Если, допустим, они станут буферизировать 2 пакета, и после 2 рубить сеанс, если им не понравился SNI, то можно выплюнуть что-то между 1 и 2. Если они будут сечь долго сеанс QUIC на предмет продолжения initial, то плеваться придется между множеством пакетов. Если же и это не сработает, значит придется дурить сразу на 1 пакете, чтобы они не распознали начало QUIC протокола и не стали ничего высекать из последующих пакетов. Но это потребует буферизации уже на стороне nfqws.
Так что писанина кода ожидается разная

Так же обновлена логика детекта tcp ретрансмиссий.
По мере реконструкции TLS запроса выясняется диапазон tcp sequence numbers, покрывающий запрос.
Ретрансмиссиями запроса считаются только повторные передачи из этого диапазона.
При обнаружении пакета вне диапазона, счетчик ретрансмиссий немедленно завершается.
Обнаружение RST или http редирект теперь жестко завязано на sequence=1 со стороны сервера.
То есть реакция только на RST сразу и молча, либо передачу http redirect сразу.
Все, что потом, не трогается, и реакции по auto hostlist нет

В скриптах ipset/get_reestr* сделана поддержка ipban.
Забаненными IP считаются IP из реестра, которым не назначен hostname.
Источник : https://raw.githubusercontent.com/zapret-info/z-i/master/dump.csv
На деле какие-то IP забанены, какие-то нет. В dump.csv нет информации разбанена ли запись или нет.
Потому лист избыточен

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

#HTTP_PORTS=80-81,85
#HTTPS_PORTS=443,500-501
#QUIC_PORTS=443,444

Может понадобится, если DPI сечет разные порты.
Но вбивать сюда 1-65535 крайне не рекомендовано, поскольку весь трафик может упасть на nfqws или tpws

Переменные конфига

OPENWRT_WAN4
OPENWRT_WAN6

позволяют переопределить в openwrt WAN интерфейсы для ipv4 и ipv6
интерфейсы задаются как имена логических интерфейсов netifd (wan,lan), а не интерфейсов linux (eth0, eth1, br-lan)
множественные интерфейсы пишутся в кавычках через пробел
все по аналогии с OPENWRT_LAN
полезно, когда у вас несколько ipv6 аплинков, и общая стратегия может ломать другой аплинк

проверка : /etc/init.d/zapret list_ifsets

Вынес отдельным скриптом install_prereq.sh установку дополнительных пакетов в ОС.
Это надо для упрощения начальной процедуры развертывания, когда install_easy еще не выполнен и надо запускать blockcheck.sh.
Чтобы не запускать install_easy и не прерывать его после установки пакетов, и чтобы не помнить/читать про необходимые пакеты, не копипастить большие команды по их установке. Вместо этого install_bin + install_prereq сразу готовят систему к blockcheck

Заменил в nfqws дефолтный фейк http/https с w3.org на iana.org.
w3.org переехал на cloudflare.
Особенность cloudflare такова, что он позволяет дергать все свои сайты с любых своих IP.
Теперь представьте, что вы тестите в блокчеке rutracker.org, который тоже на клауде.
Если TTL превысит длину пути до сервера, то сервер получит фейк.
И вместо отлупа мы получаем 200 OK или 307 redirect, как будто все в порядке.
А на самом деле не в порядке, эта стратегия будет ломать сайт.

Хочу обратить внимание на особенности применения zapret в текущих условиях в России.

Сейчас ТСПУ любят ставить у магистралов, потому приходится сдвигать TTL дальше провайдера. Может быть и 8, и даже 11.
Может быть балансировка нагрузки на разные магистралы. И на одном DPI на 5-м , на другом на 11-м.
Значит от раза к разу количество хопов может быть разным до сервера из-за разного маршрута.
Может быть и такое, что на разные направления идет стабильно разный маршрут.
Чтобы обойти какие-то сайты на одном маршруте, вы ставите 11, но на другие маршрут иной, существенно короче, и там идет облом.

Проблема случается, когда фейковые пакеты без фулинга доходят до сервера и воспринимаются им как реальные пакеты от клиента. На http это могут быть ошибки 400. Так реагируют сервера на необслуживаемый домен (iana.org, w3.org)
На https будут ошибки другого вида, связанные с невозможностью выполнить TLS handshake.

Вообщем, здесь необходим дополнительный ограничитель.
Самый универсальный и совместимый - md5sig. Но он работает только с linux серверами.
badsum, кажется, перестал работать на многих провайдерах. Возможно, DPI стали проверять tcp checksum
badseq, как показывает практика, может работать только с https, но не работать с http (особенности DPI от rdp.ru/ТСПУ)

blockcheck.sh был создан не как конечный судья, выносящий вердикт “какие буковки писать сюда”.
Он скорее напоминает томограф, а вы - врач, изучающий томограмму и ставящий диагноз. За вас он это не всегда сможет сделать.
Потому тут надо думать и понимать что происходит, чтобы получить надежный результат, а не когда-то открывается, когда-то нет, а почему я без понятия, все вписал как сказали. Нет, это уже тоже не всегда работает

Самый бронебойный вариант - обход только нужных вам сайтов, которые можно вписать в фильтр по ip или hostlist, или же autohostlist.
autohostlist хорош тем, что при должной настройке и минимальном обслуживании не трогает то, что трогать не нужно, тем самым минимизируя риск поломки всевозможных сбербанков.
Но это не избавляет от необходимости находить надежную стратегию, иначе не будет нормально работать обход того, что вам нужно

1. tpws : поддержка нового метода десинхронизации --oob. Посылка нулевого out of band байта после первой части сплита.
2. Перевод схемы nftables на обслуживание tcp соединений после NAT (POSTNAT). Это позволяет задействовать атаки, ломающие NAT. При использовании MASQUERADE они невозможны на iptables, поскольку iptables не позволяют перехватить трафик после NAT.
   В nftables теперь используется еще 1 бит в mark : DESYNC_MARK_POSTNAT. Так помечаются пакеты, перенаправляемые на nfqws в POSTNAT режиме. Чтобы потом можно было пакеты, генерируемые в nfqws, помечать как notrack, чтобы NAT их не ломал.
   POSTNAT ломает десинхронизацию UDP протоколов с первого пакета, поэтому udp идет по старинке в PRENAT режиме
3. Режим дурения datanoack. Ломающий NAT режим, требует внешнего IP адреса на системе, где производится атака. Отсылка дурящего пакета без флага ACK. Это неправильно, поэтому сервера отбрасывают, а DPI может схавать
4. Режим autottl в nfqws. На каких-то провайдерах может неплохо работать, на каких-то хуже или вообще плохо. Можно пробовать крутить параметры. Какой TTL выбрал автомат видно в nfqws --debug. Там же и видны TTL обрабатываемых пакетов. Для реализации режима требуется перенаправить как минимум первый пакет SYN,ACK

Как работает autottl.
--dpi-desync-autottl=[<delta>[:<min>[-<max>]]]
Берется входящий TTL. Если он ниже не более, чем на 31 хоп от стандартных значений 64,128,255, то соответствующее значение берется за исходный TTL входящего пакета и вычисляется длина пути как разница.
При других TTL алгоритм идет в отказ.
Далее от длины пути отнимается дельта, которую можно указать в параметре --dpi-desync-autottl. По умолчанию она = 1.
Полученное значение берется как TTL фейк пакетов.
Если оно выходит за пределы min-max, то оно нормализуется до min или до max. Если после нормализации превышена длина пути, алгоритм выдает отказ.
При отказе используется фиксированное значение ttl, заданное в параметре --dpi-desync-ttl.
Если у вас нет других ограничителей по fooling, лучше указать --dpi-desync-ttl=1, чтобы в случае отказа фейк пакет не дошел до сервера.
Можно настроить отдельную версию параметров для ipv6.
Смысл значений min-max означает диапазон длин пути, между которыми находится DPI. Нет смысла атаковать сервера слишком близкие, которые еще до DPI. Это обычно ресурсы самого провайдера. Так же нет смысла гнать фейки слишком далеко куда-то в США, потому что там тоже нет блокирующих DPI.
Значение дельты позволяет несколько сгладить небольшую разницу в длине исходящего и входящего пути. Но если сделать слишком большое значение, то можно вылезти в область DPI. Фейки перестанут доходить до DPI, и обход перестанет работать.
Блокчек прогоняет тесты на несколько вариантов delta. Это тот случай, когда тестирование надо выполнять на чем большем количестве заблокированых доменов, тем лучше. На разных доменах могут работать разные дельты. Если на большинстве доменов работает какая-то дельта, то ее и нужно использовать. Если везде все по разному, то от autottl стоит отказаться.

В tpws добавлена возможность указать OOB байт. В виде символа или 0xHEX.
Там же новые параметры --tamper-start и --tamper-cutoff позволяют ограничить байтовые позиции или номер блока исходящего потока, к которым применяется дурение. start<=pos<cutoff
cutoff - это точка отсечения, с которой больше не дурим.
Позиция относится к началу текущего принятого от клиента блока.

Обнаружилось, что некоторые провайдеские NAT datanoack проходит корректно. В этом случае внешний IP адрес может быть не обязателен.
megafon, beeline мобильные работают.
Но linux NAT оно не проходит. За домашним роутером это бесполезно, но можно с него.

autottl на BSD системах можно завести безкровно. В смысле, не надо перенаправлять весь входящий трафик с порта (ибо connbytes отсутствует).
Достаточно перенаправить 1 пакет SYN,ACK, и его легко фильтрануть правилом ipfw или PF.
autohostlist в dvtws по-прежнему не рекомендован на BSD, тк требует перенаправляения более одного входящего пакета на tcp соединение, и ограничить не представляется возможным.
Если ваш провайдер виснет на заблокированных ресурсах, то сработать может и без.
Вариант “зависло” детектится на основе только исходящего трафика. Вариант RST или redirect детектиться не будут
tpws c autohostlist работает без ограничений

Сделана частичная поддержка blockcheck в OpenBSD и MacOS. Частичная в том смысле, что tpws не поддерживается в OpenBSD, а в MacOS не поддерживается dvtws.
Увы, я до сих пор не понимаю как перенаправлять трафик в OpenBSD на tpws с локальной системы (не проходной)
Если брать инструкцию с route-to от TOR, то она работает, но невозможно узнать оригинальный адрес назначения у сокета через DIOCNATLOOK, так что этот варик редиректа бесполезен
В MacOS это работает без проблем.

Перевел тест tpws в blockcheck на использование socks, выкинув всю муть с перенаправлением трафика через фаервол.
Раньше от этого отказывался, потому что невозможно управлять версией ip (ipv4/ipv6), когда CURL работает через прокси.
Пришлось вынести ресолвер отдельно. mdig ресолвит домен, далее курлу подсовывается ключ --connect-to. Он доступен с версии 7.49, следовательно совсем уж древние курлы старее мая 2016 отваливаются , равно как и старые дистрибутивы ОС в варианте “из коробки”. Если у вас такой древнющий курл, можно собрать самому или взять готовый статический бинарик.
В openwrt с LEDE 17 версия curl достаточно новая.
В итоге tpws теперь можно тестировать в openbsd и pfsense, а код скрипта упростился

В blockcheck добавлена проверка на обход QUIC. Для нее требуется curl с поддержкой опции --http3-only.
Сейчас пока это диковинка, родной curl скорее всего не умеет
Тут есть статики для разных платформ : Releases · stunnel/static-curl · GitHub

Десинхронизация udp на nftables тоже переведена на POSTNAT схему вместе с TCP.
Этот вариант позволяет задействовать любые атаки, в том числе ломающие NAT, однако при включенном masquerade для проходного трафика может использоваться только через nftables.
Например, вариант ipfrag2 работает на многих сайтах для обхода блокировки QUIC.
Сеть очень плохо относится к фрагментации tcp на уровне IP. Это ненормальная ситуация, поэтому как правило такое режется.
Но к фрагментации udp сеть относится относительно лояльно. Есть ситуации, когда это вообще нормально.
IP фрагментация используется в IKE. В IKE уже изобрели свой метод фрагментации сообщений на уровне L7, но старые ОС об этом не знают. windows 7 отсылает фрагментированные udp, windows 10 - несколько нефрагментированных udp. Именно поэтому на некоторых VPS вам упорно не удастся подключиться к вашему strongwan с win7, и все лишь потому, что у вас слишком упертый хостер, который решил подрезать фрагментированные пакеты полностью.
Фрагментация QUIC по сути тоже ненормальна, но мало кто будет лезть так глубоко и анализировать udp payload (который еще надо суметь собрать).
cloudflare и bbc.com обходятся через ipfrag2, на facebook режут.

Новый метод десинхронизации нулевой фазы SYNDATA.
Термин нулевой фазы относится к десинхронизации на этапе TCP 3 way handshake.
К ней неприменимы фильтры на основе hostlist.
Этот тот случай, когда в --dpi-desync может быть 3 параметра через запятую.
Можно так : --dpi-desync=syndata,fake,split2

Суть в добавлении данных в пакет SYN. ОС принимают такие SYN пакеты, но данные игнорируют, а некоторые DPI их принимают. Кое-где работает на наших ТСПУ, но только для http.
На https может работать, если в параметре --dpi-desync-fake-syndata передать файл, содержащий TLS client hello с незаблокированным доменом. Фактически это аналог fake, поскольку расчет на то, что DPI принимает этот пейлоад как часть tcp stream, а сервер - нет.
Некоторые российские ТСПУ/DPI на http впадают в проблемы с синхронизацией sequence numbers, что приводит только к зависанию соединения.
Ломает некоторые сайты, видимо из-за собственных систем antiddos, которые плохо реагируют на аномалии

Поскольку ограничить хостлистом или аутохостлистом невозможно, применять с осторожностью

Главная цель этого режима десинхронизации - не атака на веб сайты, а атака на произвольные протоколы на конкретном сервере без применения техники split.
Сейчас наблюдается такая тема на ТСПУ. Если какой-то VPN сервис или другой сервис начинает применять техники обхода блокировок, связанные с сегментацией, то ТСПУ их обнаруживает и сразу блокирует соединение. Делается это обычно на ограниченных диапазонах IP.
В условиях жестких блокировок и противодействия техникам их обхода, ценна может быть каждая дырочка на свой сервер.
На udp это может быть ipfrag2, а на tcp - syndata.

Оказывается, старый добрый фейк на http и https может не работать в оригинальном виде.
Когда ты лезешь на http и шлешь фейк http iana.org, это может не сработать. Но если послать ерунду типа нулей, то может сработать. На syndata может быть наоборот. Ерунда не работает на https, а tls fake от iana.org - работает.

В связи с этим обновлен blockcheck на предмет поиска новых заковыристых стратегий

Еще немного по поводу SYNDATA.
На самом деле не запрещено по стандарту слать данные прямо в SYN. Поэтому такие пакеты без проблем проходят NAT и могут учитываться DPI.
Оригинальный стандарт запрещает передавать данные из SYN в сокет до полного прохождения tcp handshake. Но фактически по крайней мере linux, freebsd и windows данные в SYN игнорируют. При этом все последующие пакеты идут с сиквенсами, как будто бы SYN был пустой. То есть данные в SYN просто отбрасываются на стандартных сокетах.

Но есть еще более новый стандарт TCP fast open. В нем как раз отсылка данных в процессе хэндшейка - это нормально. Однако, для задействования функционала требуется особое программирование специально для поддержки fast open. Это должен уметь и серверный процесс, и клиентский.

Хотя некоторые веб сервера и умеют, и даже некоторые броузеры на некоторых платформах умеют, мало кто сейчас озабочен этим fast open. У меня нет статистики где и на каких ОС и на скольких сайтах он включен по умолчанию. Но как я понимаю немного где. Это уже устаревшая технология. Сейчас актуален QUIC. Он решает в том числе и проблему RTT.

Но если вдруг SYNDATA будет использован именно на fast open соединении, несомненно оно сломается. Поэтому соединения с признаками fast open не трогаются.

Сделал автоматическое перечитывание autohostlist другими процессами nfqws/tpws при модификации файла.
Выдал, допустим, блокчек 4 разных стратегии для http/https/ipv4/ipv6.
Юзер тупо вписал это в конфиг. Запущено 4 процесса.
Дернул https ipv4. Отлично, занеслось в аутолист.
Потом не работает. Почему ? Да потому что полезло по ipv6, а там не обновилось.

Реализован режим quick в blockcheck.
Его цель - найти хоть что-то работающее максимально быстро.
Изначально blockcheck создавался не как делатель волшебных пиллюль для копипасты в определенное место как на картинке. Это инструмент исследования DPI на предмет техник обхода блокировок.
Но юзера некоторые ниче не понимают, они все равно копипастят, и это их единственный шанс, чтобы оно заработало. Иначе им только отказываться от продукта, потому что не могут понять что там за буковки и что с ними делать.
В том числе для них может пригодиться этот режим, потому что все равно лишние буковки для них бесполезны.

Суть его в чем

1. Отказ от тестов tpws. Все равно он как правило не обеспечивает должный уровень обхода. Чтобы вернуть используйте переменную SKIP_TPWS=0
2. Поиск идет до первой рабочей стратегии
3. При нескольких попытках любой фейл приводит к концу серии попыток. Ведь все равно будет итоговый фейл

По умолчанию все равно оставляю standard, чтобы основная цель скрипта оставалась неизменной

Из blockcheck убраны тесты ipfrag tcp, поскольку современная сеть практически не оставляет никаких шансов этому варианту.

Немного наблюдений по поводу протокола QUIC.
Если кратко, то на DPI он обрабатывается криво. Алгоритмы несовершенны.
Поведение DPI может зависеть от типа клиентской библиотеки.
quiche может пробивать блокировку и без средств обхода.
Пакеты initial от разных библиотек могут не собираться DPI, и он может не извлекать host.
curl с nghttp3 может долго (1-3 сек) выполнять запрос с пробивкой по fake. Там то ли теряются, то ли искажаются пакеты от сервера, вынуждая клиент еще раз слать initial.
При этом firefox может сразу и быстро открывать этот же сайт по quic, если количество пробивочных пакетов 5 и выше, и подвисать на QUIC, если меньше.
Аналогично у них реализуется и блокировка wireguard udp и openvpn udp. Для пробивки нужно слать 5 фейков.
DPI по-прежнему не может корректно сечь разбросанный на несколько пакетов initial. В хромах уже начали включать кибер по умолчанию, так что 50/50. Рандомизирует сигнатуру. То в первый пакет SNI попадет, то во 2-й
Вообщем, сложная эта штука QUIC, и curl test может не отражать реальной специфики как поведет себя броузер

В tpws реализованы фильтры протоколов для disorder и oob.
Параметр oob претерпел несовместимое изменение. Теперь наравне с disorder он берет название протокола http или tls. Если без параметра - применяется дурение ко всем протоколам. Если с параметром - только к этому протоколу.
Может быть несколько --disorder или --oob. Например, можно сказать ему сделать oob для tls и http, но не делать для остальных, при условии что задано --split-any-protocol.
Байт OOB перенесен в параметр --oob-data. Это нужно, потому что в tpws стали появляться стратегии, которые нужны для одних протоколов, но могут ломать другие.
Для http есть отдельный split --split-http-req. Он имеет приоритет над --split-pos.
Если это не http, то применяется --split-pos. Получается, можно двумя этими параметрами задать разный сплит для http и tls.
Но вот disorder может сломать http на ТСПУ. В скриптах запуска можно было этот вопрос решить как с nfqws - сделать несколько параметров для http,https,http6,https6.
Но tpws еще ценен наличием режима socks, а там такое сделать не выйдет, потому что в прогах нет 4 поля socks для разных вариантов. Потому принято решение идти по пути обьединения стратегий в 1 процесс.
Кстати, это еще один пример, что вот так просто взять копипастнуть как на картинке может не получиться. Если вы захотите пойти путем tpws, то там только 1 поле, а стратегии выдал blockcheck две разные. И все, вы тут встряли, если вы - копипастер. А на самом деле это сделано потому, что все можно запихать в 1 стратегию, если их обьеденить, но это не для копипастеров. И, конечно, чтобы не ломать достоинство socks.
tpws в текущих реалиях в России работает, но ограниченно.
Как правило он может пробить http, а https только на tls 1.3.
Не поддерживающие tls 1.3 заблокированные сайты пробить не получится.

Худой, но как-то работающий способ пробить TLS1.2 на tpws. Не везде, но много где. Не особо качественно. Но лучше, чем ничего.

–mss устанавливает опцию сокета TCP_MAXSEG. Клиент выдает это значение в tcp опциях SYN пакета.
Сервер в ответ в SYN,ACK выдает свой MSS. На практике сервера обычно снижают размеры отсылаемых ими пакетов, но они все равно не вписываются в низкий MSS, указанный клиентом. Обычно чем больше указал клиент, тем больше шлет сервер. На TLS 1.2 если сервер разбил заброс так, чтобы домен из сертификата не попал в первый пакет, это может обмануть DPI, секущий ответ сервера.
Схема может значительно снизить скорость и сработать не на всех сайтах.
Несовместимо с фильтром по hostlist. Невозможен фильтр по версии TLS.
Взамен имеется фильтр по портам --mss-pf. --mss-pf=443 применяет дурение только к https.
Применяя данную опцию к сайтам TLS1.3, если броузер тоже поддерживает TLS1.3, то вы делаете только хуже.
Но нет способа автоматически узнать когда надо применять, когда нет, поскольку MSS идет только в
3-way handshake еще до обмена данными, а версию TLS можно узнать только по ответу сервера, который может привести к реакции DPI.
Использовать только когда нет ничего лучше или для отдельных ресурсов.
Работает только на linux, не работает на BSD и MacOS.

В tpws ликвидировано узкое место, связанное с ресолвером хостов.
У socks proxy есть режим переадресации по IP адресу и по хосту.
В curl за выбор режима отвечают параметр --socks5 или --socks5-hostname. Можно использовать параметр --proxy socks5://… и --proxy socks5h://… . socks5h - это как раз ресолвинг через прокси.

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

Сейчас это больше не так. Задача по ресолвингу решается в отдельных потоках, организованных в виде thread pool. Есть очередь запросов, а потоки их по мере возможности разгребают. На время ресолвинга соединение ставится на паузу, не прерывая процессинг всего остального.

Количество потоков ресолвера выбирается по умолчанию как 5+max_conn/50. По умолчанию max_conn=512, следовательно потоков 15. Можно переопределить в параметре --resolver-threads.

Да, можно было использовать какую-то отдельную библиотеку для асинхронных ресолвингов, ведь libc в общем случае такой возможности не имеет. Имеет только glibc, а musl и другие - нет. Но это зависимости, это тяжесть процесса, которую хочется избежать.

Помимо прямого назначения, это нововведение несет в себе и другую цель. Использование tpws в socks режиме с удаленным ресолвингом хостов дает tpws возможность узнать hostname еще до подключения к серверу. Следовательно, задействуется механизм, ограничивающий дурение по MSS через hostlist. В любом другом режиме MSS будет применяться неограниченно ко всем соединениям.

Как задействовать socks в броузерах.
В хромиум подобных вызвать chrome так : chrome.exe --proxy-server=“socks5://localhost:1111” . Они сразу начинают задействовать режим remote_dns.
В firefox можно глобально задать в about:flags параметр network.proxy.socks_remote_dns=true. А можно использовать расширение foxyproxy. Оно позволяет оперативно переключать прокси, и можно задать remote_dns для каждого прокси отдельно.

WSL 1. Подсистема linux на win10/11 и windows server.
Эмуляция вызовов ядра linux, позволяющая запускать бинарики linux.
Но, естественно, в реализации есть кривизна.

Проверял на windows server 2022. Оказалось глючат linux pipes.
Делаешь splice в pipe. Возвращает, что записал 8192 байт.
Делаешь splice из pipe в сокет. B хрен вам. EAGAIN. Как будто ничего нет в этом пайпе.
Делаешь read из пайпа - тоже самое. То есть там действительно пусто.
Проблема не в сокете. Если в него слать send-ом, то ошибки нет, уходит.
Получается суешь в пайп, и это куда-то пропадает неизвестно куда.
Логика неблокирующих сокетов приводит к зацикливанию процесса, сьедая целое ядро.

Сколько ни тестировал на linux, такого нет, а в винде воспроизводится на раз два.

Лечение - параметр --nosplice. Обход глюка винды

Исправлен целый ряд проблем, все же имевшихся в схеме postnat.
Десинхронизация на первый пакет (syndata на tcp или первый пакет udp, quic, например) несет в себе проблему. Если дропать в очереди первый пакет, то ломается запись в conntrack. Его нельзя дропать.
Потому было сделано особое уродование первого оригинального пакета, чтобы его пропускать в очереди.
TTL использовать нельзя, поскольку linux сечет expired icmp и ресетает сокет.
Использованы следующие схемы :

ipv4 - портим L3 чексумму ipv4 хедера. с порченой чексуммой пакет будет отброшен первым же роутером
tcp - в SYN пакете сбрасываем все флаги и этим самым так же портим чексумму L4
udp - в первом пакете обрезаем все данные после udp хедера, делаем длину в udp хедере нулевой (минимум 8 требуется - длина самого хедера), портим чексумму L4

эти меры призваны достичь результата, даже если вдруг сетевой адаптер на все делает чексум оффлоад
главная цель - чтобы этот пакет никем по возможности не был воспринят как что-то значимое. ни DPI, ни сервером. но в то же время не испортилась бы запись в коннтрак

Для дурения произвольных протоколов в nfqws добавлен параметр --dpi-desync-start.

Он полностью аналогичен --dpi-desync-cutoff, но работает как начальный ограничитель. cutoff - конечный ограничитель.
Таким образом дублируется функционал connbytes FROM:TO на уровне nfqws. Можно вырезать по номеру пакета (n), смещению позиции данных (s), а так же отсутствующий в connbytes режим - по номеру пакета данных (d). d от n отличается только тем, что считаются пакеты с непустым data payload.
Этот фильтр помогает решить вопрос с отсутствующим connbytes на BSD системах или на прошивочках linux с покоцаным ядром, где нет матча connbytes.
При наличии connbytes лучше это делать средствами iptables/nftables. Тогда не будет лишних редиректов user mode, скорость будет выше в разы.
Если надо ограничить дурение в d режиме, игнорируя непонятное количество пустых ACK, то делаем ограничитель connbytes на максимум возможных пакетов, где нам надо что-то поймать, дальше уточняющий ограничитель в d режиме на nfqws.

В tpws уже реализована пара похожих параметров --tamper-start, --tamper-cutoff

В nfqws теперь обязателен параметр --qnum. Раньше был номер очереди по умолчанию 0.
Сделано во избежание неверного использования, вызванного непониманием как оно работает.
В iptables, кстати, NFQUEUE тоже имеет по умолчанию номер очереди 0. То есть если раньше кто-то писал iptables без queue-num, а nfqws запускал без qnum, то это работало, а теперь перестанет. Вернуть этот вариант можно через nfqws --qnum 0

В nfqws сделана система задержки пакетов.
Начиная с chrome 124 по умолчанию включена пост-квантовая криптография kyber. Это раздувает TLS ClientHello до 2 пакетов, QUIC initial до 2 или 3 пакетов. Может быть и больше при низком MTU.
Ранее nfqws умел реассемблировать TLS ClientHello, но проводил десинхронизацию на тот сегмент TCP, где появилось SNI и все последующие. Допустим, имеется 5 пакетов, в 3-м из которых SNI. Получается, мы имеем : tls1,tls2,fake,tls3,fake,tls4,fake,tls5. Не слишком корректное поведение. QUIC же вообще никак не реассемблировался.
Теперь введена система задержки пакетов. Мы получаем tls1…tls5, но в сеть не шлем, а только запоминаем. По приходу последнего tls5 выполняется десинхронизация tls1 на основании полностью собранного запроса. Выходит так : fake,tls1,tls2,tls3,tls4,tls5. Что куда более корректно, ведь суть фейка - вынудить DPI отстать от запроса. Но как он от него отстанет в предыдущем варианте, если он сначала видит tls1. Он начинает реассемблировать вплоть до tls5. И получает испорченный блок данных где-то посередине. Такое тоже обычно срабатывает для обхода, но все же это не достигает изначальной цели fake.
Для QUIC производится аналогичная процедура, только с дешифровкой каждого куска, конкатенацией расшифрованных данных до тех пор, пока из них не соберется полный ClientHello.
Любая ошибка при сборке вызывает немедленную отмену реассемблирования, отсылку задержанных пакетов и отмену десинхронизации.

Реализован nfqws для windows - winws.
Это фактически замена GoodbyeDPI с up-to-date функциями из nfqws.
Работает практически все.
Из ограничений : нет ipset, не поддерживается проходящий трафик (расшаривание соединения)
Поддерживается blockcheck, но он требует установки cygwin.
Сам winws установки cygwin не требует.

Читайте docs/windows.txt, docs/quick_start_windows.txt

Это дебют, так что welcome тестировать.

Создан bundle для ускоренного и упрощенного запуска blockcheck под windows. Его достаточно для полноценного развертывания winws.

Адаптирована инструкция из основного репозитория docs/quick_start_windows.txt

Сделан запуск в виде windows служб.
См service_*.cmd
Можно запускать и через планировщик, и как службы. Как вам больше нравится.

Устранена гонка при одновременном запуске нескольких инстансов winws.
Она связана с CreateService/StartService драйвера windivert.sys
Это проблема не связана напрямую с winws, а с windivert.dll

Устранено возможное падение при остановке сервиса

Поделюсь своим опытом изучения windows 10 arm64 под qemu-aarch64 на платформе x86.

Известно, что эта платформа имеет встроенный эмулятор кода x86. Бинарная трансляция. Примерно так, как это сделано в android x86 для arm - там используются libhoodini.
Целью было выяснить возможно ли вообще использовать winws на базе x86_64 cygwin с неподписанным драйвером windivert для arm в режиме ядра testsigning.

Попытка установить win11 закончилась провалом. Все мои попытки заканчивались ошибкой установщика уже на этапе после наката install.wim на HDD. Тоже самое получалось и если install.wim накатить вручную через dism, а bcd создать вручную

win10 встала. Но первое, что я заметил, были совершенно невообразимые тупняки.
Конечно, тормоза ожидались, но там все просто ложилось почти намертво.
Как выяснилось, бинарный транслятор кода x86 под qemu-aarch64 при попытке выполнить любой бинарик x86 зацикливается с отьеданием 100% одного ядра.
Неважно что это - хоть простейший cmd. Можно ждать хоть часами - ничего не меняется.
Так что миссия на этом этапе провалилась. Не работает x86 код вообще.

А встроенного кода x86 там хватает. На удивление microsoft сильно схалявил. Целый ряд компонент windows не был перенесен на arm, а выполняется как x86 !!
Начиная с onedrive, который автоматически запускается и добавляет тупняка, и заканчивая powershell, без которого , например, даже нельзя снести все эти ненужные магазинные приложения.

По мере чистки от левака с убиранием из автозапуска всего x86 система стала гораздо более отзывчива и даже почти юзабельна.

Так что пока тестировать не на чем. Требуется реальная подходящая arm железяка

Проверена работа winws на windows 11 arm64 с неподписанным драйвером windivert в режиме testsigning.
Оно работает. Для быстрого наката arm64 версии сделан батник в bundle : arm64/install_arm64.cmd
Все, кроме драйвера, работает в x64 эмуляции.
Windows 10 arm64 не поддерживается по причине отсутствия x64 эмуляции. Поддерживается только x86.

Пару недель назад прошла такая тема, что в ОАЭ и СаудиАрабиа перестал работать GoodByeDPI.
Просто начисто. Блокчек от winws так же показал безуспешность всех вариантов.
Думали все очень сложно. Но оказалась банальщина. Они ищут в отдельных пакетах stateless сигнатуру SNI и смотрят там хост.
Помогает сплит на SNI. Но , увы, такой функции нет в zapret. Недавно Валдик дописал это для GDPI.

Сейчас догоняет и zapret. Но там все несколько сложнее. Потому что поддерживаются многосегментные запросы.
В tpws добавлен параметр --split-tls. Там все довольно просто, поскольку мы не имеем дело с отдельными пакетами. Все равно сколько пакетов в итоге будет.
В nfqws добавлены параметры --dpi-desync-split-http-req и --dpi-desync-split-tls.
И в nfqws, и в tpws для tls допустимы значения sni и sniext. sni - значит резать после 1 символа хоста. sniext - резать между байтами 2-байтной длины SNI extension.
В nfqws реализация оказалась сложнее. SNI может попасть на любой пакет в серии. Поэтому сплит-десинхронизация применяется только к тому пакету, в котором оказалась искомая позиция относительно начала всего многопакетного сообщения. Это касается как явно заданной позиции в байтах, так и автоопределения через split-tls. fake и многие другие опции идут при этом только на первый пакет серии.
Это все надо, чтобы в ОАЭ без отключения кибера сразу же заработала обманка на chrome.
GDPI пока что требует отключения кибер.

В tpws добавлена поддержка --tlsrec=sniext.
tlsrec может сочетаться со split-tls. В этом случае они адаптируются , и вычисляется корректная позиция, чтобы сплит попал куда надо, учитывая дописывание дополнительного заголовка TLS record.

В блокчек добавлены новые тесты для описанного функционала.
Сделан кэш mdig.
Изначально curl запускался с именем домена. Он сам его и ресолвил. Но оказывается, что при использования прокси опции -4 и -6 не могут корректно рулить через какую версию ip пойдет запрос. А прокси нужен для tpws. На некоторых платформах прозрачный режим не работает для локального хоста, либо его сложно автоматически задействовать.
Потому curl теперь гоняется с --connect-to , а хост ресолвит mdig. Ранее при каждом запросе запускался mdig. Теперь он запускается 1 раз на хост и ip версию, а результат запоминается в переменных shell. Запоминаются все ответы, и каждый раз выбирается случайный. Точно так же, как это делает стандартная система DNS

github внезапно отключил gzip compression. сломались скрипты ipset/get_reestr*.sh
исправлено
использовать curl --compressed нельзя, потому что на кастрированных системах curl без zlib. потому приходится эту логику реализовывать самому через шелл

Добавлена важная функция в winws.
В --ssid-filter можно через запятую задать неограниченное количество имен wifi сетей (SSID). Если задана хотя бы одна сеть, то winws включается только, если подключен указанный SSID. Если SSID исчезает, winws отключается. Если SSID появляется снова, winws включается. Это нужно, чтобы можно было применять раздельное дурение к каждой отдельной wifi сети.
Названия сетей должны быть написаны в том регистре, в котором их видит система. Сравнение идет с учетом регистра !
При этом нет никаких проверок куда реально идет трафик. Если одновременно подключен, допустим, ethernet, и трафик идет туда, то дурение включается и выключается просто по факту наличия wifi сети, на которую трафик может и не идти. И это может сломать дурение на ethernet. Поэтому полезно так же будет добавить фильтр --wf-iface на индекс интерфейса wifi адаптера, чтобы не трогать другой трафик.

Зачем это надо. Представьте себе, что вы настроили winws на ноуте чайника, который ничего не понимает, никуда не полезет и ничего не будет ни запускать, ни менять. Можно настроить и сделать сервис. Окей, чайник переехал и подключился к другому wifi. Стратегия не работает и ломает сайты. Что делать ? Ограничить дурение только на те сети, в которых вы знаете какая стратегия работает. Если таких несколько, то можно создать несколько инстансов winws с разными стратегиями и разными --ssid-fllter.
Таким образом чайник ничего не делает, и у него либо обходится блокировка, либо хотя бы ничего не ломается.

В blockcheck добавлены тесты открытости порта 80,443 (требуется ncat или netcat openbsd, бизибокс netcat не поддерживается !) и тесты блокировки по IP на DPI.

С портами все понятно. Если нет коннекта, то это сразу ВСЕ.
Домен может ресолвиться в несколько IP. Может не быть конекта на отдельных IP, если какие-то IP зарублены полностью.

Бывает так же и частичный IP блок. Конект идет, но на любые запросы возвращается reset или только на определенные протоколы типа http, tls, вне зависимости от домена.
Суть тестов блокировки по IP - дернуть заблокированный домен на предположительно незаблокированном ip (ip iana.org по умолчанию) и незаблокированный домен (iana.org) на заблокированном IP.
Дополнительно тестируется сам неблокированный домен (iana.org), чтобы быть точно уверенным, что в вашей экзотической стране не зарубили даже его.
Интерпретация результата целиком на пользователе и требует понимания.
Логика примерно такая. Если блок идет только на DPI по домену, то блокированный домен будет давать reset, timeout или redirect на любом IP.
Неблокированный домен на блокированном IP будет давать или available для http (на самом деле http code 409 или что-то такое реально вернет сервер), или ошибка при подключения по TLS сразу без задержек (что-то вроде handshake error).
Эта ситуация говорит об отсутствии блока по IP.
Если reset, timeout, redirect идут на неблокированном домене на блокированном IP, а блокированный домен на неблокированном IP выдает available или TLS error сразу без задержек, значит вероятно имеет место блок только по IP.
Если reset, timeout, redirect идут в обоих тестах, то может иметься блок как по IP, так и по домену.
Тест на блокированные IP проводится на каждый IP блокированного домена, если их несколько, а на неблокированный IP - только 1 раз на любой из IP неблокированного домена.
Собственно, это то, что я часто прошу сделать руками в случае непоняток. Сейчас это автоматизировано, и по логу блокчека можно понять больше.
Если действительно есть блок по IP, значит вероятно все последующие тесты будут безуспешны.
Однако, бывают ситуации, когда и частичный IP блок пробивается.
Например, в СаудиАрабиа оказалось, что добавление destopt хедера в ipv6 запросе пробивает блокировку. DPI не может следовать дополнительным ipv6 хедерам, не воспринимает пакет как tcp и пропускает его.
В этом и суть частичного блока. Блок на IP только определенных протоколов транспортного и прикладного уровня. Если DPI не может опознать протокол, то блокировки нет.

Полезные переменные для blockcheck
CURL_MAX_TIME=sec - сколько секунд до таймаута curl запроса. по умолчанию 2
CURL_MAX_TIME_QUIC=sec - отдельно для quic. по умолчанию совпадает с предыдущим
CURL_CMD=1 - показывать строку запуска curl каждый раз
CURL_VERBOSE=1 - опция -v для curl. в добавок автоматически CURL_CMD=1
SKIP_TPWS=1 - отказаться от TPWS тестов
SKIP_TPWS=0 - не отказываться от TPWS тестов, когда по умолчанию предусмотрен отказ
SKIP_PKTWS=1 - отказаться от nfqws/dvtws/winws тестов
UNBLOCKED_DOM - домен, используемый для ip block тестов. по умолчанию iana.org
DOMAINS=“dom1 dom2 … domN” - какие домены тестировать. по умолчанию rutracker.org

Переменные используются так :
CURL_MAX_TIME=1 SKIP_TPWS=1 CURL_CMD=1 /opt/zapret/blockcheck.sh

ПРИМЕРЫ БЛОКИРОВКИ ТОЛЬКО ПО ДОМЕНУ БЕЗ БЛОКА ПО IP

> testing iana.org on it's original ip
!!!!! AVAILABLE !!!!!
> testing rutracker.org on 192.0.43.8 (iana.org)
curl: (28) Operation timed out after 1002 milliseconds with 0 bytes received
> testing iana.org on 172.67.182.196 (rutracker.org)
HTTP/1.1 409 Conflict
> testing iana.org on 104.21.32.39 (rutracker.org)
HTTP/1.1 409 Conflict

> testing iana.org on it's original ip
!!!!! AVAILABLE !!!!!
> testing rutracker.org on 192.0.43.8 (iana.org)
curl: (28) Connection timed out after 1001 milliseconds
> testing iana.org on 172.67.182.196 (rutracker.org)
curl: (35) OpenSSL/3.2.1: error:0A000410:SSL routines::ssl/tls alert handshake failure
> testing iana.org on 104.21.32.39 (rutracker.org)
curl: (35) OpenSSL/3.2.1: error:0A000410:SSL routines::ssl/tls alert handshake failure

> testing iana.org on it's original ip
!!!!! AVAILABLE !!!!!
> testing rutracker.org on 192.0.43.8 (iana.org)
HTTP/1.1 307 Temporary Redirect
Location: https://www.gblnet.net/blocked.php
> testing iana.org on 172.67.182.196 (rutracker.org)
HTTP/1.1 409 Conflict
> testing iana.org on 104.21.32.39 (rutracker.org)
HTTP/1.1 409 Conflict

> testing iana.org on it's original ip
!!!!! AVAILABLE !!!!!
> testing rutracker.org on 192.0.43.8 (iana.org)
curl: (35) Recv failure: Connection reset by peer
> testing iana.org on 172.67.182.196 (rutracker.org)
curl: (35) OpenSSL/3.2.1: error:0A000410:SSL routines::ssl/tls alert handshake failure
> testing iana.org on 104.21.32.39 (rutracker.org)
curl: (35) OpenSSL/3.2.1: error:0A000410:SSL routines::ssl/tls alert handshake failure

ПРИМЕР ПОЛНОГО IP БЛОКА ИЛИ БЛОКА TCP ПОРТА ПРИ ОТСУТСТВИИ БЛОКА ПО ДОМЕНУ

* port block tests ipv4 startmail.com:80
ncat -z -w 1 145.131.90.136 80
145.131.90.136 does not connect. netcat code 1
ncat -z -w 1 145.131.90.152 80
145.131.90.152 does not connect. netcat code 1

* curl_test_http ipv4 startmail.com
- checking without DPI bypass
curl: (28) Connection timed out after 2002 milliseconds
UNAVAILABLE code=28

- IP block tests (requires manual interpretation)
> testing iana.org on it's original ip
!!!!! AVAILABLE !!!!!
> testing startmail.com on 192.0.43.8 (iana.org)
HTTP/1.1 302 Found
Location: https://www.iana.org/
> testing iana.org on 145.131.90.136 (startmail.com)
curl: (28) Connection timed out after 2002 milliseconds
> testing iana.org on 145.131.90.152 (startmail.com)
curl: (28) Connection timed out after 2002 milliseconds

Новое дополнение к split и disorder. Опция --dpi-desync-split-seqovl.
Это достаточно сложная для понимания концепция, если не представляешь себе хорошо как работает tcp протокол.
Если сказать по-простому, то это замешивание фейковых данных и реальных в разделяемые сегменты tcp. Замешивание идет через игру с sequence numbers таким образом, чтобы сервер воспринял лишь оригинал, а DPI было очень сложно разобраться где оригинал, а где мусор.
Этот вариант может не требовать отдельных фейк пакетов, а следовательно TTL и fooling.

На ТСПУ игра с sequence обычно вызывает зависание http, но работает на https.

Полное описание из readme.

seqovl добавляет в начало первой отсылаемой части оригинального пакета (1 часть для split и 2 часть для disorder) seqovl байт со смещенным в минус sequence number на величину seqovl.
В случае split2 расчет идет на то, что предыдущий отсыл, если он был, уже попал в сокет серверного приложения, поэтому новая пришедшая часть лишь частично находится в пределах текущего окна (in-window). Спереди фейковая часть отбрасывается, а оставшаяся часть содержит оригинал и начинается с начала window, поэтому попадает в сокет. Серверное приложение получает все, что реально отсылает клиент, отбрасывая фейковую out-of-window часть. Но DPI не может этого понять, поэтому у него происходит sequence десинхронизация.

Для disorder2 overlap идет на 2-ю часть пакета. Обязательно, чтобы seqovl был меньше split_pos, иначе все отосланное будет передано в сокет сразу же, включая фейк, ломая протокол прикладного уровня. При соблюдении этого условия 2-я часть пакета является полностью in-window, поэтому серверная ОС принимает ее целиком, включая фейк. Но поскольку начальная часть данных из 1 пакета еще не принята, то фейк и реальные данные остаются в памяти ядра, не отправляясь в серверное приложение. Как только приходит 1-я часть пакета, она переписывает фейковую часть в памяти ядра. Ядро получает данные из 1 и 2 части, поэтому далее идет отправка в сокет приложения. Таково поведение всех unix ОС - оставлять последние принятые данные.
Для windows серверов может быть наоборот, поэтому не факт, что такой вариант будет на них работать. Метод позволяет обойтись без fooling и TTL. Фейки перемешаны с реальным данными.
split/disorder вместо split2/disorder2 по-прежнему добавляют дополнительные отдельные фейки.

Как показывает практика, на https оно может не работать на TLS1.2, поскольку сечется ответ сервера с сертификатом. Только --wssize 1:6 позволяет это обойти.

Исправлен существенный косяк blockcheck.
На curl, собранном с использованием версии openssl с quic (quictls), библиотека не определялась как openssl и не включался параметр tls-max.
Поэтому все запросы шли реально на tls1.3, что давало искаженную картину.

Добавлен специфический seqovl тест на подсовывание полного ClientHello от iana.org. Аналог fake,split2 , только в одном флаконе.
ТСПУ отстает от такого TLS 1.2 запроса, не проверяя ответ сервера, и поэтому не нужен --wssize , снижающий скорость

- checking nfqws --dpi-desync=split2 --dpi-desync-split-seqovl=1 --dpi-desync-split-pos=2
curl: (35) Recv failure: Connection reset by peer
UNAVAILABLE code=35
- checking nfqws --dpi-desync=split2 --dpi-desync-split-seqovl=336 --dpi-desync-split-seqovl-pattern=/opt/zapret/files/fake/tls_clienthello_iana_org.bin
!!!!! AVAILABLE !!!!!

336 потому, что остаток до 517 байт заполнен нулями. ТСПУ их игнорирует. У нас же пойдет начало реального запроса вместо нулей. По умолчанию 2 байта.

В zapret-win-bundle еще косяк. Не положил files/fake. Из-за этого все тесты, их использующие, не работали.
/bin/sh был копией /bin/bash. Заменено на dash. dash в несколько раз быстрее bash. blockcheck стал бегать повеселее

В winws в добавок к ssid-filter сделан NLM filter.

--nlm-filter=net1[,net2,net3,...] ; включать winws только когда подключена любая из указанных сетей NLM
--nlm-list[=all] ; вывести список сетей NLM. по умолчанию только подключенных, all - всех.

–nlm-filter аналогичен --ssid-filter, но работает с именами или GUIDами сетей Network List Manager (NLM). Это те сети, которые вы видите в панели управления в разделе “Центр управления сетями и общим доступом”. Под сетью подразумевается не конкретный адаптер, а именно сетевое окружение конкретного подключения. Обычно проверяется mac адрес шлюза. К сети можно подключиться через любой адаптер, и она останется той же самой. Если подключиться, допустим, к разными роутерам по кабелю, то будут разные сети. А если к одному роутеру через 2 разных сетевых карточки на том же компе - будет одна сеть. NLM абстрагирует типы сетевых адаптеров. Он работает как с wifi, так и с ethernet и любыми другими. Поэтому это более универсальный метод, чем ssid фильтр.

В режим autohostlist внесен дополнительный механизм избегания ложных срабатываний.
Раньше чтобы добавить в лист домен нужно было, чтобы он фейлился столько-то раз на протяжении такого-то времени. При этом могло быть так. Плохо, хорошо, плохо, хорошо, хорошо, плохо. Это вызывало попадание в лист. Сейчас “хорошо” сразу же сбрасывает счетчик “плохо”. Цель - обнаружить постоянное “плохо”. Если оно через раз, значит либо это проблемы самого сайта (перегруз, например), либо ваша стратегия обхода неустойчива.
Работает и в nfqws, и в tpws.
Под “хорошо” понимается прием любых данных от сервера, не содержащих http redirect на другой домен (заглушку), либо отсыл любого пакета с sequence number, выходящим за пределы TLS ClientHello (то есть процесс пошел дальше, значит клиент принял что-то от сервера, и это уже не затык на DPI)

В blockcheck сделана корректная зачистка при обрыве терминала. Например, отвалился ssh.

Из git удалены все изменяемые файлы. Это config, init.d/{macos,sysv,openwrt}/custom, ipset/zapret-hosts-user*.txt
Они переименованы с расширением .default.
Инсталятор если увидит отсутствие этих файлов скопирует их с .default
blockcheck скопирует только config
zapret-hosts-user-ipban.txt и zapret-hosts-user.txt удалены. они заполняются кодом в инсталяторе.

Это сделано чтобы можно было не парясь накатывать файлы поверх имеющейся инсталяхи или делать git pull не парясь о нестыковках.

Распространенная проблема, связанная с ютубе,

Чел сканирует блокчеком, находит стратегию с TTL. Она обходит большинство заблокированных ресурсов.
Чел добавляет googlevideo.com. Он ломается.
Догадайтесь почему. <вступает в силу необходимость понимать что пишешь, а не копировать>

другая возможная причина тупняка - не настроен обход quic
да, quic они тоже замедляют. работает --dpi-desync=fake.
его нельзя сочетать с ttl.
возможно, какие-то ТСПУ еще не научились разбирать kyber quic, потому на них дефолтный хроме может обходить замедление сам по себе. потому в сети ходит противоречивая инфа то включать quic, то выключать. GDPI quic не поддерживает.
так же известно, что у ТСПУ исторически были проблемы с пакетами quic от разных библиотек разных версий. и на протяжении истории это менялось. они что-то доделывали.
с zapret-ом , наверно, лучше все-же сделать fake на quic. хуже не станет. и kyber тоже поддерживается

Еще немного наблюдений по поводу обхода замедления ютубе.

split2 работает, но исключительно потому, что позиция по умолчанию - 2.
Работает простой сплит на позиции 1 и 2. 3 байта в начале - это маркер TLS. Если DPI видит TLS оно начинает реассемблировать пакеты до получения full tls client hello. Внедрение кибера не оставила вариантов цензорам. Приходится реассемблить.
Поэтому простые сплиты на позиции более 2 не срабатывают.
Но работает практически любая мишура. fake, disorder2, oob, split.

Написал краткий FAQ по поводу обхода youtube средствами zapret :

Оказывается, не так все просто с windows 7 и готовым winws из комплекта zapret.

Требования к подписи драйверов windows изменились в 2021 году. Официальные бесплатные обновления windows 7 закончились в 2020. После этого несколько лет продолжали идти платные обновления по программе ESU. Именно в этих ESU обновлениях находится обновление ядра windows 7, позволяющиее загрузить драйвер windivert 2.2.2-A, который идет в поставке zapret.
Поэтому варианты следующие :

1. Взять windivert64.sys и windivert.dll версии 2.2.0-C или 2.2.0-D отсюда : Index of /download/
   и заменить эти 2 файла. В zapret-win-bundle есть отдельных 2 места, где находится winws : zapret-winws и blockcheck/zapret/nfq. Надо менять в обоих местах. Этот вариант проверен и должен работать. Тем не менее патч 10 летней давности, который включает SHA256 сигнатуры, все еще необходим.

2. Взломать ESU : Windows 7 ESU Patching · HackAndPwn
   Скрипт для установки и интеграции платных обновлений (ESU)
   и обновить систему

3. Использовать UpdatePack7R2 от simplix : https://blog.simplix.info
   Но с этим паком есть проблема. Автор из Украины, он очень обиделся на русских. Если в панели управления стоит регион RU или BY, появляется неприятный диалог. Чтобы эту проблему обойти, можно поставить временно любой другой регион, потом вернуть. Так же нет никаких гарантий, что автор не насовал туда какой-то зловредный код. Использовать на свой страх и риск.
   Более безопасный вариант - скачать последнюю нормальную версию : 22.2.10
   Набор обновлений UpdatePack7R2 для Windows 7 SP1 и Server 2008 R2 SP1 22.2.10 [Multi/Ru] :: NNM-Club
   Ее достаточно, чтобы windivert 2.2.2-A заработал на windows 7.

Оказалось, что утечки памяти ядра и падения кинетика при использовании nfqws к zapret отношения не имеют. Кинетик использует старое ядро с багом, который давно пофиксили, но в кинетике непатченная версия. Разрабы собираются выкатывать патч в новых прошивках

Очередное обновление.

Почистили немного C код по результатам статического и динамического анализа

В dvtws больше не используются raw сокеты для отсылки ipv4 пакетов. Вместо них используется divert. Поэтому “not sockarg” в правилах ipfw больше не нужно. Так же это призвано наладить совместимость с древними версиями BSD, где sockarg еще нет ( я не проверял, но кто-то писал issue, у него были проблемы из-за этого в freebsd 7.4, вышедшей в 2011 году ).
Но главной целью этого изменения было попробовать завести divert через divert-to в pf. Увы, попытка провалилась, идет зацикливание. Механизм предотвращения зацикливания divert в pf сломан в FreeBSD и как следствие в pf/opn sense включая версию ядра 14-RELEASE.
Кто-то выкатывал патч для ядра BSD, но видимо его еще не накатили в релизе.
А ipfw иногда глючит с pf вместе. Потому запуск dvtws на pf/opn sense может иметь неожиданные последствия.

В nfqws и tpws исправлен детект TLS ClientHello на очень старых криптолибах, которые шлют SSL 3.0 версию в TLS record layer , а в handshake - TLS 1.2. Старые телики самсунг, например.

nfqws и tpws теперь умеют логить --debug в файл и syslog.
syslog очень удобен на openwrt, потому что там используется logd с циклическим буфером в памяти. Читать через logread.
–debug параметр можно вносить в опции NFQWS или TPWS в конфиге, но лучше в самом начале, иначе не поймаются ошибки при анализе командной строки.

В tpws добавлена опция --connect-bind-addr. В ней можно задать ipv4 или ipv6 адрес, с которого будут выполняться исходящие подключения. Для указания и v4, и v6 можно опцию повторить.
Поддерживается и нотация fe80:xxxx:xxxx:…%interface_name для v6 link locals.
Однако , это не отменяет правил маршрутизации. Пакет пойдет на тот интерфейс, куда его направит система маршрутизации ip rule/ip route и прочее. Исключение - разве что link local. Там пойдет на тот интерфейс, который будет после %. По другому и нельзя применять link locals.
Так что не ждите чуда, чтобы направить коннект на какой-то специфический интерфейс.
На openwrt используются правила маршрутизации ipv6 с from, поэтому там это может сработать.
И не стоит удивляться, если вдруг вы указали адрес VPN, а в tcpdump оно идет на обычный инет с адресом обычного инета. Если default route на обычный инет более приоритетен, то ваш IP адрес VPN превращается через MASQUERADE в адрес обычного инета.
Вообщем, эта опция не есть панацея для выбора исходящего интерфейса сама по себе.

В tpws в режиме --debug добавлено логирование с какого enpoint-а (ip:source_port) идет подключение к удаленному ресурсу. Это может быть полезно для соотнесения лога tpws с дампом wireshark или tcpdump.

Немного переписана логика закрытия соединений в tpws.

Обнаружена такая проблема, что если клиент инициирует shutdown соединения, и нет неотосланных данных, tpws сразу же бросает оба конекта, не давая серверу дослать оставшиеся данные. Получается, клиент ждет последнего ответа, а ему приходит FIN, как будто сервер ничего не прислал.
Логика этой ситуации переписана с использованием вызова shutdown().
Теперь соединение через tpws должно корректно перекачивать все байтики до конца.
Так же сделан детект обрыва соединения через RST и воспроизведение RST на другом конце (leg).
Это секут броузеры. Если им приходит RST, они пытаются что-то делать еще, а если FIN, то могут посчитать, что сервер прислал пустышку (ошибка протокола).

В результате этих изменений могут появляться надолго подвисшие конекты через tpws, если один из концов принял соединение и повис, не отвечая на FIN.
Эта ситуация разрешается через FIN_WAIT timeout. Через какое-то время (до нескольких минут на BSD) соединения закроются.

Для смягчения вышеописанного недостатка с FIN_TIMEOUT на linux и macos сделал поддержку tcp user timeout. FreeBSD и OpenBSD не поддерживают.

–local-tcp-user-timeout и --remote-tcp-user-timeout устанавливают значение таймаута в секундах
для соединений клиент-прокси и прокси-сервер. Этот таймаут соответствует опции сокета linux
TCP_USER_TIMEOUT. Под таймаутом подразумевается время, в течение которого буферизированные данные не переданы или на переданные данные не получено подтверждение (ACK) от другой стороны.
Этот таймаут никак не касается времени отсутствия какой-либо передачи через сокет лишь потому,
что данных для передачи нет. Полезно для сокращения время закрытия подвисших соединений.
Поддерживается только на Linux и MacOS.

По умолчанию - 10 сек для local leg, 20 сек - для remote leg.
Если сделать 0, то setsockopt не будет выполнен, оставляя системное значение.

Проверил на эмуляторе android youtube app от google.
Тупит, не загружается.
Тупит на youtubei.googleapis.com и *.googlevideo.com
Остальное превьюшки - и еще что-то.
yt3.ggpht.com у меня вообще был заблокирован - зависание или RST

googlevideo.com
youtubei.googleapis.com
i.ytimg.com
yt3.ggpht.com

После задуривания всех этих доменов в режиме как на обход блокировок приложение работает нормально.

Провы по глупости стали дурить DPI, чтобы создать сиюминутное конкурентное преимущество.
В ответ в РКН включили особый режим против дурения на некоторых ggc.
Перестали работать фейки. Но им пришлось оставить разрешенными SNI от гуглодоменов.
Поэтому дописываем в стратегию --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin , и пока этого достаточно для дурения и блокировок, и ютуба.

Тем не менее чисто профилактически в nfqws заменен дефольный ClientHello на версию от firefox 128 без kyber. Сделана рандомизация SNI в формате [a-z][a-z0-9]{5}\.(com|org|net|edu|gov|biz)
Так же рандомизируются поля random и session id.
Рандомизация применяется только к дефолтному фейку. Если указать внешний файл для фейка - он будет как есть. Рандомизация выполняется 1 раз при старте nfqws.

Пофиксены 2 проблемы на архитектуре mips64 : сломаный seccomp filter и threaded resolver в tpws

В mdig пофиксено отображение статистики на 32-битных архитектурах с 64-битным time_t

МНОЖЕСТВЕННЫЕ СТРАТЕГИИ
nfqws способен по-разному реагировать на различные запросы и применять разные стратегии дурения. Это реализовано посредством поддержки множества профилей дурения. Профили разделяются в командной строке параметром --new. Первый профиль создается автоматически.
Для него не нужно --new. Каждый профиль имеет фильтр. По умолчанию он пуст, то есть профиль удовлетворяет любым условиям. Фильтр может содержать жесткие параметры : версия ip протокола или порты tcp/udp. Они всегда однозначно идентифицируются даже на нулевой фазе десинхронизации, когда еще хост неизвестен. В качестве фильтра могут выступать и хост-листы. Они могут сочетаться с жесткими параметрами. При поступлении запроса идет проверка профилей в порядке от первого до последнего до достижения первого совпадения с фильтром. Жесткие параметры фильтра сверяются первыми. При несовпадении идет сразу же переход к следующему профилю. Если какой-то профиль удовлетворяет жесткому фильтру и содержит авто-хостлист, он выбирается сразу. Если профиль удовлетворяет жесткому фильтру, для него задан хостлист, и у нас еще нет имени хоста, идет переход к следующему профилю. В противном случае идет проверка по хостлистам этого профиля. Если имя хоста удовлетворяет листам, выбирается этот профиль. Иначе идет переход к следующему.
Может так случиться, что до получения имени хоста соединение идет по одному профилю, а при получении хоста профиль меняется на лету. Поэтому если у вас есть параметры дурения нулевой фазы, тщательно продумывайте что может произойти при переключении стратегии. Смотрите debug log, чтобы лучше понять что делает nfqws.
Нумерация профилей идет с 1 до N. Последним в цепочке создается пустой профиль с номером 0.
Он используется, когда никакие условия фильтров не совпали.

ВАЖНО : множественные стратегии создавались только для случаев, когда невозможно обьединить имеющиеся стратегии для разных ресурсов. Копирование стратегий из blockcheck для разных сайтов во множество профилей без понимания как они работают приведет к нагромождению параметров, которые все равно не покроют все возможные заблокированные ресурсы. Вы только увязните в этой каше.

Мульти-профиль для tpws будет позже.
Рефакторинг был серьезный, поэтому необходимо тестирование !

Несколько практических замечаний по поводу мульти-стратегий.
Если используются скрипты zapret, то в опции NFQWS сначала пишите специальные стратегии для особых доменов. После них пишите --new и дальше то, что было там раньше.
Все свои “фишки” типа стандартных листов / автолиста скрипты zapret добавляют в конец - к последнему профилю десинхронизации.

НЕСОВМЕСТИМОЕ ИЗМЕНЕНИЕ.
В новой концепции профилей методы нулевой фазы десинхронизации несовместимы с хост-листами и больше не применяются !
Ранее они применялись , игнорируя хостлист.
Если у вас были стратегии с syndata или wssize и включен режим hostlist, то syndata и wssize не будут применены. Остальные методы 1 и 2 фазы будут применены как обычно.
Если включен режим autohostlist, то syndata и wssize будут применяться, поскольку профиль с autohostlist приоритетен.

Пример :
NFQWS_OPT_DESYNC="--hostlist=/opt/zapret_lists/list-youtube.txt --dpi-desync=split2 --new --dpi-desync=fake,split --dpi-desync-ttl=0 --dpi-desync-fooling=datanoack" NFQWS_OPT_DESYNC_HTTPS6="--hostlist=/opt/zapret_lists/list-youtube.txt --dpi-desync=fake,split2 --dpi-desync-ttl=5 --dpi-desync-fooling=datanoack --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin --new --dpi-desync=fake,split2 --dpi-desync-ttl=5 --dpi-desync-fooling=datanoack"

Вот так изменилось содержимое preset_russia.cmd для winws :
start "zapret: http,https,quic" /min "%~dp0winws.exe" --wf-tcp=80,443 --wf-udp=443 --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=11 --new --filter-tcp=80 --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new --filter-tcp=443 --hostlist="%~dp0list-youtube.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="%~dp0tls_clienthello_www_google_com.bin" --new --dpi-desync=fake,disorder2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig

windivert filter : это то, что захватывает ядро и передает процессу winws. Аналог ip/nf tables.
1 профиль : udp 443 - для quic
2 профиль : tcp port 80 - для http
3 профиль : tcp port 443 с листом list-youtube.txt . https для ютуба
4 профиль : все остальные https

Теперь продумайте логику как это работает.
Мы обрабатываем только порты 80 и 443 для tcp и порт 443 для udp.
Иного к нам не спустит windivert.

Если у нас порт udp 443, то применять fake.
Тут жесткая фиксация, udp на другой профиль попасть не может.

Если tcp port 80, то тут тоже все однозначно. Другой профиль невозможен

Если tcp port 443, то начало соединения на нулевой фазе идет по профилю 4.
Но т.к. нет методов нулевой фазы (wssize, syndata и тому подобное), то никаких действий не будет.
Как только получаем хостнейм из SNI, идет проверка заново по всем профилям.
1,2 профили отбрасываются , поскольку не удовлетворяют жесткому фильтру.
На 3 профиле идет проверка hostname по листу list-youtube.txt
Если хост в этом листе, выбирается профиль 3. Здесь происходит смена профиля на лету.
Иначе профиль остается как был - 4.

Посмотрим на preset_russia_autohostlist.cmd
start "zapret: http,https,quic" /min "%~dp0winws.exe" --wf-tcp=80,443 --wf-udp=443 --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=11 --new --filter-tcp=80 --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --hostlist-auto="%~dp0autohostlist.txt" --new --filter-tcp=443 --hostlist="%~dp0list-youtube.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="%~dp0tls_clienthello_www_google_com.bin" --new --dpi-desync=fake,disorder2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --hostlist-auto="%~dp0autohostlist.txt"

Разница только в наличии параметра --hostlist-auto. Причем он подтянут сразу к 2 профилям : 2 и 4.
Можно делать разные автолисты для жестких профилей, но можно использовать и 1 файл.
Почему я написал 2 раза автолист ? Потому что сперва идет проверка жесткого фильтра. Если у нас порт 80, до профиля 4 мы не доберемся, и автолист не будет задействован.
Автолист всегда надо писать на последнем профиле, к которому может дойти проверка на жестком фильтре. Если таких путей несколько, и вы хотите автолист на всех, то и писать надо во все места.
Но если бы вы написали автолист на профиле 3, это была бы большая глупость.
До профиля 4 дело бы вообще не дошло, и все бы обслуживалось по профилю 3.

Теперь подумайте куда надо было бы написать wssize и syndata для https, если бы они были в стратегии. Правильный ответ - в профиль 4. Даже для ютуба, который идет по профилю 3. И они будут применятся ко всем сайтам, потому что не фильтруются по хостлисту.

А что будет со старыми конфигами ? Ничего не будет. Они так же будут работать по единственному профилю. За исключением упомянутого выше несовместимого изменения. Если в стратегии были syndata или wssize, и был задан режим hostlist, стратегия полностью или частично перестанет работать. Например, может пропасть ютубе на телике, но остаться на компе (тк TLS 1.2 перестал обходиться). В последнем случае меняйте стратегию или отказывайтесь от hostlist. Чтобы работало как раньше, надо было бы дописать еще один профиль c wssize/syndata, но уже после дополнительных параметров с листами, которые сформируют скрипты zapret. Пока это не реализовано в основном функционале, хотя может быть сделано через custom script.

Почему нельзя было бы сделать как раньше сразу ? Представьте такой вариант
--hostlist a --wssize 1:6 --new --hostlist b --wssize 2:5
хостнейм мы не знаем. что выбирать ?

Решение проблемы с несовместимостью wssize/syndata с MODE_FILTER=hostlist.

Добавлены переменные конфига

#NFQWS_OPT_DESYNC_SUFFIX="--dpi-desync=syndata"
#NFQWS_OPT_DESYNC_HTTP_SUFFIX="--dpi-desync=syndata"
#NFQWS_OPT_DESYNC_HTTPS_SUFFIX="--wssize 1:6"
#NFQWS_OPT_DESYNC_HTTP6_SUFFIX="--dpi-desync=syndata"
#NFQWS_OPT_DESYNC_HTTPS6_SUFFIX="--wssize 1:6"

Значения по умолчанию копируются в незаполненные специализированные версии аналогичным образом, как и в основных параметрах.
К параметрам nfqws добавляется --new <suffix_strategy>.
Итоговые параметры nfqws могут быть такими : <main_strategy> --hostlist=ipset/zapret-hosts-user.txt --new <suffix_strategy>

Реальный пример.
У вас раньше стояло так :

MODE_FILTER=hostlist
NFQWS_OPT_DESYNC_HTTPS="--dpi-desync=fake --dpi-desync-fooling=datanoack --wssize 1:6"

Это перестало работать.
Надо сделать так :

MODE_FILTER=hostlist
NFQWS_OPT_DESYNC_HTTPS="--dpi-desync=fake --dpi-desync-fooling=datanoack"
NFQWS_OPT_DESYNC_HTTPS_SUFFIX="--wssize 1:6"

Здесь вы явно указываете, что wssize применяется всегда, вне зависимости от хостлист фильтра.
Так было и раньше, но теперь старый вариант указания параметров не работает.
Менять запись нужно только если MODE_FILTER=hostlist. Если там что-то еще - не нужно. Наоборот, если вы уберете wssize из основных параметров и напишите в суффикс без MODE_FILTER=hostlist, то wssize опять перестанет работать, поскольку дело не дойдет до suffix профиля.

Чтобы wssize работал всегда вне зависимости от MODE_FILTER, можно написать так :

NFQWS_OPT_DESYNC_HTTPS="--dpi-desync=fake --dpi-desync-fooling=datanoack --wssize 1:6"
NFQWS_OPT_DESYNC_HTTPS_SUFFIX="--wssize 1:6"

tpws тоже переделан на множественные стратегии

Работают аналогично nfqws, кроме некоторых моментов.
Нет параметра --filter-udp, поскольку tpws udp не поддерживает.
Методы нулевой фазы (–mss) могут работать по хостлисту в одном единственном случае :
если используется режим socks и удаленный ресолвинг хостов через прокси.
То есть работоспособность вашей настройки в одном и том же режиме может зависеть от того,
применяет ли клиент удаленный ресолвинг. Это может быть неочевидно.
В одной программе работает, в другой - нет.
Если вы используете профиль с хостлистом , и вам нужен mss, укажите mss в профиле с хостлистом,
создайте еще один профиль без хостлиста, если его еще нет, и в нем еще раз укажите mss.
Тогда при любом раскладе будет выполняться mss.
Используйте curl --socks5 и curl --socks5-hostname для проверки вашей стратегии.
Смотрите вывод --debug, чтобы убедиться в правильности настроек.

В стандартных скриптах запуска --mss так же копируется в suffix и используется оттуда при MODE_FILTER=hostlist.

MODE_FILTER=hostlist
TPWS_OPT="--hostspell=HOST --split-http-req=method --split-pos=3 --oob --mss 88"
TPWS_OPT_SUFFIX="--mss 88"

Это несовместимое изменение 1.
Несовместимое изменение 2 - удалена опция --mss-pf за ненадобностью. Функция реализована через профили.

В blockcheck внесена поддержка переменных
TPWS_EXTRA - для tpws
PKTWS_EXTRA - для nfqws/dvtws/winws
эти переменные добавляются к параметрам тестовых запусков соотв демонов

основное применение - включение разных внешних пейлоадов

PKTWS_EXTRA="--dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin" ./blockcheck.sh

чтобы не уродовать код скрипта ради сиюминутных частных веяний и хотелок

Дополнение к *_EXTRA.

Похоже, что нельзя адекватно в стандартную шелл переменную засунуть множество аргументов командной строки для вызываемого процесса.
Проблема в пробелах.

Допустим, у нас PKTWS_EXTRA=“–hostcase --hostnospace”
Я передаю эту переменную как есть $PKTWS_EXTRA без кавычек в дочерний процесс.
Получается 2 аргумента. Все хорошо.

но что делать, если PKTWS_EXTRA=“–hostcase --dpi-desync-fake-tls=”/opt/xxxx xxx xxx/fake.bin""

Нельзя никак сделать, чтобы стало 2 аргумента. И так, и сяк пробовал. Нет нормального способа разделить корректно. Будет или 1 аргумент, или огрызки, или будут передаваться кавычки как есть в процесс. А это - неправильно и не сработает.

Возможно, есть решение через какие-то внешние стандартные команды, но скрипт затачивается на огрызочный busybox environment. Там нет ничего advanced. И баша тоже нет.

Решение такое

PKTWS_EXTRA остается
В него можно совать аргументы через пробел, где в отдельно взятом аргументе нет пробелов.
Если пробелы есть или просто так по желанию можно использовать PKTWS_EXTRA_1 , PKTWS_EXTRA_2, … , PKTWS_EXTRA_9

корректно будет так :

PKTWS_EXTRA_1=“–hostcase” PKTWS_EXTRA_2=“–dpi-desync-fake-tls=/opt/xxxx xxx xxx/fake.bin” ./blockcheck.sh

Если у вас cygwin, то обратные слэши не подходят. Надо обратные слэши в пути перевернуть в прямые. Или использовать cygwin пути : /cygdrive/x/path/to/file.bin.
В скриптах для автоматизации конверсии путей надо использовать команду cygpath.
Пример cygpath есть в blockcheck.cmd

Аналогичная схема реализована и для TPWS_EXTRA

Сделал проверку в blockcheck на уже запущенные процессы zapret и вывод предупреждения, если они есть.
Только предупреждение. Блокчек ничего не знает об install_easy, о способе запуска этих процессов, не знает ничего о службах systemd, openrc, sysv, ничего не будет останавливать и трогать. Только warning.
Наличие процессов может свидетельствовать о неободимости остановить службу zapret, а может ни о чем не свидетельствовать. Например, болтается инстанс на порт wireguard или tpws --socks.
Сами думайте надо ли что-то делать или нет.

Сделал еще детект goodbyedpi. Он тоже будет мешать блокчеку

-filter-udp=50000-65535 --dpi-desync=fake,tamper --dpi-desync-any-protocol --dpi-desync-autottl=2 --dpi-desync-repeats=11

отсутствие понимания создает огромную проблему, и она множится от копипасты
запрет не будет думать за вас
он будет срать 11 пакетами на каждый реальный как вы ему и сказали
причем не только на дискорд
торентики в 10 раз замедлились на раздачу ? вот поэтому, что вы трэш написали

desync any protocol нуждается в connbytes или cutoff ограничителе.
пример взят c винды, где connbytes нет

в добавок в этом примере tamper - лишний. он работает пока только с DHT.
а так же autottl не будет работать на всех провайдерах. или вообще, или потребуется поиск рабочей delta. Для каких-то протоколов это не так важно, потому что сервер отбрасывает невалидные пакеты, даже если они до него дошли. Типичный пример - QUIC. А для других может испортить что-то.
Поскольку нет фильтра по IP, а только по портам, то насиловаться будут все udp с портами 50000+. И что-то может сломаться. Совершенно неожиданно и внезапно.

Добавлена поддержка множественных custom скриптов в директориях custom.d

Сделаны экспериментальные custom скрипты 50-discord.
Автор не изучал блокировку этого сервиса. Сделано с информации community.
Можете дополнять, изменять и оптимизировать.

Сделаны скрипты получения листов get_refilter_ipsum.sh, get_refilter_domains.sh

Если вкратце, то это интеллектуальная попытка расчистить нарко-казиношный трэш из реестра

Сделаны ipset-ы в tpws и nfqws. User mode реализация, которая ни в коей мере не должна быть использована как удобная замена сложным ковыряниям в ip/nf tables лишь потому, что это просто и удобно. Это будет порочной практикой. Сделано для систем windows и linux без ipset (Android, например)

ipset-ами фильтруются профили. ipset является жестким фильтром, он работает сразу после первого пакета.

Поддержка фильтрации L7 (–filter-l7). L7 протокол становится известен обычно после первого пакета с данными вместе с hostname. Поэтому он не работает для нулевой фазы. На нулевой фазе L7 всегда равен unknown.

autohostlist debug log теперь содержит ip:port клиента и название L7 протокола. В postnat режиме вы не увидите ip клиента, а увидите endpoint самого роутера, с которого идет внешний конект.

custom scripts
Переменные FW_EXTRA_PRE, FW_EXTRA_POST для добавления строчки в nft rule или iptables rule до и после правила zapret. Можно использовать как локальные переопределения для одной или более операций в своих custom скриптах.
Например, вам очень нужно дурить DPI только для клиентов с одной подсети. Если используется postnat режим, сначала надо маркировать пакеты каким-то битом, не конфликтующим с nfqws, а
затем добавлять фильтр по mark.

Чтобы исключить конфликты по номерам портов , демонов и очередей введена динамическая аллокация через хелперы alloc_dnum, alloc_qnum alloc_tpws_port.

Новая функция zapret_custom_firewall_nft_flush предназначена для зачистки своих цепочек и set-ов. Нужна только, если таковые есть. Стандартные цепочки zapret чистятся автоматически.

Новые скрипты получения ip и host листов get_refilter_ipsum.sh , get_refilter_domain.sh

Багфиксы.
Зависание tpws/nfqws с 100% cpu usage, если хостлист в gzip и содержит комментарий.
Исправлено применение autottl при смене профиля на лету.
tpws: исправлено не-применение MSS в transparent proxy mode.

zapret-win-bundle. Обновлен preset-russia на поддержку discord voice. Фильтруется по портам и ipset.
Добавлен killall.exe и reload_lists.cmd для перечитки листов без убивания процесса. Может не работать с сервисом и scheduled task !

32-битная версия под windows : GitHub - bol-van/zapret-win32

Сделан минимальный вариант запуска tpws на openwrt для систем с ограниченным местом на диске.
init.d/openwrt-minimal
Требования к диску от 120 до 200 кб. 200 кб - для iptables и ipv6

Управление конфигом tpws через UCI : /etc/config/tpws. Управление фаерволом через файлы /etc/firewall.user для iptables и /etc/nftables.d/90-tpws.nft для nftables

Собираюсь убирать все это хозяйство с HTTP,HTTPS,QUIC,MODE
Оно создавалось под вариант, когда не было мультистратегий и фильтров.
Сейчас натягивают сову на глобус, пытаясь запихнуть в QUIC незапихуемое только потому, что там udp. Это полнейший misuse и трэш.
Будет несовместимое изменение, полностью ломающее старый конфиг.
Конфигурация будет приближена к winws.
Отдельно настраиваем перехват по портам и отдельно опции единственного инстанса nfqws и/или tpws.
Стандартный autohostlist будет в виде переменной $AUTOHOSTLIST, стандартный hostlist - $HOSTLIST. Куда надо, туда и воткнете. Будете сами думать куда. Как в винде.
Скачивание сетов/листов будет отдельно настраиваться.

Кастомы останутся, но уже без MODE=custom. Достаточно их наличия.
Могут быть варианты, не вписывающиеся даже в новую схему.
Тот же дискорд требует особого ipset. Проводить в конфиг - это слишком частно, такого не будет.
На винде ipset идет через параметр --ipset winws, а на не винде это порочная практика. Естественно, по незнанию и по упрощению будут насиловать несвойственным образом, но это ненормально. Надо использовать kernel ipsets.
Думаю воткну в инсталятор проверку на наличие параметра --ipset и принудительный отказ продолжать. Иначе один кто-то напишет, а потом по сети этот копипастный трэш будет распространяться.

Масштабное переосмысление системы запуска под linux,openwrt,macos.
Конфиг потерял совместимость.
Инсталлятор при замещении /opt/zapret будет предупреждать о несовместимости параметров и отказываться их сохранять. Придется настраивать заново.

Основная причина рефакторинга - приведение конфига к функции мульти-стратегий.
Больше не надо разделять на инстансы http, quic и прочее.
Не надо натягивать сову на неестественные места. В сети распространились конфиги, где дискорд пытаются засунуть в QUIC.

Больше нет никаких http, https, quic.
Есть отдельно настраиваемые параметры запуска tpws, tpws-socks, nfqws и параметры перехвата трафика через ядро (iptables, nftables).
Очень похоже на вариант winws на windows.
Параметра MODE тоже больше нет. Стандартные режимы имеют свои выключатели и включаются независимо, а custom scripts применяются просто по факту их наличия в custom.d
Можно легко комбинировать tpws и nfqws вместе, и потом на эту систему подвесить еще tpws socks для получения обходного прокси.

custom скрипты inherit больше не нужны. Если их не убрать, будет рекурсивное зацикливание.

Применение стандартных хостлистов идет через маркер <HOSTLIST> в конфиге. Скрипты подставляют на его место фактические параметры листов из ipset в зависимости от MODE_FILTER и убирают, если не задана фильтрация по хостлистам.

Особо читайте раздел “Выбор параметров” в readme.txt, а так же docs/quick_start.txt.

Еще одно слабое место остается в nfqws и tpws.
При дублировании хостлистов по профилям они дублируются и в памяти.
Если листы большие - занимаемая память увеличивается кратно.
Так сделано из-за обьединения всех листов одного типа.
Если 1 профиль имеет хостлист a и b, а другой имеет b, то фактически это разные хостлисты в памяти, поскольку список “a+b” - не a и не b. Там не отделить одно от другого.
Надо хранить все листы в памяти раздельно и проверять несколько штук в 1 профиле тоже раздельно. И делать дедупликацию. Не загружать заново.
Аналогично и с ipset

В blockcheck сделана поддержка DoH.
Она включается автоматически, если обнаружена подмена DNS.
Чтобы включить или выключить принудительно, можно использовать переменную
SECURE_DNS=0|1
В код зашит список из 5 открытых ресолверов DoH. Проверяются все по очереди до первого работающего. Этот и используется.
Переопределить список для поиска можно в переменной DOH_SERVERS. Задать конкретный сервер можно через DOH_SERVER.

Технически ресолвинг опирается на обновленный mdig и выполняется так :
mdig --family=6 --dns-make-query=rutracker.org | curl --data-binary @- -H "Content-Type: application/dns-message" https://cloudflare-dns.com/dns-query | mdig --dns-parse-query

Поэтому он не требует никакого специального софта и может работать на openwrt без плясок.
Встроенная поддержка doh в curl может во-первых не быть, во-вторых он будет каждый раз призадумываться. В blockcheck сделано кэширование DNS записей, и этот вариант не очень сочетается.

В blockcheck сделана фильтрация только по IP:port тестируемого в настоящий момент домена.
Все остальное больше не трогается. Не рушит на час работу броузера.

upcoming release 67 notes

Самое главное изменение - переделана система внутреннего управления листами в nfqws и tpws.
Если раньше листы одного профиля кидались в общую неделимую кучу и загружались заново для каждого следующего профиля, то теперь листы все загружаются отдельно, исключая повторы.
Если раньше вы писали <HOSTLIST> в 3 профилях и использовали большой РКН лист, то требуемая память умножалась на 3 и могла доходить до внушительных для слабых систем значений. Теперь это больше не так.

--filter-tcp=80 --dpi-desync=fake,split2 --dpi-desync-fooling=md5sig <HOSTLIST> --new \
--filter-tcp=443 --dpi-desync=fake,disorder2 --dpi-desync-fooling=md5sig <HOSTLIST> --new \
--filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=6 <HOSTLIST> --debug

lists summary:
hostlist file /opt/zapret/ipset/zapret-hosts-user-exclude.txt
hostlist file /opt/zapret/ipset/zapret-hosts.txt.gz
hostlist file /opt/zapret/ipset/zapret-hosts-user.txt
profile 1 include hostlist /opt/zapret/ipset/zapret-hosts.txt.gz
profile 1 include hostlist /opt/zapret/ipset/zapret-hosts-user.txt
profile 1 exclude hostlist /opt/zapret/ipset/zapret-hosts-user-exclude.txt
profile 2 include hostlist /opt/zapret/ipset/zapret-hosts.txt.gz
profile 2 include hostlist /opt/zapret/ipset/zapret-hosts-user.txt
profile 2 exclude hostlist /opt/zapret/ipset/zapret-hosts-user-exclude.txt
profile 3 include hostlist /opt/zapret/ipset/zapret-hosts.txt.gz
profile 3 include hostlist /opt/zapret/ipset/zapret-hosts-user.txt
profile 3 exclude hostlist /opt/zapret/ipset/zapret-hosts-user-exclude.txt

Кроме того сделана автоматическая перечитка всех листов при изменении времени модификации файлов. HUP больше не нужен.
Исчезновение какого-либо файла листа или потеря доступа к нему больше не является фатальной проблемой. Раньше демоны в этом случае аварийно завершались. Сейчас в этой ситуации ничего страшного не случится. Будет использоваться копия в памяти. При появлении файла или возобновлении доступа он опять будет проверен на время изменения и при необходимости перегружен.
Перегрузка выполняется не сразу, а только по факту использования данного листа.

Все сказанное полностью распространяется и на user mode ipsets.

Параметры --filter-tcp, --filter-udp теперь берут список портов или диапазонов портов через запятую.
Особый знак * есть синоним 1-65535.

В конфиге в опциях tpws и nfqws введен еще 1 маркер <HOSTLIST_NOAUTO>.
Он аналогичен <HOSTLIST>, только ipset/zapret-hosts-auto.txt для текущего профиля вставляется как обычный лист, что позволяет выключить логику распознавания блокировок.
Если другой профиль обновил автолист, остальные профили принимают изменения автоматически, поскольку теперь это хранится в одной области памяти без дублирования.

blockcheck теперь дурит только IP:port тестируемого домена. Все остальное не затрагивается.
Введена поддержка DoH серверов, которая включается автоматически при обнаружении подмены DNS.
Элевация до рута сохраняет переменные исходного юзера. Больше не надо получать сначала рутовый шелл, чтобы скармливать переменные blockcheck.
blockcheck не проводит элевацию до рута, если SKIP_PKTWS=1 или система MacOS (тк там всегда только tpws)

Репозиторий zapret-win32 удален. Его содержимое перемещено в основной репозиторий в binaries/win32.
win64/zapret-winws так же удален. Его содержимое осталось только в zapret-win-bundle.

nfqws: исправлено вероятное падение при включении опций --hostcase, --hostnospace, --domcase

В nfqws, tpws поддерживается чтение конфига из файла через первый и единственный параметр @<config_file>

release 68

Удалены binaries. Binaries теперь только в релизах, собираемых через github actions.
Русская документация переведена в markdown.
nfqws,tpws: альтернативное использование знака ‘$’ для чтения параметров запуска из файла :$<config_file>
uninstall_easy.sh: предложение удалить зависимости на openwrt
install_easy.sh: предложение скачивать хостлисты в режиме фильтрации autohostlist
Багфиксы

На традиционных *nix платформах по-прежнему можно использовать основную репу без бинариков. Их можно собрать самому, имея cc, make и необходимые dev пакеты : zlib1g-dev libcap-dev libnetfilter-queue-dev. install_easy.sh при отсутствии бинариков сам запустит make. Но установка dev пакетов и компилятора - на вас.
Так же актуализирована и дока по сборке на openwrt под SDK в docs/compile

zapret v69

• nfqws,tpws : поддержка сплита на нескольких позициях : multisplit и multidisorder
• nfqws : переименование split => fakedsplit , disorder => fakeddisorder. старые варианты остаются как синонимы.
• nfqws : депрекация --dpi-desync-split-http-req, --dpi-desync-split-tls. старые параметры добавляют split позиции к списку.
• nfqws : split2 и disorder2 становятся синонимами multisplit и multidisorder. сохраняется автоматическая split позиция 2, если не указано --dpi-desync-split-pos.
• nfqws : отмена seqovl без отмены desync в случае превышения MTU. только для Linux.
• nfqws : seqovl берет позиционные маркеры для disorder и только число для split
• tpws : депрекация --split-http-req , --split-tls. старые параметры добавляют split позиции к списку.
• tpws : --tlsrec берет позиционные маркеры, а не только фиксированные смещения
• tpws : депрекация --tlsrec-pos. старый параметр создает абсолютный положительный маркер.
• tpws : починка не срабатывающего мультисплита через --fix-seg
• nfqws,tpws : назначение владельца лог файлам и автохостлисту после парсинга всех опций
• nfqws,tpws : установка переменной окружения EXEDIR для использования в @config
• dvtws : установка рандомного поля ip_id вместо нулевого
• repo : бинарники для android API level 21+ (Android 5.0)
• install_easy : поддержка APK packet manager в openwrt
• blockcheck : убран вопрос “игнорировать сертификаты”
• blockcheck : убраны переменные IGNORE_CA, CURL_VERBOSE. вместо них добавлена переменная CURL_OPT.
• blockcheck : поддержка новых стратегий multisplit
• blockcheck : переработка порядка тестирования стратегий
• blockcheck : показ всех рабочих стратегий в summary
• багфиксы

zapret v69.1

1. tpws : исправлена логика процессинга хостлистов в режиме --socks5-hostname и логика обработки неизвестного протокола с хостлистами.
2. 10-keenetic-udp-fix : лечащая добавка для кинетика против отсутствия маскарада без ndmmark

zapret v69.2

• nfqws,tpws: новый параметр --skip для временного исключения профиля без удаления параметров
• nfqws: новый параметр --methodeol. убрать пробел после Host: и добавить \n перед методом
• init.d: не использовать pgrep в sysv для совместимости с busybox (keenetic, прошивки, alpine)

zapret v69.4

• nfqws: обрамление фейками обоих сегментов в fakedsplit/fakeddisorder
• nfqws: задание содержимого фейков в fakedsplit/fakeddisorder через --dpi-desync-fakedsplit-pattern
• багфиксы

На некоторых операторах такой зоопарк, что без обрамления обоих сегментов fakedsplit не пробивает.
Долго думал почему. Резал и по midsld. Нифига не работало.
Как он определяет какие фейки, какие нет, если все идет подряд с одинаковой длиной и sequence, а во втором куске нет полного имени хоста ? Но по факту если второй кусок тоже облепить, то работает

zapret v69.5

• nfqws,tpws: опция проверки параметров командной строки без фактического запуска --dry-run
• install_easy: проверка параметров командной строки tpws и nfqws

zapret v69.6

• nfqws: Установка NETLINK_NO_ENOBUFS для NFQUEUE. Решает проблему с аварийным выходом процесса на некоторых системах (keenetic).
• init.d: Унификация custom скриптов для linux. Удалены init.d/{openwrt,sysv}/custom.d.examples. Скрипты теперь имеют формат как раньше для sysv, примеры находятся в `init.d/custom.d.examples.linux’. Совместимость со старым openwrt вариантом сохраняется. Но копипастные инструкции немного слетят.
• init.d: Новый custom скрипт 20-fw-extra. Например, для тех, кому нужно дурить трафик через nfqws только с одного входящего интерфейса и не дурить с остальных.
• init.d: Новый custom скрипт 50-wg4all. Ищет в ядре udp пакеты wireguard handshake initiation на любые порты и перенаправляет на nfqws.

Пояснения на счет 20-fw-extra.
Меня не раз спрашивали что делать, если надо дурить на nfqws только одну внутреннюю сеть, а другую нет. Чтобы был публичный wifi с ограничениями и непубличный wifi для своих, например. Обычно я предлагал отказаться от скриптов и запускать руками.
Но теперь эта задача может быть решена и на уровне скриптов.
Главная проблема - отсутствие возможности в стандартном варианте задавать свои условия ip/nf tables. Вторая проблема - невозможность фильтрации по внутренним IP в варианте nftables при использовании схемы postnat.
Задача решается примерно так :

1. Разнести их на разные подсети и интерфейсы. Так проще будет понять нужно ли им дурение. Хотя, если вы можете назначать “своим” особые IP адреса, можно и по ним тоже сечь.
2. Сделать NFQWS_ENABLE=0 в config.
3. Переписать init.d/custom.d.examples.linux/20-fw-extra в custom.d
4. Настроить config :

NFQWS_ENABLE_OVERRIDE=1
FW_EXTRA_PRE_NFQWS_IPT="-m mark --mark 0x10000000/0x10000000"
FW_EXTRA_PRE_NFQWS_NFT="mark and 0x10000000 != 0"

5. Отдельными средствами маркировать битом 0x10000000 пакеты, предназначенные для дурения на этапе до POSTROUTING. Для проходящего трафика это можно сделать в PREROUTING, для исходящего с самой системы - в OUTPUT.

50-wg4all - это простое решение для дурения любого wireguard, не требующее настройки по портам и чему-либо еще. Переписал и работает. Оверхеда на системе практически не создает.
Единственная возможная настройка - стратегия дурения в config : NFQWS_OPT_DESYNC_WG.
По умолчанию - --dpi-desync=fake. Туда можно добавить репиты по необходимости.

zapret v69.7

• nfqws,tpws: параметр --comment. любые комментарии в любом месте.
• nfqws: предупреждение о возможной “ТРЭШ ФЛУД” конфигурации. Когда пишите --dpi-desync-any-protocol без --dpi-desync-cutoff и используете методы с фейками. Это не всегда плохо, но когда плохо, то очень плохо.
• winws: многократное снижение использования процессора за счет отказа от процессинга пустых TCP ACK пакетов в --wf-tcp
• nfqws: в android версии исправлен bad system call при завершении процесса

zapret v69.8

1. winws: обработка пустых исходящих TCP с FIN или RST в --wf-tcp для нужд conntrack
2. repo: сборка под mips-rlx5281 (lexra)

Где-то месяца два назад пробовал смотреть почему не работает приложение youtube TV.
Оно использует GQUIC, который zapret не опознает и не реагирует на него.
Думал уже надо делать поддержку GQUIC.
Но поставив свежую версию с apkmirror обнаружил, что GQUIC больше нет, есть IETF QUIC, и все и так работает.
Следовательно страждующим - обновляйте приложение.

У меня заработало вот это
com.google.android.youtube.tv_5.21.300-521300320_minAPI24(armeabi-v7a)(nodpi)_apkmirror.com.apk

На эмуляторе genymotion под образом android 12 версия для x64 не работает, но не из-за блокировки, а по причине отсутствия чего-то в системе. Возможно, кодеков. На реальном устройстве заработало без проблем

Делаю вывод, что тратить силы на поддержку GQUIC не имеет смысла, тк протокол устаревший, и используется только в старых версиях отдельных приложений. И есть обновление, которое отказалось от использования этого протокола

Приложение Android TV завелось на чистом Android 9 (не сток) без установленных gapps. Официальные требования - Android 7.0+. Следовательно, могу предположить, что требования не очень мощные, и должно пойти на достаточном количестве устройств. Но должно быть какие-то старые телики и приставки обломаются, поскольку нельзя на них обновить версию приложения.
Android 5.0 поддерживают только старые версии приложения 2.x

Для владельцев старых девайсов можно сделать дурение всего UDP на 443 без листов
--filter-udp=443 --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d2 --dpi-desync-repeats=СКОЛЬКО_НАДО
Хуже не будет

Или отдельно для quic через `–filter-udp=443 --filter-l7=quic", затем вышеописанное

В блокчеке 2 нововведения

1. Переменная PARALLEL=1 включает параллельные попытки тестирования стратегий. По умолчанию не включается из-за опасности обидеть сайт дятло-долбежкой и получить неверный результат.

2. Возможность задать ответы на диалоговые вопросы через переменные и убрать тем самым эти вопросы. Чтобы сразу запускался процесс и не было вопросов на что-нибудь нажать или что-нибудь ввести.
   CURL_MAX_TIME=1 CURL_MAX_TIME_QUIC=2 SKIP_DNSCHECK=1 DOMAINS=nnmclub.to IPVS=46 ENABLE_HTTP=1 ENABLE_HTTPS_TLS12=1 ENABLE_HTTPS_TLS13=1 ENABLE_HTTP3=1 REPEATS=8 PARALLEL=1 SCANLEVEL=standard BATCH=1 ./blockcheck.sh

Для использования с релизом достаточно заменить файл blockcheck.sh из git.

v70.5

• nfqws: множественные фейки для всех типов протоколов через указание множественных параметров --dpi-desync-fake-???. (кроме syndata, это - не протокол)
• nfqws: поддержка меж-пакетной дефрагментации QUIC фреймов CRYPTO. так стали делать свежие chrome броузеры. на более старой версии пакеты не собираются, хост не вытаскивается

Если не обновлять pktws, на последних chrome слетит дурение quic и перестанут работать хостлисты по quic. Либо придется отключать KYBER