Использую GDPI для доступа к ютубу с помощью фрагментации HTTPS пакетов. Полет нормальный. решил поставить на роутер чтоб все устройства имели доступ к ресурсу. Не работает как с nfqws

/opt/zapret/nfq/nfqws --qnum=201 --user=daemon --dpi-desync-fwmark=0x40000000 --wssize=1:6 --dpi-desync=split --dpi-desync-ttl=0 --dpi-desync-fooling=badsum

так и с tpws:

/opt/zapret/tpws/tpws --user=daemon --bind-addr=127.0.0.127 --port=988 --split-any-protocol --split-pos=1 --split-http-req=method

при этом нет никаких ошибок, служба запущена, но функцию свою не выполняет.

Заранее благодарю.

Как вы запускаете GoodbyeDPI?
Вы делали дамп трафика, смотрели, что конкретно делает nfqws/tpws? Быть может, в вашем случае только фрагментации недостаточно?

Опция wssize нужна для сервера, а не для клиента (для того, чтобы nfqws устанавливать на заблокированный сервер). Вам нужна опция wsize для фрагментации (но фрагментация изменением Window Size — устаревший и нерекомендуемый метод).
dpi-desync-ttl=0 отключает отправку поддельного пакета, которая и так не активирована по умолчанию.

Теперь я совсем запутался.

Какой метод лучше использовать? tpws или nfqws

Вы можете мне дать готовую команду при которой будет только фрагментация пакетов по https со значением 1 и все. Так как на ПК GDPI именно так и работает с ключом -e 1 и все открывается.

nfqws более функциональный, чем tpws.
nfqws --wsize 1 является полным аналогом goodbyedpi.exe -e 1.

Подредачил конфиг при установке:

NFQWS_OPT_DESYNC=“”
NFQWS_OPT_DESYNC_HTTP=“”
NFQWS_OPT_DESYNC_HTTPS=“–wssize=1”
NFQWS_OPT_DESYNC_HTTP6=“”
NFQWS_OPT_DESYNC_HTTPS6=“”

При запуске службы выдает сразу 2:

Starting daemon 1: /opt/zapret/nfq/nfqws --qnum=200 --user=daemon --dpi-desync-fwmark=0x40000000
Starting daemon 2: /opt/zapret/nfq/nfqws --qnum=201 --user=daemon --dpi-desync-fwmark=0x40000000 --wssize=1

не работает.

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

Борьба продолжается.
Запустил отдельно с ключом как и подсказали.

./nfqws --wsize 1

получаем:
opening library handle
unbinding existing nf_queue handler for AF_INET (if any)
binding nfnetlink_queue as nf_queue handler for AF_INET
binding this socket to queue ‘0’
setting copy_packet mode
initializing raw sockets bind-fix4=0 bind-fix6=0
Running as UID=2147483647 GID=2147483647

всё должно работать, но нет.

так же как писал выше что использую свой хост файл как дополнительный и прописал его настройках роутера как дополнительный и всеравно тщетно.

Может подскажите в какую сторону двигаться, а то кроме вашего форума и почитать больше негде.
ПС. На компе все работает на УРА (с заменой хост файла на свой)

Забудьте про --wsize. Это устаревший параметр. Для его использования нужно пенеправлять 1 пакет SYN,ACK из входящего трафика, а не исходящего.
Тот же эффект и без побочных эффектов достигается при использовании параметра dpi-desync=split2.

Чтобы не гадать, для того и придумал blockcheck.sh . Прогоните его и не мучайтесь

–wssize нужен, чтобы заставить сервер разбить на части TLS ServerHello. Эта опция снижает скорость, использовать как последнее средство

Я бы с удовольствием прогнал blockcheck.sh еще в самом начале, но он постоянно жалуется на разные проблемы и не хочет запускаться вовсе. На данный момент жалуется на NFQUEUE:

NFQUEUE iptables or ip6tables target is missing. pls install modules.

Хотя все уже установлено и службы работают стабильно.

iptables -t mangle -I PREROUTING -j NFQUEUE --queue-num 3 --queue-bypass
ip6tables -t mangle -I PREROUTING -j NFQUEUE --queue-num 3 --queue-bypass

Что выдает вот это ?
Иногда ошибку нужно смотреть еще и в dmesg

Система съедает команду iptables, и на этом все. Никаких изменений.
С ip6tables иначе, он не может принять ее так как полностью отсутствует поддержка ipv6.

Итак, на данный момент всё работает благодаря параметру dpi-desync=split2. За что огромная вам благодарность!

Однако, не сразу заметил так как работает ТОЛЬКО через браузер. Например, если зайти на сайт ютуба, то все будет работать безупречно, но если зайти в тюб через приложение (iOS, Android) то снова ничего работать не будет.

Возможно ли что приложение принудительно резолвится через гугловый днс? Так как гугловый днс в моем регионе забанен, то попахивает жареным.

Так как blockcheck.sh все еще не запускается посоветуйте еще возможные команды для пробы.

Заранее благодарен

Я так и предполагал. Но что тогда это за система ? openwrt , если это не какой-то кастомный билд, включает поддержку ipv6.

UPD. Убрал из blockcheck проверку на ipv6 nfqueue. Должно работать, если не соглашаться с проверкой ipv6

Точно можно ответить только посмотрев трафик через wireshark

Спасибо, помогло. Результаты теста следующие:

ipv4 youtube.com curl_test_http : tpws --split-http-req=method
ipv4 youtube.com curl_test_http : nfqws --dpi-desync=split2
ipv4 youtube.com curl_test_https_tls12 : tpws --split-pos=1
ipv4 youtube.com curl_test_https_tls12 : nfqws --dpi-desync=split2

Все остальное напрочь закрыто. Тут видно что и tpws работает, но на деле не так. Работает только nfqws, но мы это знали и до этого.

На данный момент проблема такая что не работают приложения (iOS, Android). Не принципиально, но хочется уже довести до ума.

tpws --split-pos и nfqws --split2 выполняют одно и то же действие
blockcheck тестирует доступность ресурса, запуская tpws и nfqws, а не каким-то третьим методом
если не работает, значит что-то сделано не так

на счет ios, простых решений не ждите, придется вам делать дамп трафика и выкладывать или анализировать самому

приложение лезет к google api, а не корневому веб сайту youtube.com
я попробовал установить на android, но это не получилось всилу требования google apps, которые выпилены на всех моих устройствах. тем не менее до падения приложение успевает залезть на youtube.googleapis.com.
вообщем, можно ожидать использования несколько других доменов, чем в веб версии
цель - сдампать трафик и выделить эти домены из TLS Client Hello (с quic initial или с обычного tls), проверить их доступность