split2 режет пакеты, но не отправляет фейки. split режет пакеты и отправляет фейки. но эти фейки - просто пустые пакеты. поэтому fake нужен для отправки конкретных фейков (можно указать пакет при помощи --dpi-desync-fake-tls), чтобы обойти проверку по sni в случае ютуба, например. так что эти режимы можно применять как вместе, так и отдельно - всё зависит от требуемой стратегии.
читаем про комбинирование, там указанj какой метод на какой позиции можно применять
я тоже не совсем понимаю зачем указывать нулевой ttl, ведь по умолчанию zapret не модифицирует ttl, по идее
но в целом, касательно опции --dpi-desync-ttl, она применяется для того, чтобы фейковые пакеты не ушли дальше dpi. её значение надо подбирать исходя из того как устроена маршрутизация у твоего конкретного провайдера. также эту опцию можно комбинировать с --dpi-desync-fooling. или наоборот, использовать fooling без ttl (как раз вариант с ttl=0).
для ipv6 опция, кстати, другая --dpi-desync-ttl6
Параметры манипуляции могут сочетаться в любых комбинациях.
Я под любыми комбинациями понимаю и любой порядок тоже. Про эти фазы не расписано что они из себя представляют. Поэтому непонятно если split2 разрезает пакет на части, но не отправляет фейки, а fake отправляет фейки, то почему fake + split2 не равно split, который и разрезает пакеты и отправляет фейки? Логика работы мне не ясна. Вот это я и имел в виду, когда говорил, что мануал написан путанно.
метод нулевой фазы - это то, что делается на этапе установления соединения, еще до запросов и известного hostname
метод первой фазы - это то, что делается до отправки значимой части запроса. такой, как tls clienthello или http request или wireguard handshake initiation и тд
метод второй фазы - это то, что делается непосредственно со значимой частью запроса. как издеваться над ней
fake : fake TLS, real TLS
fake, split2 : fake TLS, кусок 1 real TLS, кусок 2 real TLS
fake, split : fake TLS, нули в размере 1 куска real TLS, кусок 1 real TLS, нули в размере 2 куска real TLS, 2 кусок real TLS
split2 : кусок 1 real TLS, кусок 2 real TLS
split : нули в размере 1 куска real TLS, кусок 1 real TLS, нули в размере 2 куска real TLS, 2 кусок real TLS
сейчас бы я называл split = split4. но так исторически сложилось, а ломать уже настроенные конфиги не хочется
Итак, в продолжение вчерашней темы с zapret на роутере с OpenWRT ради Youtube:
–debug ничего не показал, ошибок в логе нет
проверки blockcheck выдают более-менее одинаковые результаты, всегда похожие на –dpi-desync=fake --dpi-desync-ttl=3 и –dpi-desync=split2 --dpi-desync-split-pos=5
при активном zapret с настройкой –dpi-desync=fake,split2 --dpi-desync-split-pos=2 --dpi-desync-ttl=3 проверка blockcheck всегда утверждает, что домены Ютуба доступны и не нуждаются в bypass
но Ютуб не работает (проверяю на компе и смартфоне)
при этом стандартный goodbyedpi.exe -9 --blacklist на компе и ByDPI на смартфоне с split 2 справляются легко
Компьютер и телефон подключены по WiFI к роутеру с zapret. Пробую вашу строку параметров.
На компе результат никакой (((
На смартфоне медленно открылась главная страница Ютуба (которая с поиском и без рекомендаций). Затем поиск даже выдал какие-то результаты, потом через время появились превью видео, но произвольно выбранное видео не открылось. Вернулся к результатам поиска, а вот обновить страничку уже не вышло - висит с серыми блоками вместо превью…(((
И всё это очень медленно…
Чего-то явно не хватает в параметрах, только вот чего?
и номер очереди должен быть 200, если не заданы уточняющие параметры для HTTP,HTTPS
если уж запускаете в консоли, то можно и без syslog. с syslog он ничего в консоль не выведет.
или в файл --debug=@/tmp/log.txt
выяснить точнее что запускается скриптами zapret можно через
/etc/init.d/zapret start_daemons
/etc/init.d/zapret stop_daemons
Мультипрофили - это вещь хорошая, я вот твою программку попробовала, скомпилировала с коммита 85de6f. За пару минут стратегии для одного провайдера настроила, трёхфазный nfqws как часики швейцарские заработал. И крёстный ход на Ютюбе посмотреть можно, и как молодёжь кувыркается - тоже.
Работает прямо из коробки, без всяких мудрёных шелл-скриптов, благо были запасные очереди с флагом bypass для, так сказать, горячей замены. Молодец!
Но всё же, очередь - она и в Африке очередь. Даже если многопоточно обрабатывать, вход и выход-то у неё последовательные. Значит, малейшая задержка может сразу на всё повлиять, особенно если настройки слишком мудрёные придётся применять. Один пользователь программку не нагрузит, а вот если это шлюз?
Поэтому лучше очереди делить - хотя бы по адресам распределять, или numgen приспособить. А в идеале по хостам, чтобы у каждого фильтра был свой pid. А там уж хоть nice им ставь, хоть через cgroups политики настраивай, чтобы лайвстримы в реальном времени без задержек шли, а форумы, как этот, уж как получится.
Это я к тому говорю, что на будущее стоит об этом подумать, особенно если стратегии сложнее станут. И для масштабирования, где возможность есть, и для алгоритмов, чтобы сеть не сломалась, когда одна TCP сессия по разным процессам разлетится.
Если в linux *tables настроены правильно с ограничителем по connbytes, то вряд ли оно сильно нагрузит. Оно будет обрабатывать по 10-20 пакетов на каждое соединение, что вообще ни о чем по нагрузке на CPU.
Но если у вас получится сделать так, чтобы на каждое tcp соединение (connmark) пакеты будут приходить одному инстансу nfqws, то это тоже вариант.
Можно не использовать хостлист фильтры, а только ipset.
Загонять в ipset целые ASки проблемных ресурсов с прыгающими IP.
ASN google, ASN meta corp и тд
Остальное загонять через ресолв листа.
Тогда nfqws вообще не будет трогать ничего остального, и оно не сможет сломаться.
и в теории это всё, что требуется, что обойти текущие блокировки (в смысле текущие проблемы с fake, т.к. как я понял в данный момент fake не работает только с GGC, остальные сайты с ним прекрасно открываются)
Ох, спасибо вам, уважаемые. И особенно респект автору за скрипт и техподдержку!
Номер очереди ставил и 200. Результат такой же. (увидел на гитхабе чьи-то дампы с –qnum=1 и –qnum=200 и делал как попугай
нет
Вот у меня тоже такие подозрения…
С --debug я не никогда не видел больше чем это после запуска/перезапуска, и при посещении сайтов там строки не добавляются:
initializing conntrack with timeouts tcp=60:300:60 udp=60
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 ‘200’
setting copy_packet mode
initializing raw sockets bind-fix4=0 bind-fix6=0
set_socket_buffers fd=5 rcvbuf=2048 sndbuf=32768
fd=5 SO_RCVBUF=4096
fd=5 SO_SNDBUF=65536
set_socket_buffers fd=6 rcvbuf=2048 sndbuf=32768
fd=6 SO_RCVBUF=4096
fd=6 SO_SNDBUF=65536
Running as UID=1 GID=1
set_socket_buffers fd=4 rcvbuf=65536 sndbuf=32768
fd=4 SO_RCVBUF=131072
fd=4 SO_SNDBUF=65536
