Какой метод обхода блокировок будет актуален в 2026 году?

Censorship circumvention methods & software Tunneling software
1

XRay, v2Ray, Reality, VLESS и т.д. голова идет кругом. Блокировки становятся все более изощренными. Многие техники и инструменты уже не работают. Вместо них появляются новые. Как во всем этом разобраться? Можете дать краткую справку какие методы будут актуальными и перспективными в 2026 году, а какие уже устарели и не стоят внимания? И желательно какие-то ссылки на проекты или статьи.

Я имею в виду технологии туннелирования - ТОР-ы, Запреты и т.д. оставим за скобками. Ну и те из них, которые позволяют нормально пользоваться современным Интернетом, то есть с хорошей пропускной способностью. Техники которые позволяют передавать туда-сюда всего лишь килобайты тоже пока оставим.

3

Вопрос дублирует тему.

https://ntc.party/t/как-это-работает-книги-и-статьи-how-does-it-work-books-and-articles/8235

Современный интернет — национальные интранеты.

4

Действительно частично дублирует. Я не нашел ее раньше. Я сам могу удалить тему или модераторы сами разберутся?

5

Я не верю в “белые списки” в ближайшие годы. Если только не случится чего-то экстраординарного. Я много всяких блокировок угадал и предсказал заранее, но в это не верю. “Белые списки” означают стать в один ряд с Сев.Кореей, Туркменистаном и Эритреей.

7

Старлинки, иностранные сим карты. Ловить интернет из-за границы, и уже внутри страны раздавать через VPN. Уже слышал, что подобным образом ловили и перераздавали интернет из Эстонии. Ну и в Северную Корею так же завозят китайские смартфоны, и находясь на границе можно попасть в китайский интернет (Это уже лучше, чем ничего).

8

Тема была заявлена как “актуальные и перспективные технологии туннелирования в 26-м году”. Не в 36-м и не в 37-м. Подождите. Не все так плохо. Белые списки не введены повсеместно навсегда и не будут в ближайшее время. О старлинках думать еще рано.

Я предлагаю вернуться к обсуждению технологий XRay, Reality и т.д. Что именно работает, а что РКН уже научился выявлять и блокировать.

9

зачем тогда вообще такую тему создавать, если вы итак все отлично угадываете и предсказываете?

Как раз нет, наоборот, они именно что будут введены. Просто не так, как вы себе представляете. Достаточно посмотреть на тренд последнего года. А именно: РКН вообще целиком и полностью перестал считаться с collateral damage. Уже повсеместно и массово идут либо полные, либо “сибирские”, либо 16кб блокировки CDN, облачных провайдеров и сколь-менее популярных хостеров. И наиболее вероятно что это будет продолжаться и усиливаться - сначала замедляют/блокируют тяжеловесов типа Cloudflare/AWS и Hetzner/OVH, в итоге все медленно но верно дойдет до блокировки вообще любых иностранных CDN и любых хостеров чуть больше чем уровень поделок любителей. Ну и само собой поверх этого отдельные белые списки, как уже есть белые списки для ресурсов на том же Cloudflare.

А когда все массово начнут использовать промежуточные узлы внутри страны - будут закручивать то же самое на транграничных и датацентровых ТСПУ, или даже нарастят мощности фильтрации чтобы фильтровать и трафик от абоненто который идет внутри страны

10

так достаточно этот форум почитать. РКН действует по двум фронтам:

  1. массовые блокировки целыми подсетями CDN и хостеров
  2. блокировки по косвенным признакам (типа “сибирской блокировки”).

по первому см. выше, по второму - там все настолько хаотично, что предсказать, с каким напором и с какой стороны им моча в голову ударит, просто невозможно. В каких-то случаях блокировку триггерит большое количество параллельных подключений к одному адресу, в каких-то случаях наоборот большой трафик под одному подключению. В каких-то случаях режут неопознанные протоколы, в каких-то случаях сильнее всего фильтруют обычный TLS, а рядом свободно бегает древний Shadowsocks.

В целом, если кинуть кубик, на ближайшие полгода я бы смотрел примерно так:

  1. проксирование через промежуточный узел внутри страны, желательно reverse

  2. для проксирования между промежуточным узлом внутри страны и снаружи использовать всякие вообще стандартные туннельные протоколы, которые существуют очень давно и реализованы в популярных серверных ОС, но обычно применяются именно между серверами, а не для обычных прокси/VPN (вплоть до того что это может быть вообще не TCP и не UDP)

  3. XHTTP с разными конфигурациями (мультиплекс, разделение потоков на разные сервера, и т.д.) для разных случаев про запас

  4. нешифрованный HTTP в качестве внешнего слоя (но это по принципу Неуловимого Джо).

Ну и самый надежный вариант - международный аэропорт Шереметьево.

11

В таком случае, белые списки надо пробивать фейком разрешенного сайта. На хостере поднимать VPN, чтобы SNI/IP примерно совпадали.

Если совсем до мелкоты не дойдёт (резидентских адресов, совсем мелких хостеров), т.е. белый список не будет глобальным (а он даже в ТМ не глобальный), то я бы посмотрел в сторону распределённых решений: i2p, tuntox. Но тут уже не до скорости.

Самым надёжным методом будет непопулярный, не массовый.
Вопрос лучше задать не “будут ли белые списки”, а будут ли они обходиться.

12

да были уже маппинги ip → sni, просто допиливают или удавку затягивает помаленьку. Это вообще примитивный анализ, с чего бы его не сделать если уже есть фильтрация по сигнатурам у реверса

13

на Net4People, например, еще давно обсуждалась более интересная схема из Ирана: доступ по HTTPS блокировался, если перед этим не было отправлено DNS-запроса доменом из SNI, и если последующее подключение с этим SNI шло не по адресу из DNS-ответа. получается очень эффективное средство для борьбы с Reality и подобными.

Понятное дело, что оно сломает доступ тем кто пользуется DoH/DoT, но РКН это наверняка мало волнует.

“Пробивание фейком” в стиле zapret и подобных тоже имеет границы применимости - более чем уверен что поставщики ТСПУ будут работать в эту сторону (более сложные эвристики направленные конкретно на эти обманки, увеличение окна стейта для анализа не только самых первых пакетов, и т.д.).

У них у всех есть очень больное слабое место, так же как и Tor’а: они сами по себе распределенные, но им надо как-то бутстрапиться. А адреса нод для бутстрапинга точно так же можно заблокировать. Tor эту проблему кое-как решает с помощь бриджей, а вот I2P изначально не ставит целью борьбу с блокировками, и таким заниматься не будут.

14

Это касалось только https трафика? Если да то можно легко обойти

Самое слабое место у них то что известен список всех узлов. Достаточно его заблочить и сеть перестанет работать. У Tor это список публичен, у i2p нужно собирать вручную

15

Всем привет!Хотел написать отдельной темой,смотрю вопрос прям который у меня вертиться на языке…. :waving_hand: Сразу скажу: я по профессии столяр-плотник. Мои руки привыкли к дереву, но жизнь заставила разобраться в сетях и линуксе,сильно не пинайте ,занимался ремонтом электроники отсюда и небольшие познания…! Собрал себе инструменты для обхода блокировок, сейчас всё летает, но хочется сделать “на века”, как хорошую мебель.

Понимаю, что мои текущие схемы держатся на том, что IP хостинга в РФ пока доступен. Но я реалист и понимаю: если (или когда) врубят жесткие “Белые списки” (доступ только к госуслугам…итд итп), мой VPS в RU превратится в тыкву, так как он не в реестре разрешенных,на нём крутиться xrey.А вот почитав два дня форум самописный запустил на vk cloud.

:hammer_and_wrench: Что имею сейчас: Две рабочие конфигурации, построенные по принципу “Моста”:

  1. PC: Xray Client → [VPS RU Reverse Proxy] →⭠revers- [VPS EU] → Internet.

  2. Android: Самописный скрипт на Python (эмуляция WebSocket + поведение) → [Vk cloud + Nginx + White Site] → ⭠revers-[VPS EU].

    • Фишка: Nginx на входе делит трафик: обычных юзеров пускает на сайт, мой трафик (по паролю) заворачивает в туннель до EU.EU весит на входящем порту VK в тунеле.

:red_question_mark: Вопрос к знатокам: Какие модули или костыли можно “прикрутить” к этой архитектуре СЕЙЧАС, чтобы иметь шанс пробиться через WhiteList в будущем?

Меня интересует именно вектор развития:что можно улучшить в текущих конфигурациях для устойчивости…)

Буду благодарен за любой совет, куда копать столяру, чтобы интернет в мастерской не кончился. :tractor:

16

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

17

Белый список на то и белый список, что он автоматом отсекает любые методы обхода, т.к. там по умолчанию отбрасываются любые сетевые пакеты кроме тех, которые РКН разрешил в ручном режиме. Т.е. если хотите иметь канал обхода, то должно быть именно так, как я написал выше - необходимо иметь заграничную точку, подключение к которой считается легальным и трафик к ней не будет резаться. Я, собственно, выше именно это и писал, только мои посты снесли почему-то. Хотя ниже народ ровно то же самое пишет по сути про белые списки и т.д.

Т.е. борьба с белыми списками - это не изучение технологий (заведомо проигрышная стратегия, ибо бан по IP вы ничем не обойдете), а вкладывание денег и сил в обустройство легальной заграничной точки подключения.

18

При белых списках, может быть бан и не по IP. Например, сейчас на хостингах белые списки с баном по SNI.
Современные сайты очень сложные. Сейчас не просто домен = 1 IP. Это осталось в прошлом. Сейчас cdn-ы, внутри сайтов тоже куча ресурсов, которые используют cdn-ы. И как их обелить условному ркну? Вот, SNI проверяют. Поэтому куча дыр.
Ведь IP у сайта динамические. Сегодня такие, завтра другие (замучаешься отслеживать). Одни резолверы выдают одни, другие выдают другие. Т.е. если заблочить все IP на хостинге, кроме некоторых, надо ещё держать под контролем резолверы, чтобы они не выдавали заблокированные IP.
И всё бы ничего, но большинство пользуется смартфонами, планшетами, с ограниченной конфигурацией, у браузеров могут быть свои doh-и.
Но в общем, чтобы блочить по IP, нужно чтобы все девайсы использовали провайдеровские днсы и днсы должны быть синхронизированы, т.е. не выдавали заблокированные IP. Будут ли они так заморачиваться? Не знаю.
И даже в этом случае могут пролезть фронтинги разные, хотя их и осталось мало. Например, в ТМ до сих пор используют фронтинг гугла.

Белые списки на мобильном интернете сейчас вообще обходят пролезая через webrtc звонки в максе.

19

Белый список по IP может быть сопровождён и с другими проверками, например на мобильном МегаФоне при включённых БС на некоторых диапазонах выполняется проверка SNI+IP, а не только IP. Так что вкладывание ресурсов в обустройство легальных точек подключения должно быть сопровождено в том числе и с изучением технологий обхода.

20

как минимум начать с простой проверки по паре ASN+SNI, а не просто SNI.

нужно чтобы все девайсы использовали провайдеровские днсы

это их вообще не волнует, они блокировкой DoH развлекались еще много лет назад (Роскомнадзор отрезает сервисам возможности обхода блокировок | Кабельщик)

это ненадолго, пока Яша и ВК на своих TURN-серверах не врубят рейтлимит или контроль объемов трафика в разные стороны.

21

Ваши рассуждения были бы верны в парадигме “РКН заботится о безопасности россиян”. Но на деле мы видим ковровые бомбардировки рунета. Телеграм тому хороший пример: если уж блокировка средства связи, которое активно используется и на фронте, и в бизнесе не остановила РКН, то почему вы думаете, что РКН остановится перед сопутствующим ущербом, когда из-за веерных блокировок вы не сможете получить доступ к легитимным сайтам? Еще раз, черным по белому: деятельность РКН приводит к смертям. В прямом смысле этого слова. На фронте сломана связь. В тылу предупреждения о ракетных и дроновых атаках, которые раньше приходили через Телеграм, теперь не работают.

Поэтому можете даже не сомневаться, что если ради блокировки 1 сайта придется положить доступ к 1000 легитимных ресурсов, то РКН сделает это без колебаний. Вернее, те, кто стоит над РКН.

Теперь что касается легальных соединений. Я тоже не думаю, что блок будет прям тотальный, но контроль будет усиливаться, т.е. в будущем наверняка придется лично топать ножками в РКН или еще куда-то, там писать зачем вам нужен VPN и для каких целей. В конце концов, в сырьевой перепродажной экономике попросту нет возможности работать в полном отрыве от западного мира, нужны какие-то каналы связи, особенно в промышленности, где какой-нибудь станок может вообще тупо встать, если его лишить связи с сервером вендора. Поэтому задача заключается в том, чтобы создать видимость необходимости подключения куда-то за бугор. Всяким программистам-айтишникам это проще всего будет сделать, они реально могут работать удаленно, а подключение к внутренним корпоративным сетям там нормой является. Ну а то, что точка выхода VPN-тоннеля может не оканчиваться корпоративной сетью, а продолжаться дальше в интернет - это уже отследить невозможно будет по понятным причинам.

Так что как-то так. Обходить же белые списки, выискивая какие-то прорехи в них… Ну наверное можно, но это заведомо тупиковая затея, поскольку уже сейчас ситуация постепенно становится такой, что ты на поиск обходов тратишь времени больше, чем на пользование самими целевыми ресурсами куда тебе был нужен доступ.