Zapret: what's new

Добавил в 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 - это точка отсечения, с которой больше не дурим.
Позиция относится к началу текущего принятого от клиента блока.