У меня есть несколько экспериментальных способов обхода блокировок на серверной стороне заблокированных сайтов, без необходимости каких-либо действий на стороне клиентов. Способы реализованы и протестированы, они показали свою эффективность при определенных условиях, но тестировались ограниченно и на малом количестве провайдеров.

Мне было бы интересно протестировать их на реальных заблокированных сайтах, с большим количеством посетителей из разных мест России. Если вы владелец заблокированного сайта и вам интересно поучаствовать в эксперименте — пишите на iam@valdikss.org.ru.

Также оказываю услуги по созданию тяжелоблокируемых распределенных сайтов и индивидуальных клиентских способов обхода блокировок: https://antizapret.prostovpn.org/services.html

У меня есть несколько экспериментальных способов обхода блокировок на серверной стороне заблокированных сайтов

Костыли с DNS Round Robin high availability и туннели клиентской части TCP сеанса на главный сервер с включённым net.ipv4.ip_nonlocal_bind?

Согласны ли вы, что DNS — самое слабое звено?

Хм, нет, мои способы так или иначе основаны на особенностях TCP-стека в системах DPI и клиентских ПК.
Некоторые провайдеры фильтруют любые IP-адреса и порты (так называемый «полный DPI»). Если ваш метод заключается в очень частой смене IP-адресов, чтобы они не успевали попадать в фильтр, то с «полным DPI» он не будет эффективен.

Так проблема же в том, что TCP-тюнинг на стороне сервера не может менять данные, отправленные клиентским приложением! Всё, что приходит на ум о TCP, это игра в кошки-мышки с DPI без пересборки потока, где сервер намеренно настаивает на заниженном окне. Интересно, есть ли способ это окно вернуть к исходным значениям, после TLS-рукопожатия (естественно, HTTP без TLS сразу отметается).

И есть ли в TCP магия Вуду против новых, современных DPI, которыe уже не надуешь фрагментированным рукопожатием?

Я использую различные трюки для десинхронизации TCP-соединения, чтобы DPI не мог отследить сессию.

АТАКА ДЕСИНХРОНИЗАЦИИ DPI
Суть ее в следующем. После выполнения tcp 3-way handshake идет первый пакет с данными от клиента. Там обычно “GET / …” или TLS ClientHello. Мы дропаем этот пакет, заменяя чем-то другим. Это может быть поддельная версия с безобидным, но валидным запросом http или https (вариант fake), пакет сброса соединения (варианты rst, rstack), разбитый на части оригинальный пакет с перепутанным порядком следования сегментов + обрамление первого сегмента фейками (disorder), то же самое без перепутывания порядка сегментов (split). В литературе такие атаки еще называют TCB desynchronization и TCB teardown.

Так какие из этих трюков может выполнить сервер? (навскидку, ни один)

Вообще, откуда пошёл термин десинхронизация, обычно так про часы говорят.

Реконструкция tcp стрима предполагает запись о внутреннем состоянии потока
На какой фазе установления или разрыва соединения мы находимся, sequence number с каждой стороны, буфер данных для реконструкции .
Десинхронизация направлена на достижение одного логического состояния между клиентом и сервером и другого между клиентом и DPI и сервером и DPI.
Чтобы клиент и сервер общались нормально, а у DPI рвало крышу. Чтобы реконструируя поток, он видел что угодно, кроме триггера, по которому он блокирует или разрывает поток