Фикс обнаружения и блокировки туннелей | sing-box маршрутизация

Manuals and How-Tos
111

То что это проблема – пока вообще ничем не обоснованно, кроме “ну.. они будут объем трафика сортировать…”, как минимум потому что не с чем сравнивать. У вас нет логов, каких-то графиков того, что трафик конкретно этой схемы чем-то выделяется на фоне всего остального, и разумеется, ни что больше на похожую энтропию трафика не похоже.

Никто пока не говорит, что отлетал сервер. Просто предположения о “палевности”. У меня вот всё стабильно работает. РКН пока ничего не анализирует по логам и объемам трафика на ISP. А шпионы? Шпионы уже реальны, мы хотя бы его физически обнаружили в MAX, и новости поступают.

То есть ставка на то, что анализ будет производиться именно с сервисов, а не ТСПУ / ISP. Надежно только с ISP отличить – видимо сложнее, чем принудить абсолютно все аккредитованные в IT сервисы.

То всё маршрутизируется прозрачно на удаленный шлюз – это побочный эффект, компромисс, trade-off, а не задумка. Задумка – прозрачное для любых клиентов управление их маршрутизацией. Чтобы на условном iOS включил VPN – 24/7 любые сервисы работают.

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

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

Здесь схема – подходит для любых клиентов. Ничего на клиентах настраивать не нужно. Спокойная прозрачная маршрутизация, будто блокировок и не было, о них клиенты знать не должны. Клиенты / устройства не спроектированы на рассчёт о цензуре. Цензурой занимается ШЛЮЗ, по определению, предоставляет транспортный слой, который справляется с теми или иными условиями сети. Как-будто Анти-ТСПУ коробка.

Почему бы не туннелировать весь трафик хотя бы с ПК? Чтобы минимизировать объем трафика.

Чем больше вы открываете наружу доступ – тем больше уязвимостей для эксплуатации, тем больше надо прокладки в виде Zapret делать, открывая порты и т.д. А на ноутбуках, таких как MacBook, доступа к ядру вообще нет, знаете почему? Потому что конечные устройства не рассчитаны на костыли в сети для самих себя.

И как минимум эти комбайны из кучи костылей вообще не портируемая схема, слишком много слоев, которые нужно контролировать, которые могут сломаться, в которых средний человек не разбирается и точно допустит кучу ошибок, утечек, и уязвимостей.

Все костыли – на сервере. Клиенты (устройства) – счастливые.

Если так уж спать не дает объем трафика к одному IP – создайте прослойку в виде мобильного OpenWRT роутера, таскать с собой везде. Теперь ваш мозг маршрутизации будет там, а не на сервере по SSH. Будете с собой таскать, “ну теперь уж точно не палево!”. Появится завтра новость или хотя бы прецеденты на то, что начали по объему трафика в одной точке наблюдения душить – одним из первым побегу собирать такой роутер, а пока достаточно хорошая и удобная для среднего человека схема, которая оптимизирует реальные проблемы (шпионы на сервисах – уже проверенный факт), а не чисто гипотетические.

112

хоспади.. шпионы существовали и 20 лет назад когда еще сталлман про них писал в далеких 2000х. весь этот тред и оп просто пытаются переизобрести колесо тора со схемой мультихопов и глобальных adversary

вы пытаетесь спасать утопающих строя эти server-side схемы, когда нужно менять смотрящего. сам менталитет у людей, не знаю учить? переучивать? правильные люди которым важна приватность давно выбросили смартфоны и перешли на кнопочные телефоны, снесли виндоусы и поставили линуксы. используют виртуальные машины для рунета в конец… а вы хотите ведрами воду черпать из тонущего титаника? зачем?

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

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

запретят гугл и их смартфоны завтра, что тогда? заставят поставить red star os или скрепный baikal как западный tpm со своим модулем который тоже будет шпионить, что тогда? бутлодер залочат как на телефоне как сейчас это хотят сделать на западе с их age verification, что тогда? до вашей схемы никому не будет дела, про нее уже писали не то что 20, в все 30 лет назад, а вы с пеной у рта думаете что такие КрЯкнУлИ кОд чТо тЕРь СоСнИТе всЕ вАщЕ я ВсЕ зНаЮ!11!!

Summary

у вас класический dunning-kruger после прочтения одного дока =)

113

Если клиент вашей архитектуры не пользуется Bittorrent, который вы как единственный предлагаете директить на клиенте - весь трафик, абсолютно весь трафик этого клиента будет идти на один адрес VPS.

ИМХО, клиенты должны быть умными, и VPS должны быть умными, все должны быть умными и желательно разнообразно умными, чтобы паттерн был не один, а много.

114

Спасибо за разбор, схема с разделением IP и WARP на выходе логичная и вполне резонная.

Но вопрос по входному IP.
Вы описываете сценарий:
шпионское приложение сливает exit IP → РКН проверяет → находит прокси. Разделение IP это
закрывает — exit IP не ведёт к inbound.

Но зачем РКН эта цепочка через exit IP, если ТСПУ и так видит клиент → X.X.X.X:443 напрямую?

Им не нужно искать прокси через логи сайтов — подключение видно на уровне провайдера без всякой корреляции. Ведь шпионский модуль проверяет доступность запрещённых ресурсов с клиента — а
значит можно отследить полный маршрут: клиент обратился к заблокированному сайту и получил нормальный ответ, ТСПУ видит что в этот момент трафик идёт на X.X.X.X, и вполне может сравнить логи со сливами маха, сопоставить 2 + 2, или забить даже на это.
Подскажите пожалуйста. Или же я что-то упускаю? Может как-то невнимательно прочитал..

115

Это не оверлей сеть, а трёхэтажная схема маршрутизации для:

  • Удовлетворения РФ сервисов
  • Западных (с геоблоком)
  • Обычный доступ

Сеть – это граф узлов. Я выбрал идеальный узел, который оптимизирует расстояние до всех остальных. Некий центроид.

Перенести управление на один умный узел вместо десятков тупых. Оптимизация.

Приватность важна до первого хопа. То есть проскочить через массовый сборщик логов. Поэтому утечки недопустимы. VLESS обеспечивает скрытность в толпе (по протоколу) и пофиг какой там объем трафика.

Об изоляции (оффтоп)

Это второй слой изоляции, userspace sandbox. Вы делаете из Android сборщик телеметрии и костылей. В том же плане iOS больше на кнопочный телефон по приватности – “Делай хорошо одно, а не всё”. Сеть – ниже.

“Рунетом” с идентичностью пользоваться с изоляцией fingerprinting и ущерба смысла нет. А без неё – тем более. Рунет заведомо про идентичность. Я не люблю слишком широкие правила “чёрное” и “белое”, потому что это ненадожно, создает уязвимости. Лучше делить сервисы на классы.

Здесь топик про огранизацию транспортного уровня, а не об OPSEC. Тем не менее схема любые оверлей сети очень даже позволяет. Причем прозрачно. Установите условный TailsOS, должен запуститься сразу же из коробки (при условии наличия sing-box)

Да, однокнопочные – “Сделать всё заебись”. Любые айфоны / тостеры – прозрачный свободный, приватный доступ к сети. Потом можно sing-box на OpenWRT роутер общий поставить, так вообще сказка, как будто и нет никаких РКН / санкций (в плане свободы доступа к ресурсам).
Но не для куриц, чтобы клевать в “Включить” / “Выключить”. А вы всё выключить для части трафика наровитесь.

Предложите свою, что-ли. Только не пишите “палево!!! гигабайты к одному IP!” и не предлагайте костыли на Android. Терпеть не могу когда задачу пытаются решить в лоб, а не поменять мышление – на самом деле мы не обходим “блокировки”, а организовывем себе трёхэтажную сетевую инфраструктуру для гибкого управления. А то что “блокировки” обходятся – это побочный эффект, заслуга архитектуры.

Бэкграунд (оффтоп)

Серьёзно? Я месяцами к этой схеме шел, и падал. Я уже и не помню когда это началось, но вот серьёзно я усираться стал над этим как минимум с ноября 2025. Вы думаете что я один раз документацию прочитал, всё понял (причем сразу, с учетом всех нюансов всех протоколов, прикладном развертывании служб), и родил себе эту схему?

Я верю в схему и считаю её лучшей, пока не будет доказано обратное. Как минимум ничего лишнего в DIRECT с ПК я пускать не намерен, на зло всем ISP всё зашифровано будет!

Последним пазлом стало разделение входного / выходного IP с апстримом в WARP через WG endpoint. Тут он и сошелся.

Да. Знаете почему? На то удаленный шлюз и нужен, чтобы в ОДНОМ месте управлять всей маршрутизацией, а не в нескольких, создавая кучу ошибок и путаниц.

Много трафика к одному IP – плохо!

Нет, я не верю в эту байку. Неужели РКН за десять лет не додумались так туннели обнаруживать ещё? Тратят миллиарды денег на ТСПУ, позорятся перед сервисами заставляя их доносить на пользователей. Это во-первых.

Во-вторых вообще не факт, может не так страшен чёрт как его малюют? Может не так уж палевно или сложно это обнаруживать? У нас нет данных логов ISP и графиков.

Пусть ПК хотя бы минимально умным будет, но с тем же фундаментом. Ноутбуки / смартфоны / прочие гаджеты – тупыми, знаете почему? Потому что они не предназначены умничать с сетью. Они предназначены на userspace sandbox, а не kernel network hacking. Занимаясь хакингом или вообще какой-то маршрутизацией КРОМЕ прикладных каналов – вы проливаете знание о том какая сеть в сами устройства, нарушается базовый принцип энкапсуляции знаний. Это приводит к уязвимостям и усложняет схему.

Например вы можете поднять какой-то прокси для X приложения, а роутер – да хоть на голубинной почте но должен будет доставить пакеты – справляясь с помехами на сети, в зависимости от протокола.

То есть да, клиенты должны быть умными, но не с сетью.

Сетью может быть хоть голубинная / ослиная почта, хоть на магии, клиенты знать о том какая она – не должны. ШЛЮЗ (со знанием сети, для которой является входом в транспорт) в сети просто обязан будет доставить любые их прихоти от А до Б.

Вы абсолютно правы! Знаете, моя схема как раз это и чинит.

Как, но ведь шпион знает куда я подключаюсь?

А вот теперь попробуйте угадать где расположен мой ТСПУ в моей схеме.

У меня же часть трафика идет в DIRECT и в логах сервиса со шпионским модулем это видно

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

То есть это намного важнее, чем байки про объем трафика.

116

сделаю немного больно
Но кому принадлежат этот входной и выходной IP так и не рассмотрено

117

Вам принадлежит, в вашем же хостинге. Два белых IPv4 в интерфейсе сети (ip a)

118

Узкое место найдено.

119

Оно не одно.

Как нет? Хостер же видит…

Что видит? Входящие зашифрованные, исходящие зашифрованные запросы в апстрим (к недоверенным сервисам) – то есть в WARP?

Для обнаружения туннеля нужно как минимум два наблюдателя, а не один. Раз первый хостер, значит второй – должен быть сервис или Cloudflare. Если сервис – это ухудшит корреляцию, из-за хопа через CF. Если Cloudflare – то да, но это уже второй наблюдатель.

А как тогда это будет считаться узким местом?

Если сервис, куда запросы идут в DIRECT с VPS – скомпромитирован. Например если YouTube сливает. Но он считается доверенным.

120

ТСПУ и так знает ваш домашний ip адрес. Ему вовсе не нужны никакие шпионы в МАХе и или госуслугах, чтоб идентифицировать, что пользователь с внутренним nat ip x.x.x.x это конкретно Вася Пупкин из квартиры №10. О какой вообще приватности от ТСПУ может идти речь, если этот самый ТСПУ стоит прямо внутри провайдерской сети и мониторит вообще весь трафик, проходящий там.
Если так хотите обезопасить себя от деанонимизации системой ТСПУ, то покупайте Starlink и гоните весь трафик через спутники, в обход всяких ТСПУ и российских ОПСОСов

По факту, ТСПУ даже не нужно знать кто именно скрывается за каким ip. Ему достаточно увидеть, что какой-то пользователь с ip x.x.x.x устанавливает очень странные и подозрительные подключения на один конкретный vps. Всё, этого достаточно чтобы просто сбросить подключение этому пользователю, и пофиг кто именно скрывается там за этим ip x.x.x.x, хоть Вася Пупкин, хоть баба Зина.

121

То есть я правильно понимаю, что мы снова пришли к этим байкам про эвристики ТСПУ? В те самые моменты когда до сих пор работают Zapret, и ничего что 80% трафика идет к SNI 4pda.to и остальные 20% - к google.com?

Они не странные, vless + gRPC – обычный веб-сёрфинг / API сервис.

В общем нет смысла обсуждать эвристики ТСПУ здесь, т.к мы не эксперты в этом, статья не об этом.

122

Можете, пожалуйста, уточнить момент про

сейчас у всех схема запроса выглядит примерно так, если добавить разделение ip:
клиент → (ТСПУ провайдера) → (X.X.X.X:443 (vps - входной IP) Y.Y.Y.Y (vps - выходной IP)) → ютубчик
как вы минуете анализ трафика ТСПУ:

входной ip же всё равно сливается

я не понимаю как происходит его защита

123

Здесь защита не от ТСПУ, а от шпионов. Это разные точки наблюдения. От ТСПУ невозможно скрыть IP, это неизбежно. Но можно пройти как легитимный трафик, на то и используется легитимный протокол (TLS) с характером gRPC (для имитации интенсивной работы API).

124

Пара вопросов:

  1. Что планируешь делать со своей схемой, когда рос сервисы закроют доступ к себе с адресов WARP? Я думаю, это произойдет в ближайшее время в рамках нынешней инициативы.
  2. Тебя не беспокоит вероятность попасть в условные “списки неблагонадежных граждан” просто за сам факт захода с адресов WARP? Рос сервисы по своей природе не анонимны и привязаны к номеру телефона / паспортным данным.
125
  1. Бойкот – перестать пользоваться на постоянке.
  2. Вопрос – универсальный, не обязательно ахилесова пята конкретно этой статьи. Большинство из вас бы просто в direct начало пускать трафик к шпионам (они этого только и хотят) с той же сети из которого идут запросы в туннель.

Умнее будет – слать запросы с другой сети, мобильной, со своего небольшого “ботнет” подключенных к шлюзу устройств.

Как? В смысле?

Reverse tunnel к условному смартфону, подключенному в туннель.

Схема для sing-box:

В inbounds.inbound.bind_interface выбрать интерфейс сотовой сети и принимать подключения на нем.

На сервере настроить балансировщик, выбирать конкретное устройство в зависимости от его доступности (если отвечает с сотовой сети):

{
  "type": "urltest",
  "tag": "auto",

  "outbounds": [
    "proxy-a",
    "proxy-b",
    "proxy-c"
  ],
  "url": "",
  "interval": "",
  "tolerance": 0,
  "idle_timeout": "",
  "interrupt_exist_connections": false
}

Получаем тем самым список резидентских прокси (со своих же устройств), которые будут отвечать с сотовой сети (через reverse tunnel), чтобы проксировать запросы через них.

Так в DIRECT же что-то идет!

На другой ТСПУ, это другая точка наблюдения, не связанная с основным маршрутом к основному туннелю.

То есть я даже и не изобретаю ничего, использую тот же sing-box. Делаю то же самое, что большинство из вас сделало бы, но безопасно (маршрут к шпионам по другой сети). А шпионы наверняка даже в БС будут доступны.

126

Тем не менее, разделение адресов помогает. У меня вот недавно начались отвалы доступа к VPS. Сначала пару раз в день, потом все чаще и чаще. В итоге пришлось продираться к панели 3xui в редкие минуты доступа и судорожно настраивать там второй IP под руководством DeepSeek, делая выход всех коннектов с VPS на другой IP, который пришлось срочно покупать у хостера. После этого ситуация нормализовалась и все работает штатно, но только если не пытаться подключаться с телефона к тому же VPS через домашний Wi-Fi - после этого снова доступ на пару минут пропадает. При этом лично у меня MAX не стоит, но есть другое отечественное ПО (Сбер, Т-Банк, Озон, Яндекс.Почта, Яндекс.Go), которое либо я сам запускаю, либо оно само в фоне стартует (считаю что это вот уже косяк самой Андроид-системы, что она позволяет подобную самодеятельность приложениям, но без рута такое не заблочить, как я понимаю). Видимо, что-то из этого софта дополнительно сливает инфу ТСПУ, раз возникает блок.

Т.е. нельзя утверждать что разделение адресов помогает прям вот на 100%, но то, что это решает 90% проблем - это факт. Кроме того, наверняка я где-то с настройкой напортачил, т.к. не шарю в теме от слова “совсем”, наверняка если бы сделал все грамотно, то ТСПУ окончательно отвязался бы от моего домашнего интернета, но мне пока и так нормально.

127

Так не должно быть, походу шпионы в смартфоне каким-то образом триггерят блок. Проверьте, отключите Wi-Fi, переключившись на сотовую связь, доступ к VPS появляется?

  • Если да, то active probing по связке SRC → DST продолжается.
  • Если нет, то на ПК тоже пропадает?

Надо было наоборот :slight_smile:
Выход с заблокированного (тот IP что уже “грязный”), а вход – с нового, ещё неизвестного шпионам IP.

У вас не прекратится active probing из-за этого, новый IP теперь возможно тоже стал грязным, если вы сливаете сервисам-шпионам его как exit узел.

Я на 99% уверен, что шпион просто запомнил связку приложение (с аккаунтом) → грязный IP и блокирует подключения с смартфона к грязному IP. Провал в том, что нужно было грязный IP оставить на выходе, а на вход сделать новый, а не наоборот новый на выход.

Если схема кривая и есть утечки – да, но моя схема чинит “кривизну тостера” архитектурно на уровне сети, делая любые “слития доп инфы” невозможными. Разумеется, если проливать трафик мимо туннеля в direct с того же устройства – это всё поможет шпионам.

То есть железное требование у тостера одно – не сливать в direct трафик от шпионов. Гарантировать TUN интерфейс с пылесосом всех запросов в системе.

При неполной маршрутизации – согласен, но важно учитывать, что новый IP нельзя палить шпионам, он должен стать входным, а грязный – выходным. И шпионский трафик в direct не слать, это очень помогает шпионам.

Зерно статьи – разделение. Её полная задумка – это полная схема маршрутизации трафика.
Первое – чинит простой слив IP логам шпиона. Второе – устраняет дополнительные утечки, которые шпион использует для проверки на наличие туннеля.

Что за утечки? Например, те что обсуждали здесь, этот шпион экспуатирует уязвимость split маршрутизации:

Его цель даже не IP узнать, а просто подтвердить наличие туннеля, это уже достаточно для инициализации дальнейших расследований со стороны шпиона.

128

Так насколько я понял, от Убогих как раз поступила инициатива, что бы все скрепные сервисы блокировали подключения к ним с подозрительных IP - тогда получается стратегия с полным туннелированием не прокатит - где взять легитимны outbound ip? Тогда всё загнивающее будет работать а посконное нет?

129

Это не закроет уязвимость в подтверждении наличия туннеля вообще. В том числе и per-app маршрутизацию можно обойти (снова мусолить эту тему здесь не буду).

До первого хопа – туннелируйте. Потом – в зависимости от политики сервисов. Часть сервисов с геоблоком, часть – РФ, остальное – тоже в апстрим.

Моя задумка – удаленная маршрутизация как средство переноса точки наблюдения до первого хопа.
Второй хоп – преодоление политик сервисов.

Трёхэтажная схема на то и трёхэтажная, что разные этажи – разные уровни угроз.
Первый этаж – средство противодействия шпионам + контроль.
Второй этаж – средство связности в зависимости от политик сервисов.

Это уже универсальный вопрос, а не ахиллесова пята данной статьи. Моё предложение – обратный туннель к смартфону и выход в БС с сотки – и только для единичных сервисов, а не дефолт рунета. Но это на втором этаже, а не на первом.

131

С пятницы тоже периодически по вечерам не могу зайти по SSH на забугорный ВПС (сам IPшник ВПСки пингуется). До этого всё работало, как часы, что на стационаре, что на смартфоне. Пока решил не усложнять и сделать цепочку (руВПС + забугорный ВПС). В контексте темы топика я правильно понимаю, что два отдельных IP на выход/вход надо делать на руВПС и далее уже связь с забугорным через один старый IP?