Исследуя блокировки на одном из провайдеров , я обнаружил интересную штуку.
Большинство блокировок обходится zapret-ом как обычно на других провайдерах.
Однако, на cloudflare применен какой-то более строгий алгоритм, который сечет попытки обхода, по крайней мере split запроса точно, и в этом случае вне зависимости от домена дает RST.

Вот так это выглядит :

Если zapret убрать, то фильтрация идет нормально.

$ sudo systemctl stop zapret
$ curl -4k --resolve bred.com:443:172.67.159.231 https://bred.com
curl: (35) OpenSSL/3.0.9: error:0A000410:SSL routines::sslv3 alert handshake failure
(ЭТО ОШИБКА СО СТОРОНЫ CLOUDFLARE, НЕ БЛОКИРАТОР)
$ curl -4k --resolve nhentai.net:443:172.67.159.231 https://nhentai.net
curl: (35) Recv failure: Connection reset by peer
$ curl -4k --resolve rutracker.org:443:172.67.159.231 https://rutracker.org
curl: (35) Recv failure: Connection reset by peer

Однако, при любой фрагментации запроса идет сброс вне зависимости от домена :

$ ps xau | grep nfqws
tpws       21245  0.0  0.0   3028  2080 ?        S    12:07   0:00 /opt/zapret/nfq/nfqws --user=tpws --dpi-desync-fwmark=0x40000000 --qnum=200 --dpi-desync=split2

$ curl -4k --resolve kremlin.ru:443:172.67.159.231 https://kremlin.ru
curl: (35) Recv failure: Connection reset by peer

$ curl -4k --resolve lenta.ru:443:172.67.159.231 https://lenta.ru
curl: (35) Recv failure: Connection reset by peer

Отсюда можно сделать какой вывод.
У них есть особый более строгий фильтр для CDN типа cloudflare, который zapret пробить не в состоянии. По той причине, что он сечет попытки обхода (например, через split запроса) и полностью блокирует IP в этом случае.

/etc/hosts
104.21.97.11 nhentai.net
104.21.97.11 rutracker.org

помогает с zapret-ом обойти блокировку

Как показывает опыт, не весь cloudflare так заблокирован. В нем есть ряд диапазонов, который заблокирован как описано выше, но если из него выехать, то там все стандартно

Не исключаю, что там осталась какая-то старая отсебятина от провайдеров. Там стоит минимум 2 DPI, который дают редирект по http на разные URL, но возможно еще какое-то старье

В спб на нескольких провайдерах ничего подобного (пока ?) нет.

PS. Обнаружилась дырка в “строгости”. Если резать по 1 байту --dpi-desync-split-pos=1, то это пробивает фильтр

У проводного мтс такая фигня уже давно. Уже года 3, если не больше. Тоже заметил, что там два dpi. Один поумнее, собирает сессию и ищет вначале tls запрос. Другой тупой и просто ищет tls запрос в каждом пакете без анализа сессий. И вот второй dpi находит начало tls запроса, но не находит sni, который переместился в следующий пакет. И срабатывает блокировка. Видимо так решили проблему encrypted sni.

del

Пробовал резать по 516:1 (всего 517). Та же история.
Причем, как уже написал, это работает только на части адресов cloudflare. Довольно большие дипазоны, типа x.x.0.0-x.x.96.255 , а с x.x.97.0 - норм
Это какое-то отдельное правило. Анализируя только 1-й пакет на 443 порту, допускать только TLS, проверяя при этом SNI. TLS считается как полная запись, кусок не считается. Иначе - RST

Обнаружил похожую блокировку с конца января:
1

$ ./ciadpi -m split -s 3 &

$ curl -I --resolve rutracker.org:443:172.67.182.196 https://rutracker.org -x socks5://localhost:1080
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to rutracker.org:443
(Блокировка)

$ curl -I --resolve rutracker.org:443:172.67.159.231 https://rutracker.org -x socks5://localhost:1080
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to rutracker.org:443
(Блокировка)

$ curl -I --resolve bred.ru:443:172.67.159.231 https://bred.ru -x socks5://localhost:1080
curl: (35) OpenSSL/3.0.9: error:0A000410:SSL routines::sslv3 alert handshake failure
(Ошибка Cloudflare)

2

$ ./ciadpi -m disorder -s 3 &

$ curl -I --resolve rutracker.org:443:172.67.182.196 https://rutracker.org -x socks5://localhost:1080
HTTP/2 301...

$ curl -I --resolve rutracker.org:443:172.67.159.231 https://rutracker.org -x socks5://localhost:1080
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to rutracker.org:443
(Блокировка)

$ curl -I --resolve bred.ru:443:172.67.159.231 https://bred.ru -x socks5://localhost:1080
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to bred.ru:443
(Блокировка)

Да, на некоторые адреса действует особая блокировка - если первый пакет не является TLS записью с SNI, то соединение блокируется, независимо от домена.
Обойти можно, отправив фейковый TLS пакет:

$ ./ciadpi -m fake -s 8 -H -t 7 &

$ curl -I --resolve rutracker.org:443:172.67.182.196 https://rutracker.org -x socks5://localhost:1080
HTTP/2 301...

$ curl -I --resolve rutracker.org:443:172.67.159.231 https://rutracker.org -x socks5://localhost:1080
HTTP/2 301...

$ curl -I --resolve bred.ru:443:172.67.159.231 https://bred.ru -x socks5://localhost:1080
curl: (35) OpenSSL/3.0.9: error:0A000410:SSL routines::sslv3 alert handshake failure
(Ошибка Cloudflare)

На том провайдере это не работало.
blockcheck от zapret не выдавал ни одной рабочей стратегии на https
и только разбиение на 1 байте дало результат.
Это должно быть или ошибка в знаках сравнения в алгоритме DPI, или реакция на первые 2 байта 16 03, точнее на их отсутствие в первом пакете
Но вопрос остается открытым с какой целью это было сделано, сделано ли это на ТСПУ, и если да, то почему не везде, почему только на cloudflare и только на части диапазонов.
Какие-то тестилки, которые забыли выключить, а правая рука забыла, что делала левая 2 года назад , так и потонув в бюрократическом омуте ?