del
Добавил профиль с фильтром tcp=443 и wsize=1500 без хостлистов, т.к. таковых не было. Не понимаю правда как это поможет с ютубом, если он должен обрабатываться по другому профилю. Не помогло.
Надо смотреть лог исчезла ли разбивка на входе и стал ли обрабатываться траф
до получения имени хоста профиль с хостлистом не задействуется
Нет, все равно встречаются пакеты с размером окна 2. Не знаю, как посмотреть, обрабатывается ли трафик, но ютуб не открывается.
В шарке это не будет видно. Там будет по-прежнему 2.
В дебаг логе не должны больше быть пакеты размера 2 с содержимым HEX 16 03
Должны быть надписи типа packet contains tls client hello
Пакетов длиной 2 нет, youtube как-будто обрабатывается:
Спойлер
packet contains full TLS ClientHello
hostname: www.youtube.com
we have hostname now. searching desync profile again.
desync profile search for hostname=‘www.youtube.com’ ipv6=0 tcp_port=443 udp_port=0
- Hostlist check for profile 3
Checking include hostlist
Hostlist check for www.youtube.com : negative
Hostlist check for youtube.com : negative
Hostlist check for com : negative - Hostlist check for profile 4
Checking include hostlist
Hostlist check for www.youtube.com : negative
Hostlist check for youtube.com : positive
desync profile 4 matches
desync profile changed by revealed hostname !
dpi desync src=192.168.219.103:9108 dst=142.250.185.238:443
split pos 1
sending fake request : 16 03 01 02 87 01 00 02 83 03 03 5F 15 63 CB 06 EA 1C DD 40 76 F5 8C 44 50 6E 01 F3 A3 83 AC C2 … : …_.c…@v…DPn… …
sending 1st tcp segment 0-0 len=1 seqovl=0 : 16 : .
sending 2nd tcp segment 1-1411 len=1411 : 03 01 09 93 01 00 09 8F 03 03 57 1E 77 2A F4 AE 3C 4A 02 11 91 A9 49 58 59 96 C0 CA 32 9A AF 2B … : …W.w*…<J…IXY…2…+ …
Во. Что и требовалось. Дурку провайдера преодолели.
Дальше дело за поиском рабочей стратегии
Кстати, стратегию можно искать блокчеком на каком-нибудь домене GGC, который не загружается через curl без обхода блокировок. При этом параллельно надо запустить winws --wf-tcp=443 --wsize 1500.
например такие домены
rr4---sn-n8v7znsk.googlevideo.com
rr2---sn-gvnuxaxjvh-o8ge.googlevideo.com
Понятно, спасибо за помощь. Буду пробовать.
С помощью блокчека я выявил вышеописанные «универсальные дурилки», которые пробивают большинство заблокированных сайтов моего провайдера. Но их все равно много — десятки вариаций. Как их дальше сократить до нескольких самых пробивных, самых быстрых и эффективных? Блокчек тут уже не помощник.
Если взять множество вариаций с TTL, то надо брать TTL максимальный из минимально рабочих.
К TTL добавить дополнительный ограничитель. Это можно быть любой из рабочих - datanoack, md5sig, badsum, badseq.
datanoack - вообще самая ультимативная штука, но не работает через домашний роутер. Работает только с него. Если работает, то никаких TTL и фулингов вообще не надо.
Следует избегать wssize, syndata, ipfrag,
Стараться уложиться в fake,split2,split.
disorder применять только, если не работают вариант split2 или split.
Обращать внимание на особенности стратегий с http и https. Например, на наших ТСПУ badseq часто вызывает зависание на http, но работает надежно на https.
При необходимости делить стратегии по ipv4/ipv6 http/https.
Если с TLS 1.2 все плохо, смириться с использованием лишь TLS 1.3 стратегий. Если нет критических девайсов типа телика, которые не умеют TLS 1.3
Для QUIC не использовать TTL с фейк.
Пробовать особенные пейлоады с фейк. Это прежде всего ClientHello с www.google.com для youtube доменов по TLS, quic initial с www.google.com с 2-кратным повторением - для QUIC.
И таких правил может быть много. В зависимости от множества факторов , провайдера и общей ситуации вокруг.
Ни автор, ни кто-либо еще не может дать готовый рецепт для любых случаев. Это все дышит, и везде ситуация может быть уникальна. А завтра - поменяться
Спасибо за обстоятельный ответ!
Ещё возникли вопросы.
Некоторые товарищи советуют забить болт на tcp 80 (http) и прописать только стратегии с портом 443 (https). Это хорошая идея или всё же стратегию и для 80 лучше прописывать?
Второй вопрос: у меня datanoack, md5sig, badsum, badseq — часто проходит с домашним роутером, если верить блокчеку. Например такой вариант: --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=fake --dpi-desync-fooling=datanoack
Получается, мне его можно использовать, несмотря на роутер? И всегда ли из четырех вариантов лучше выбирать datanoack?
В блокчеке есть такое предостережение: “ВНИМАНИЕ! Хотя одурачивание datanoack работало, оно может сломать NAT и работать только с внешними IP. Кроме того, для корректной работы может потребоваться nftables”.
Все. У меня голова уже крУгом. 
Я думал, что tls_clienthello_www_google_com.bin НУЖНО использовать для доступа КО ВСЕМ сайтам, если используется fake, а quic_initial_www_google_com.bin - только для Ютуба.
Как сделать двухкратное повторение для QUIC? Я только нашел опцию --dpi-desync-repeats=<N>. В ваших пресетах, кстати, значение =11. Где вообще используется QUIC? Разве не с Ютубом? и почему с ним нельзя использовать ttl? И куда лепить --qnum=200 при использвании мультистратегии?
Вот у меня:
nfqws --dpi-desync=fake,split2 --dpi-desync-ttl=3 для Рутрекера
и
nfqws --dpi-desync=split2 --dpi-desync-split-pos=1 для rr4---sn-n8v7znsk.googlevideo.com
Роутера нет. Есть командная строка в Linux и nftables. Как из всего этого слепить крокодила? 
Мои крокодилы просто ради шутки:
nfqws --qnum=200 --filter-tcp=443 --hostlist=/youtube.txt --dpi-desync=split2 --dpi-desync-split-pos=1 --dpi-desync-fake-tls=clienthello_www_google_com.bin --new --filter-udp=443 --hostlist=/youtube.txt --dpi-desync=split2 --dpi-desync-split-pos=1 --dpi-desync-fake-quic=initial_www_google_com.bin" --dpi-desync-repeats=2 --new --filter-tcp=443 --dpi-desync=fake --hostlist=/some_file.txt --dpi-desync-fooling=datanoack
2-й - все то же самое, но в конце вместо --dpi-desync-fooling=datanoack указать --dpi-desync-ttl=3
Дополнение.
Похоже не работают они. Крокодил не ловится, не растет кокос.
Есть вопрос по дополнительным правилам nftables для обхода блокировок WireGuard. У меня сейчас установлен nfqws через install_easy.sh на Debian (systemd). Так-то не проблема дописать правила на нужные порты UDP когда уже всё запущено (с направлением пакетов на очередь инстанса nfqws для QUIC), и это работает. Но как и куда эти правила лучше всего дописать, чтобы работало после ребута? Я так подозреваю, что в принципе можно дописать в /etc/nftables.conf. Или есть более элегантный способ?
UPD: заметил QUIC_PORTS в конфиге, в целом неплохой компромиссный вариант. @bolvan, а зачем для QUIC перехватываются пакеты с 1 по 6, там же по идее 1 достаточно? Или это необходимо для логики --hostlist-auto?
Также хотелось бы отдельно настроить --wssize для конкретного IP. Я так понимаю это надо будет поднимать ещё один инстанс nfqws для этого? Опять же вопрос как это лучше организовать в рамках уже установленного сервиса.
И ещё, в какой-то момент я буду переносить это на OpenWRT. Насколько сильно будет отличаться настройка вышеописанного для этой системы?
Вроде починил ютуб сайты этим методом тоже работают
–dpi-desync=fake,split2 --dpi-desync-split-seqovl=1 --dpi-desync-fake-tls=0x00000000 --dpi-desync-fooling=md5sig
Если сайт новый для броузера, он может залезть на оба варианта http и https одновременно.
Если не увидит STS хедеров, то может показать http версию. И там будет заглушка.
По возможности надо дурить. Но нерабочая стратегия хуже, чем ее полное отсутствие.
Если он работает, то это лучший вариант. Все остальное - выбросить.
верно. linux nat на домашних роутерах обычно не проходит.
может проходить, если на роутере включено аппаратное ускорение. на стоках это вероятный случай.
тогда пакеты данных идут мимо linux, а тупая логика свитча настолько тупа, что не проверяет этот неправильный случай.
но только для кабеля. для wifi может не работать. И тогда получается работает с кабеля, с wifi - нет.
conntrack такие пакеты всегда помечает INVALID и не делает NAT на них.
провайдерский NAT так же обычно пропускает, но может и не пропускать в каких-то случаях.
профиль 1 : ничего не нужно для split2 из написанных параметров. они игнорятся
профиль 2 : split2 для udp не работает. пустой профиль
профиль 3 : может сработать, но обычно к нему еще split2 нужен. datanoack требует проверки.
поиск рабочей стратегии ложится на юзера, автор ничего подсказать не может.
если совсем печально, см binaries/win64/zapret-winws/preset_russia.cmd. на авось
Да, именно для нее. Правда, она не всегда срабатывает на QUIC. Потому что некоторые библиотеки не повторяют CRYPTO, а шлют PING при отсутствии ответа.
Но как и куда эти правила лучше всего дописать, чтобы работало после ребута?
QUIC_PORTS можно использовать, хотя это и не лучшее решение.
если стратегии QUIC и WG отличаются, можно использовать профили с фильтром по --filter-udp. Только надо понимать, что скрипты zapret будут добавлять листы в конце строчки NFQWS_OPT_DESYNC_QUIC. Профили надо писать с учетом этого понимания. Есть еще SUFFIX. Он будет дописан после листов.
WG вообще никогда ни по каким листам не пройдет.
Плохая идея мешать QUIC в скриптах запрет и правила без скриптов запрет. Лучше тогда идти путем custom script в init.d/sysv/custom
Также хотелось бы отдельно настроить --wssize для конкретного IP. Я так понимаю это надо будет поднимать ещё один инстанс nfqws для этого? Опять же вопрос как это лучше организовать в рамках уже установленного сервиса.
Тут уже по любому светит custom script в рамках скриптов zapret, либо отсебятина отдельно.
Если это dest ip, проблем с фильтром нет.
Если source ip, то в postnat схеме прямая фильтрация невозможна. Надо маркировать битом на входе и фильтровать по этому биту на выходе.
И ещё, в какой-то момент я буду переносить это на OpenWRT. Насколько сильно будет отличаться настройка вышеописанного для этой системы?
Если остебятина - будет довольно сильно отличаться в плане правильной прикрутки к системе. Чтобы без конфликтов и гонок, а не тяп-ляп через rc.local.
Если custom script, то они немного отличаются в openwrt. По части запуска демонов. Правила FW можно копировать 1:1
tls - это tls, а quic - это quic
Зачем использовать пейлоад одного для другого ? Это очень разные протоколы. tls работает по tcp, quic - по udp.
Мой недавний тест на своем провайдере и чьи-то наблюдения отсюда говорят, что для googlevideo, а возможно и других youtube доменов, для tls надо использовать tls_client_www_google_com, для quic - quic_initial_www_google_com.
В остальных случаях оставить по умолчанию
вот такой у меня конфиг. Не таблетка, не панацея !
NFQWS_OPT_DESYNC="--hostlist=/opt/zapret_lists/list-youtube.txt --dpi-desync=split2 --new --dpi-desync=fake,split --dpi-desync-fooling=datanoack"
NFQWS_OPT_DESYNC_HTTP6="--hostlist=/opt/zapret_lists/list-youtube.txt --dpi-desync=fake,split2 --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-fooling=datanoack"
NFQWS_OPT_DESYNC_HTTPS6="--hostlist=/opt/zapret_lists/list-youtube.txt --dpi-desync=fake,split2 --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-fooling=datanoack"
NFQWS_OPT_DESYNC_QUIC="--hostlist=/opt/zapret_lists/list-youtube.txt --dpi-desync=fake --dpi-desync-repeats=2 --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_initial_www_google_com.bin --new --dpi-desync=fake --dpi-desync-repeats=2"
MODE_FILTER=autohostlist
cat /opt/zapret_lists/list-youtube.txt
googlevideo.com
youtubei.googleapis.com
i.ytimg.com