Привет, Хабр.

Статья с более приятным Markdown-оформлением доступна на моем сайте, не забудьте поставить плюс!

Посмотрим, как работает сам ТСПУ, как его обойти, какой протокол выбрать, какой клиент использовать и узнаем чего ожидать в будующем.

Белые списки на мобильном я тут не буду затрагивать так как уже писал статью на эту тему. Историю тоже, про нее писал 119-минутный лонгрид о 2008–2026 годах.

Для начала сведем все к двум видам блокировки: тупой и умной. Это упрощение с которым легче понять принцип работы ТСПУ.

ТСПУ смотрит на IP-адрес, порт и транспортный протокол пакета. Если они попадают под правило блокировки, выкидывает пакет. До сервера вы просто не дошли.

Например, запрещен весь трафик к определенному IP, TCP на порт 443 или вообще весь UDP.

Зашифровали запрос? Адрес, порт и транспорт все еще те же. Разбили запрос на части? Все еще отправляете их туда же тем же способом. Если правило отбрасывает такое подключение целиком, менять содержимое пакетов бесполезно.

Под такое правило попадает весь трафик с выбранными признаками. Заблокировали общий IP - положили все сайты на нем. Закрыли TCP/443 - отрезали HTTPS по TCP. Запретили UDP - отвалились QUIC, игры и звонки, которые его используют. Задели диапазон CDN - вместе с нужным сервисом легли чужие сайты, обновления и API.

Запрещен порт - меняем порт. Запрещен транспорт - меняем транспорт. Запрещен IP - идем на другой IP. Например, подключаемся к посреднику, а он уже идет на нужный сайт. Дальше буду называть это туннелем. Обмануть такую блокировку изменением запроса не получится. Придется менять само подключение, идти на другой IP, использовать другой порт или транспорт. Например, через VPN-сервер.

Для точечной блокировки ТСПУ может пропустить подключение и проверить, к какому сайту или сервису мы идем.

Теперь представим, что адрес, порт и транспорт разрешены. Но ТСПУ смотрит, что мы передаем.

Например, в начале обычного HTTPS-соединения браузер сообщает имя сайта через SNI. Мы говорим серверу: «привет, мне нужен owenewans.org». ТСПУ читает это имя и обрывает соединение. Другой сайт на том же IP продолжает работать ведь его SNI не заблокирован.

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

Иногда даже не нужен туннель. Можно изменить запрос так, чтобы сервер понял запрос, а ТСПУ не узнал запрещенный признак. Для этого исуществуют zapret, zapret2, ByeDPI и ByeByeDPI. Дальше буду называть это анти-DPI.

Самый простой пример для понимания анти-DPI : Представьте фильтр, который блокирует сайт owenewans.org. Он ищет это имя целиком в самом начале интернет-запроса. Мы берем и разрезаем запрос пополам прямо посреди имени: в первый пакет отправляем owenew..., а во второй - ...ans.org.

Фильтр провайдера смотрит на первый пакет, не видит там целого адреса и пропускает его. Смотрит на второй - там тоже обрывок, и он тоже проходит. А уже на конечном сервере обе половинки склеиваются обратно в owenewans.org, и сайт успешно открывается.

Сейчас фильтр провайдера научился склеивать разорванные пакеты, обычный разрез не работает. Так что сейчас обходы устроены хитрее.

Тоесть, ТСПУ должен ошибиться, а сервер должен получить нормальный запрос. Если сломали запрос для обоих, вы просто сломали себе интернет.

Для этого есть ECH: он защищает внутренний ClientHello, включая настоящее имя сайта. Прочитать его из обычного SNI уже не получится.

Только вот остается виден сам признак использования ECH, ТСПУ может запретить соединения с ECH целиком.

Сервер сначала узнали по протоколу, потом добавили его IP в запрет. Вы поменяли протокол, а адрес остался тот же. Все еще не работает, или соединение разрешили, но начали выкидывать часть пакетов: страница вроде открывается а видео стоит.

Фильтры и балансировщики для ТСПУ выпускает RDP.ru. У фильтра есть общая аппаратно-программная платформа EcoSGE. На ней работают EcoFilter, который проверяет адреса и запросы по спискам, и EcoDPI, который распознает протоколы. Поэтому дальше, когда говорю о DPI, имею в виду эту часть российского ТСПУ.

Сам фильтр - стоечное устройство с процессором Intel Xeon, оперативной памятью и сетевыми портами. Например, у EcoFilter 4120 их 12, у 4160 - 16, по 10 Гбит/с. Порты работают парами: с одной стороны приходит трафик абонента, с другой идет обмен с интернетом.

Перед фильтрами могут стоять EcoFilter Balancer или Eco Highway. Они распределяют потоки и применяют свои правила по адресам и портам. За журналами и подготовкой списков стоит ПО EcoDPIOS: сервер предварительного формирования списков, СПФС, и система централизованной обработки списков, СЦОС.

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

Так вот, допустим, вы пользователь и хотите зайти на owenewans.org.

Будем следовать сначала за DNS-запросом, потом за соединением с сайтом и ответом.

Чтобы отправить запрос сайту, программа должна узнать его IP. Мы спрашиваем DNS-резолвер: «дай запись для owenewans.org». A-запись содержит IPv4-адрес, AAAA содержит IPv6. Браузер может запросить обе.

Система проверяет кеш и hosts. Если ответа нет, обращается к настроенному DNS-серверу.

Наш DNS-пакет идет к резолверу (например 8.8.8.8). Имя owenewans.org находится внутри вопроса, и в обычном не шифрованом DNS его можно прочитать по дороге.

Но до этого ответа еще надо дожить.

Если что те-же ошибки ( на то они и ошибки ) бывают и без блокировки: домен может не существовать, а DNS-сервер может сломаться, но мы представим именно вмешательство в запрос.

Первая: вместо адреса сайта нам возвращают заглушку. Например, адрес страницы о блокировке или значение, по которому сайт не откроется.

Вторая: получаем NXDOMAIN, будто домена не существует.

Третья: REFUSED, резолвер отклонил запрос.

Четвертая: SERVFAIL, разрешение имени не удалось.

Пятая: фильтр отбрасывает вопрос или ответ. Клиент ждет, повторяет попытку, может попробовать следующий резолвер. Если ответа так и нет, сообщает, что время ожидания вышло.

Оператор может настроить запрет на своем резолвере или вмешаться в запрос к чужому. Например, перехватить обращение на порт 53.

Отправим DNS-вопрос по шифрованному соединению. DoT - DNS over TLS, вопрос идет внутри TLS, обычно через TCP/853. DoH - DNS over HTTPS, вопрос отправляем внутри HTTPS-запроса, обычно на порт 443.

Вопрос про owenewans.org скрыли шифрованием. Само соединение с резолвером проходит проверку DPI и тоже может попасть под блокировку.

Да, даже у DoT и DoH есть свои отпечатки. Помогают они только с скрытием данных но не факта передачи.

Можно отправить DNS через туннель, например через настроенный SSH-туннель с защищенным соединением. Запрос уйдет внутри него, и оператор не увидит, что мы спрашиваем про owenewans.org.

Снаружи останется соединение с сервером туннеля. Разумеется то насколько оно похоже на обычный трафик, зависит от протокола и настроек.

Получили 93.95.228.248. Теперь идем к сайту.

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

У сайта могут быть IPv4 и IPv6. Браузер пробует оба пути и использует тот, по которому быстрее установилось соединение. Например, IPv6 заблокирован, а по IPv4 сайт открывается: браузер использует IPv4.

Если хотим полностью обойти DNS надо сохранить имя сайта и отдельно указать клиенту его адрес, например через hosts.

Пакет уходит в домашний роутер, затем в сеть провайдера. Дальше проходит его оборудование, а после - другие сети по дороге к серверу.

ТСПУ стоит внутри сети оператора, до NAT или после него. До NAT оно видит адрес конкретного абонента и может связать обращение к owenewans.org с ним. После NAT оно видит общий внешний IP, через который выходят другие абоненты.

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

Фильтр прозрачный для IP-маршрутизации: пропускает пакеты через себя без отдельного видимого прыжка в traceroute.

Перед фильтрами могут стоять bypass и балансировщик.

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

Если фильтров несколько, балансировщик делит между ними соединения. Пакеты одного соединения он направляет к нужному фильтру, чтобы тот видел обмен целиком.

При отказе одного фильтра трафик могут отдать оставшимся. Это перераспределение делает балансировщик; bypass нужен для прямого пути в обход обработки.

ТСПУ проверяет IP, порт и транспорт нашего подключения. Под запретом может быть один адрес, диапазон, конкретный порт или весь UDP.

Например, мы идем к 93.95.228.248 по TCP на порт 443. Если правило запрещает такое подключение, фильтр выкидывает пакет. До сайта мы не дошли.

Понадобится доступное сочетание адреса, порта и транспорта. При полном запрете IP - другой адрес сайта или туннель через доступного посредника.

В адресе сайта мы выбираем и способ обращения. http:// позволяет передать запрос без TLS, https:// использует TLS для защиты обмена.

При обычном HTTP имя сайта и запрос страницы видны по дороге. ТСПУ может прочитать их и заблокировать домен или конкретный адрес страницы. Вместо страницы сайта фильтр может отправить 307 Temporary Redirect, и браузер перейдет на заглушку о блокировке. В HTTPS фильтр не может подставить такой ответ без перехвата TLS.

Наш owenewans.org открываем по HTTPS через TCP. Чтобы передать запрос, сначала установим соединение, потом договоримся о TLS. Тут нас тоже могут остановить.

Браузер начинает TCP-обмен с owenewans.org : «хочу соединиться» - SYN. Сервер отвечает: «готов» - SYN-ACK. Браузер подтверждает - ACK.

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

Еще фильтр может отправить сброс TCP, RST, от имени другой стороны.

TCP установили. Теперь браузеру надо договориться с сервером о TLS.

Браузер отправляет ClientHello и начинает TLS. Здесь обмен проверяет DPI. Как он распознает трафик и принимает решение о блокировке, разберем ниже.

Если правило сработало, фильтр может отбросить сообщение клиента, ответ сервера или сбросить соединение. При сбросе браузер покажет ошибку, при молчаливом отбрасывании будет ждать и повторять передачу.

Проверка может продолжиться и после первых сообщений, по мере обмена.

Прошли проверку и установили TLS. Браузер отправляет HTTP-запрос к owenewans.org внутри шифрованного соединения. Сервер обрабатывает его и возвращает страницу.

Ответ идет через сеть обратно к нам и снова проходит фильтры. ТСПУ может пропустить запрос, но заблокировать ответ. Если пропустили оба направления, браузер получает страницу.

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

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

Другой вариант - разрешить начальный объем, а дальнейшую передачу ограничить. Тогда короткий запрос работает, большой файл зависает.

Ограничение через очередь заставляет пакеты ждать. Ограничение через отбрасывание заставляет стороны повторять отправку. Пользователь в обоих случаях видит медленную загрузку, зависшее видео или соединение, которое вроде установилось, но дальше ничего не передает.

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

Фильтр заводит запись о соединении. Ее отличают пять значений: IP клиента, порт клиента, IP сервера, порт сервера и транспортный протокол, TCP или UDP. Это 5-tuple. По ним фильтр относит следующие пакеты к тому же обмену, включая ответы сервера.

В TCP номера последовательности показывают положение байтов в потоке. Если ClientHello приехал несколькими сегментами, ТСПУ сохраняет части и собирает сообщение. Поэтому простой разрез owen и ewans.org уже не помогает: после сборки фильтр получает полное имя.

У обычного DNS фильтр читает имя домена из вопроса и тип запрашиваемой записи, например A или AAAA.

У HTTP фильтр читает запрос и заголовок Host независимо от порта. Например:

Отсюда получает имя owenewans.org и путь /article, затем сравнивает их со списком блокировки.

У HTTPS фильтр разбирает ClientHello: тип сообщения, длины полей и расширения. В расширении SNI находит имя сайта. С QUIC ситуация такая же: ТСПУ извлекает ClientHello из начальных пакетов и проверяет SNI.

ECH защищает внутренний ClientHello, включая настоящее имя сайта. Прочитать owenewans.org из него без ключей не получится. Но ТСПУ может запретить такой обмен целиком, вместо выбора отдельных скрытых доменов.

Например, у Cloudflare проверяет сразу три признака: адрес из его диапазонов, внешнее SNI cloudflare-ech.com и расширение ECH. При совпадении отбрасывает пакеты соединения, как по TCP, так и по QUIC. Правило действует на выбранных диапазонах IP, поэтому один сайт с ECH у вас открывается а другой нет.

Сигнатура задает признаки протокола: определенные байты, расположение и длины полей, типы сообщений, порядок запросов и ответов.

В EcoSGE есть проверка незапрошенных HTTP-ответов. Сервер прислал HTTP-ответ сразу после установки TCP, хотя клиент еще не отправлял запрос. Фильтр может заблокировать такую сессию за неправильный порядок обмена.

Например, SSH начинает обмен строкой вида SSH-2.0-OpenSSH_.... По ней фильтр распознает SSH еще до авторизации.

Немного теории: пауза перед принятием SSH-ключа может выдать первое подключение, а если отпечаток не сверить вручную, в теории можно довериться подставному серверу ТСПУ и отдать ему пароль. Разумеется это страшилки и выдумки. Пока что. =)

Или же у OpenVPN в заголовке сообщения есть байт с типом пакета и номером ключа. Старшие пять бит задают тип, младшие три - номер ключа. Начальное сообщение клиента P_CONTROL_HARD_RESET_CLIENT_V2 имеет код 7, ответ сервера P_CONTROL_HARD_RESET_SERVER_V2 - код 8. Это признаки собственного формата OpenVPN, которые остаются снаружи шифрованных данных туннеля.

ТСПУ распознает много чего, например OpenVPN TCP и UDP, IPsec, L2TP, PPTP, Telegram и его прокси с имитацией TLS. Проверка охватывает оба направления: признаки протокола есть и в запросах клиента, и в ответах сервера.

Программы могут иметь схожие признаки. Если правило слишком широкое, вместе с запрещенным протоколом оно заденет и другой трафик. Например, при блокировке SSH отвалится и SFTP, который работает через него.

Браузер, curl и приложение на телефоне начинают TLS с разными параметрами: предлагают свои наборы шифров, расширений и поддерживаемых групп. Фильтр видит эти поля ClientHello и их порядок. У клиентов DoH/DoT эти параметры тоже видны, хотя сам DNS-вопрос зашифрован.

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

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

Например, sing-box и Xray используют uTLS для имитации ClientHello браузера. В настройках выбираем отпечаток Chrome или Firefox, и клиент отправляет соответствующие шифры и расширения.

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

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

Блокирующая система может сама подключиться к подозрительному серверу, притворившись клиентом туннеля. Отправить запрос и посмотреть, что он ответит.

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

Такую проверку называют активным зондированием.

Фильтр проверяет DPI-списки по приоритету и учитывает исключения. Правило задает действие: заблокировать, сразу пропустить или продолжить проверку следующими списками. ТСПУ может распознать OpenVPN, записать результат в журнал и пропустить соединение, если блокировка для него не задана.

Распознав OpenVPN, фильтр запоминает протокол соединения. Дальше применяет его правила ко всем пакетам этого обмена. Пока запись остается в кеше, он может использовать прежнюю классификацию для обмена с теми же IP, портами и транспортным протоколом.

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

Например, ТСПУ распознал Telegram-прокси, его адрес добавили в список блокировки. Следующие подключения к этому адресу попадают под адресное правило. Меняем протокол на том же сервере - все равно не работает, потому что IP остался прежним. Умная блокировка превратилась в тупую.

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

При тупой блокировке меняем запрещенный IP, порт или транспорт на доступный. При умной - меняем передачу данных, чтобы ТСПУ не распознал запрещенный признак, или прячем обмен внутри туннеля.

Подключаемся к доступному серверу, а он уже идет на owenewans.org. Запрос и ответ проходят через него. ТСПУ видит соединение с посредником, сайт видит адрес посредника.

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

Туннель нужен при блокировке IP или целого диапазона. Подходит и для обхода запрета по имени или протоколу. Через него можно направить отдельное приложение, выбранные сайты или весь трафик устройства. Доступность и скорость зависят от сервера и пути до него.

Если ТСПУ блокирует протокол самого туннеля, выбираем другой транспорт или маскировку обмена. Если заблокирован его IP, нужен сервер с другим доступным адресом.

Против умной блокировки используем zapret, zapret2 и ByeDPI. Они меняют передачу данных на пути к сайту. Мы продолжаем подключаться к owenewans.org напрямую.

Сервер должен получить правильный запрос, а ТСПУ - не распознать запрещенный признак.

При умной блокировке для игр и звонков анти-DPI. Там важен пинг, менять IP не требуется. Если IP, порт и транспорт сервиса доступны, идем к нему напрямую через zapret или ByeDPI.

При тупой блокировке IP или когда просто нужно сменить адрес - идем через туннель. Только теперь весь выбранный трафик проходит через VPN-сервер. Это добавляет пинг, а скорость упирается еще и в его канал и нагрузку.

Зато готовый VPN проще завести: добавили профиль, включили, пользуемся. С zapret придется повозиться со стратегиями. Конфиг, который работает у друга, у вас может не заработать: другой провайдер, другая версия или настройки ТСПУ.

Кратко о самих протоколах и мое мнение.

SSH - Да именно он, протокол для защищенного удаленного доступа, обычно через него управляют сервером в терминале. Но внутри того же соединения можно передавать TCP-соединения других программ. Минималистично, быстро и легко. Если SSH доступен и сервер разрешает проброс TCP, будет работать. Есть поддержка TUN-туннелей.

Hysteria 2 - Прокси на QUIC, между клиентом и сервером идет UDP, внутри можно передавать и TCP, и UDP. Для скорости. Выбираем, если UDP до сервера доступен. Советую официальный сервер Hysteria, а не реализации из ядер типо sing-box.

NaiveProxy - HTTPS-прокси, передает соединения через HTTP/2 или HTTP/3. Для маскировки использует сетевой стек Chromium, тот же, что и в Chrome, плюс дополняет первые сообщения лишними байтами, чтобы скрыть их характерные размеры. Но огромный расход батареи и трафика.

Mieru - Зашифрованный прокси поверх TCP или UDP. Работает без TLS, поэтому домен и сертификат для сервера не нужны. Добавляет случайные данные к сообщениям, чтобы скрывать их размеры. Если хочется реально без гемороя, иногда падает.

Juicity - Еще один прокси на QUIC для передачи TCP и UDP. До сервера тоже нужен доступный UDP. Если хочется попробовать что-то вместо Hysteria. Отдельной причины предпочесть его Hysteria у меня нет.

Shadowsocks - Зашифрованный прокси для TCP и UDP. Не маскируется под браузерный HTTPS. Для ТСПУ мертв. Костылить плагинами не вижу смысла.

VLESS - Протокол проксирования из Xray с авторизацией по UUID. Для защиты и маскировки соединения обычно добавляют TLS или REALITY, а для передачи данных выбирают транспорт, например XHTTP. Переусложнен. Xray тяжелый и конфиг излишне сложный, sing-box пытается делать слишком многое ( например та же поддержка hysteria которая славно что хотяб работает ). Смысл в нем наверное только для XHTTP поверх CDN или для коммерческих VPN.

Мое мнение. К слову, для обычного базового VLESS и обычного юзера подойдет практически любой клиент. Кроме разве что Karing - он слишком сложный.

Exclave - Пожалуй, лучший клиент по возможностям: современный, большой выбор протоколов, использует реализации от создателей протоколов. Минус - уродливый интерфейс.

owenclave - Мой форк Exclave. Переработан интерфейс и мои небольшие изменения. Есть загрузка зашифрованных подписок happ5crypto, настройка User-Agent, подмена HWID и тд.

FlClash - Третий выбор после Exclave и owenclave. Просто красивый интерфейс и все работает, но в owenclave он тоже красивый, а возможностей у owenclave больше. Тут на любителя. И что забавно надо ввести руками / скопировать длинное предупреждение что приложение не предоставляет серверы, забавно.

Happ - Из плюсов большая кнопка, добавление профиля одним нажатием и удобство для коммерческих VPN с VLESS. Интерфейс на любителя, ядро отстает. Hysteria использует через реализацию sing-box, и нормально она не работает. SSH и Mieru нативно нет. Closed source.

Incy - Happ с другим интерфейсом который к тому же еще более на любителя. Выглядит навайбкоженным, Hysteria тоже нормально не работает. Выбирать разве что из-за внешнего вида. Closed source.

Hiddify - Красивый, и на этом все. Последний стабильный релиз не поддерживает даже Hysteria Gecko, да и в остальном показал себя плохо. Брать разве что ради интерфейса... Хотя для него есть FlClash или owenclave.

Karing - Старый интерфейс и неприятный UX. Я минут двадцать пытался понять, как добавить отдельную ссылку вида proto://, а не подписку example.org/link. Чисто на любителя. Если так нравится страдать, проще использовать sing-box напрямую.

'

Throne - Пожалуй, лучший клиент на ПК. Hysteria и все остальное работает. Из минусов - очень уродливый интерфейс и для кого-то избыток функций, хотя для меня второе плюс.

FlClash - Очень красивый интерфейс, хорошая поддержка протоколов, но мало функций. Для тех, кому надо, чтобы все работало без лишних наворотов, наравне с Throne. Только при первом запуске надо РУКАМИ ввести / вставить длинное предупреждение на английском о том, что приложение не предоставляет серверы, подписки и доступ в сеть. Не шучу. Сюр какой то.

v2rayN - По сути Throne с другим интерфейсом и более ограниченной поддержкой протоколов и их возможностей. Особых причин выбирать его вместо Throne не вижу.

Hiddify - Красивый, и на этом все. Последний стабильный релиз не поддерживает даже Hysteria Gecko, да и в остальном показал себя плохо. Брать разве что ради интерфейса или пробовать нестабильную сборку. При наличии FlClash смысла не вижу.

Karing - Старый интерфейс и неприятный UX. Я минут двадцать пытался понять, как добавить отдельную ссылку вида proto://, а не подписку example.org/link. Чисто на любителя. Если так нравится страдать, проще использовать sing-box напрямую.

Частично я уже рассуждал об этом в статье про чебурнет, но с того времени много что поменялось.

Очередные сигнатуры и обновления фильтров я перечислять логично что не буду. больше волнуют сценарии, в которых придется переделывать сами способы обхода.

На мобильном это уже происходит, я даже отдельную статью писал. Теперь представим, что ту же практику перенесут на домашние подключения и начнут доводить до ума.

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

С CDN похожая история. Пока разрешенный CDN позволяет любому клиенту проксировать запросы на свой сервер, через него можно пустить, например, XHTTP. Но доступ к таким CDN оставят только одобренным клиентам. Надо договориться с владельцем инфраструктуры ИЛИ заставить его.

DNS-туннели тоже не вечные. В нашем чате им посвящена целая ветка, щас реализации уже позволяют передавать приличные объемы данных. Но оператор может: оставить только свой резолвер, разрешить запросы только к определенным доменам, добавить шейпинг и рейт-лимиты.

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

Отвалится куча нормальных сервисов, людям станет ОЧЕНЬ неудобно. Хотя... на мобильных сетях это уже никого не останавливает.

Про сертификаты Минцифры я тоже писал. Сценарий такой: заставить пользователей доверять нужному корню, поставить перехватывающий прокси и пропускать только соединения, которые он может расшифровать. Клиент договаривается о ключах с посредником, посредник отдельно подключается к настоящему серверу.

Для обхода придется заботиться еще и о том, что видно внутри HTTPS. Gосредник увидит, что после рукопожатия вы гоняете вместо/по HTTP. Понадобятся нормальные запросы и еще один слой шифрования для данных.

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

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

Допустим, вы притворяетесь посетителем моего ( когда-то ) текстового сайта owenewans.org. Только почему-то двенадцать часов подряд гоняете через него гигабайты трафика. А потом таких посетителей становится три тысячи, и все восемь часов качают что-то с одного сервера.

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

Обычный юзер не купит себе триста серверов ради семейного VPN. Нескольким людям с одним VPS станет сложнее, а разработчикам придется добавлять задержки, лишний трафик и маскировку поведения. Протоколы будут жирнеть, настройка усложняться. И все это ради того, чтобы открыть сайт.

Пожалуй самая спорная часть. Я считаю что нейросети/ии/ллм/трансформеры и тому подобное используется максимум статически при анализе больших обьмов данных но никак ни в реал тайме, хотя данных об этом у нас просто нет.

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

Чисто для примера в мою голову пришел Jev. Модель возвращает структурированные ответы и вероятности вместо длинного текста. Модели можно поручить узкую классификацию ( оф коурс для сетевого трафика понадобится своя модель и свои данные ).

ИИ классификатор может работать быстро, проблема - обработать масштаб всей сети и не перебанить легитимный трафик. Модель ошибется, а у человека отвалится банк, игра или сервис.

РКН при этом планировал направить 2,27 млрд рублей на фильтрацию трафика с машинным обучением.

Я не разработчик нейросетей.

Разумеется, я разобрал не все механизмы ТСПУ и способы их обхода. Некоторые моменты пришлось упростить, иначе статья превратилась бы в техническую документацию. Хотя тут и без того набралось пять тысяч слов.

© owenewans. All photos and images in this article are protected by copyright. The material is distributed under the terms of the Creative Commons Attribution 4.0 International

© owenewans. Code snippets, if any, are distributed under the terms of Unlicense.