Разбивая лёд. Claude vs ТСПУ. Ноябрь 2026

Данная статья написана исключительно в исследовательских целях и не является инструкцией по применению.

Посадил я Клода в сеть Ростелекома и попросил выйти в мир. Вот что из этого вышло. Всё, что ниже — нейрослоп.

Как устроена фильтрация и что работает

Обзор по состоянию на ноябрь 2026 г. Основан на практической настройке цепочки «РФ → Европа» и замерах из сети Ростелекома. Конкретные серверы, IP и домены намеренно не указаны.

1. Как устроена фильтрация

ТСПУ

«Технические средства противодействия угрозам» — оборудование DPI (глубокой инспекции пакетов), установленное у операторов связи (Ростелеком, мобильные операторы, крупные провайдеры) и управляемое централизованно. Оператор связи сам правилами не управляет — политика одна на всю страну, но применяется неравномерно: по регионам, операторам и типам сетей (мобильная/проводная) картина может отличаться.

Что умеет ТСПУ

Блокировки по хостингам (замеры из Ростелекома)

Скачивание 2–10 МБ по HTTPS из сетей провайдеров:

Вывод: крупные и дешёвые зарубежные облака заморожены первыми. Картина меняется — проверять конкретный IP перед использованием (см. раздел 5).

2. Обзор способов обхода

2.1 Классические VPN (OpenVPN, WireGuard, IPsec, L2TP, PPTP)

• Протоколы с узнаваемыми сигнатурами, распознаются DPI.

• Статус: в РФ массово блокируются, особенно на зарубежные адреса. Годятся только как транспорт внутри уже замаскированного канала или для связи между доверенными узлами внутри страны.

2.2 Shadowsocks

• Шифрованный поток без явных заголовков. Старые версии распознаются по статистике и активным пробам.

• Статус: современные варианты (SS-2022) работают местами, но «случайный шум без TLS» сам по себе подозрителен. Уступает протоколам, маскирующимся под HTTPS.

2.3 Маскировка под HTTPS: Trojan, VLESS/VMess поверх TLS

• Трафик выглядит как обычный TLS на 443 порту. Нужен свой домен с настоящим сертификатом.

• Без защиты от активного зондирования сервер можно «прощупать».

• Статус: работает, но уступает Reality.

2.4 VLESS + Reality (+ XTLS Vision) — основной рабочий вариант

Протокол из проекта Xray.

• Reality: сервер не имеет «своего» поддельного сертификата. Для любого клиента без секретного ключа он прозрачно проксирует соединение на настоящий сайт (dest). Зонд ТСПУ получает настоящий сайт с настоящим сертификатом — отличить VPN от сайта невозможно.

• XTLS Vision (flow=xtls-rprx-vision) убирает характерный признак «TLS внутри TLS» в размерах пакетов.

• Fingerprint (fp=chrome) — ClientHello клиента неотличим от браузера Chrome.

Важно: выбор сайта-маскировки (SNI/dest):

• ❌ Крупные чужие домены (microsoft.com, google.com, cloudflare.com и т.п.) — режутся проверкой «SNI ↔ IP».

• ⚠️ Чужие малоизвестные сайты — работают, но завязаны на чужую инфраструктуру.

• ✅ Лучший вариант — собственный домен с настоящим сайтом на том же сервере. DNS домена указывает на этот же IP, сертификат настоящий, при зондировании отдаётся реальная страница.

2.5 XHTTP, gRPC, WebSocket — транспорт через HTTP и CDN

• Трафик идёт как обычные HTTP-запросы, можно пустить через CDN (например, Cloudflare): ТСПУ видит соединение с CDN, а не с вашим сервером.

• Плюсы: IP сервера скрыт, можно пережить блокировку IP.

• Минусы: ниже скорость, CDN сами подвержены замедлениям и частичным блокировкам в РФ; зависимость от политики CDN.

2.6 QUIC/UDP-протоколы: Hysteria2, TUIC

• Высокая скорость на плохих каналах.

• Статус в РФ: UDP и QUIC ограничиваются — нестабильно, для основного канала не рекомендуется.

2.7 Каскад с российским входным узлом («двойной VPN»)

клиент ──▶ сервер в РФ ──▶ сервер за рубежом ──▶ интернет

• Клиент подключается к российскому IP — международный трафик клиента ТСПУ не видит, блокировки зарубежных адресов на стороне абонента не действуют.

• Межсерверное плечо РФ → заграница: трафик «датацентр ↔ датацентр», выглядит как бэкапы/синхронизация.

• Входной узел можно спрятать за существующим российским сайтом: SNI-маршрутизатор (haproxy) на 443 отдаёт Reality-клиентов в Xray, всех остальных — на настоящий сайт.

• Минусы: две аренды, на входном узле лежит часть рисков (IP с сайтом может попасть под блок вместе с VPN).

• Статус: самый устойчивый вариант на сегодня.

2.8 Tor с мостами (obfs4, Snowflake, WebTunnel)

• Публичные узлы Tor блокируются; мосты с обфускацией — работают частично. WebTunnel маскируется под HTTPS-сайт, Snowflake — под WebRTC.

• Минусы: низкая скорость, не для повседневного трафика.

2.9 Локальный обход DPI без сервера (zapret, GoodbyeDPI, ByeDPI)

• Программа на устройстве/роутере «ломает» анализ DPI: фрагментирует ClientHello, шлёт фейковые пакеты с неверным TTL, меняет регистр заголовков и т.п.

• Работает против: замедлений и SNI-фильтрации (например, YouTube).

• Не работает против: блокировки по IP и «заморозки» по адресу — пакеты всё равно идут на заблокированный адрес.

• Плюс: не нужен внешний сервер, трафик не уходит за рубеж.

2.10 Шифрование DNS и ECH

• DoH/DoT (DNS-over-HTTPS/TLS) — защищает от подмены DNS-ответов провайдером. Сам по себе блокировки по IP/SNI не обходит.

• ECH (Encrypted Client Hello) — шифрует SNI. В РФ соединения с ECH блокируются, на практику не годится.

3. Сравнение

4. Теоретические рекомендации по построению

1. Протокол: VLESS + Reality + xtls-rprx-vision, порт 443, fp=chrome.

2. Схема: каскад «вход в РФ → выход за рубежом», если важна устойчивость; один зарубежный сервер — если его IP не замораживается из сетей ваших пользователей.

3. Маскировка: собственный домен с настоящим сайтом и сертификатом Let’s Encrypt на каждом узле. Живой сайт с посетителями — лучшая маскировка: реальный фоновый трафик делает VPN-соединения неотличимыми.

4. Сайт по умолчанию: на выходном узле настроить nginx default_server с нейтральным сайтом — его увидит всякий, кто обратится по IP или с чужим SNI.

5. Хостинг выхода: не брать крупные облака из «замороженного» списка; проверять конкретный IP до установки (раздел 5).

6. Межсерверное плечо: SNI тоже должен проходить ТСПУ — проверять перед запуском.

7. Ключи клиентов: отдельный UUID на каждого человека/устройство — тогда утёкший ключ отзывается точечно, а в логах видно, кто подключается.

8. Защита от жалоб хостеру (abuse): на выходе блокировать исходящую почту (25/465/587), BitTorrent, доступ к частным сетям. Жалобы на спам и торренты — основная причина закрытия аккаунтов.

9. Безопасность серверов: вход только по SSH-ключу, firewall «только нужные порты», минимум сервисов наружу.

10. Мониторинг: регулярно проверять выходной IP через туннель, скорость (скачивание ≥10 МБ ловит «заморозку»), активных клиентов, сроки сертификатов.

5. Как проверить сервер/IP до использования

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

1. Доступность: TCP-соединение на 443 и 22. Таймаут на всё — блокировка по IP.

2. «Заморозка»: временно поднять на кандидате HTTPS-сервер с файлом 10 МБ и скачать его. Пришло меньше ~20 КБ — адрес заморожен, использовать нельзя.

3. SNI: TLS-рукопожатие с выбранным для маскировки SNI на IP кандидата. Нет ответа — SNI режется для этого IP.

4. Цель маскировки: сайт должен поддерживать TLS 1.3 и HTTP/2.

5. Сквозной тест после настройки: выходной IP через туннель + скачивание 10–20 МБ.

Для быстрой оценки провайдера без аренды: скачать крупный файл с его speedtest-узла или зеркала Debian/Ubuntu, размещённого в его сети.

6. Типичные ошибки

7. Правовой контекст (кратко)

• Использование VPN физическими лицами в РФ на момент написания не запрещено; ограничены реклама и популяризация средств обхода блокировок, а также доступ через них к запрещённой информации.

• Провайдер выходного сервера живёт по законам своей страны и своим правилам (AUP): проверяйте, не запрещены ли там VPN/прокси и как он реагирует на жалобы.

• Документ описывает технические принципы и не является юридической консультацией.