Как работают ТСПУ Роскомнадзора? Разбираемся вместе

⚠️ Дисклеймер: Материал носит исключительно информационный и образовательный характер. Все описанные команды и примеры предназначены для изучения сетевых технологий, диагностики собственных систем и поиска технических неисправностей. Материал не предназначен для обхода установленных ограничений доступа. Перед применением информации убедитесь, что ваши действия соответствуют законодательству Российской Федерации и правилам используемых сервисов.

Технические средства противодействия угрозам (ТСПУ) — тема, которая обрастает мифами быстрее, чем Raspberry Pi обрастает пылью на полке. В интернете хватает историй от «это просто чёрный ящик, который режет всё подряд» до предположений о полном анализе каждого действия пользователя.

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

Кстати, позже с этой темой произошла уже вполне реальная история: в Яндекс.Метрике я обнаружил переход на статью про ТСПУ из системы МИР ГРЧЦ. Об этом отдельно написал в материале «Роскомнадзор стучится в мои двери: как система МИР нашла мою статью про ТСПУ».

Что такое ТСПУ на самом деле

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

Если сильно упростить, это специализированный сетевой узел, который находится на пути трафика и способен анализировать проходящие соединения.

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

Поэтому искать в интернете фотографию «того самого ТСПУ» и представлять, что у всех провайдеров установлена одинаковая коробка, было бы слишком большим упрощением.

Как ТСПУ может встраиваться в сеть

Упрощённо сеть оператора можно представить так:

Интернет
    |
Магистральная сеть оператора
    |
Средства анализа и фильтрации трафика
    |
Агрегационная сеть
    |
Абонентские подключения

Главная идея здесь проста: оборудование анализа находится между абонентом и внешней сетью.

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

Пассивный и активный анализ

У сетевого оборудования вообще существует два принципиально разных подхода к анализу трафика.

Пассивный режим — копия трафика передаётся анализатору. Само устройство непосредственно не участвует в передаче пакетов.

Такую схему часто называют:

SPAN
mirror
port mirroring

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

Inline-режим означает, что оборудование находится непосредственно на пути передачи данных.

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

Что вообще можно увидеть в сетевом трафике

Здесь часто возникает заблуждение: раз HTTPS шифрует данные, значит промежуточное оборудование вообще ничего не видит.

Это не совсем так.

Даже у зашифрованного соединения остаётся некоторое количество служебной информации.

Например:

• IP-адрес источника;
• IP-адрес назначения;
• порт назначения;
• время начала соединения;
• продолжительность соединения;
• количество переданных данных;
• особенности установления TCP-сессии;
• отдельные параметры TLS-рукопожатия.

Само содержимое HTTPS-запроса при корректно установленном TLS при этом остаётся зашифрованным.

То есть условный промежуточный сетевой узел может видеть:

192.0.2.10
    ↓
TCP 443
    ↓
203.0.113.20

но это совершенно не означает, что он автоматически видит пароль, который пользователь вводит на HTTPS-сайте.

Как может выполняться фильтрация

Разные ситуации требуют разных методов. Поэтому сводить всю работу ТСПУ к банальному списку IP-адресов было бы неправильно.

1. Фильтрация по IP-адресу

Самый понятный вариант.

Существует определённый IP:

203.0.113.25

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

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

Особенно это характерно для:

• CDN;
• облачных платформ;
• shared hosting;
• reverse proxy;
• крупных веб-инфраструктур.

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

Для диагностики собственного сервера обычный администратор может начать с самого простого:

ping 203.0.113.25

Но отсутствие ответа на ping ещё вообще ничего не доказывает. ICMP может быть отключён непосредственно на сервере или firewall.

Гораздо полезнее проверять тот сервис, который действительно используется.

Например HTTPS:

curl -I https://example.com

или TCP-порт:

nc -vz example.com 443

2. DNS и почему он не всегда виноват

Когда пользователь вводит:

example.com

компьютеру сначала нужно узнать IP-адрес этого домена.

Для этого используется DNS.

Проверить, какой адрес получает ваша система, можно обычной командой:

dig example.com

или:

nslookup example.com

На Windows:

nslookup example.com

Если DNS вообще не возвращает адрес, соединение ещё даже не дошло до TCP.

Но здесь важно не делать поспешных выводов.

Разные DNS-серверы иногда возвращают разные IP совершенно легитимно. Причиной может быть:

• CDN;
• GeoDNS;
• балансировка;
• Anycast;
• кеширование;
• изменение инфраструктуры самого сайта.

Поэтому различающиеся DNS-ответы сами по себе ещё не означают вмешательство в соединение.

3. DPI — Deep Packet Inspection

DPI расшифровывается как Deep Packet Inspection, то есть глубокий анализ пакетов.

Подобные технологии используются далеко не только для ограничений доступа.

DPI можно встретить у:

• интернет-провайдеров;
• операторов мобильной связи;
• крупных компаний;
• систем информационной безопасности;
• систем предотвращения атак;
• сетевых анализаторов.

Система может анализировать не только IP и порт, но и структуру конкретного протокола.

Например, отличить:

HTTP
TLS
DNS
SSH
QUIC

по характерным особенностям обмена данными.

Что такое SNI

При установлении HTTPS-соединения клиент сначала создаёт TLS-сессию.

В классической схеме в TLS ClientHello может передаваться имя сервера — Server Name Indication (SNI).

Упрощённо:

Клиент
   |
   | TLS ClientHello
   | SNI: example.com
   ↓
Сервер

Это необходимо потому, что один IP-адрес может обслуживать множество HTTPS-сайтов.

Серверу нужно понять, сертификат какого именно сайта использовать.

Именно поэтому ситуация:

TCP 443: OK
TLS: ERROR

ещё не говорит, что сервер недоступен полностью.

Проблема может находиться в:

• SNI;
• сертификате;
• reverse proxy;
• TLS-конфигурации;
• виртуальном хосте веб-сервера.

4. Анализ сетевых протоколов

Разные протоколы имеют собственные особенности установления соединений.

Например, отличаются:

• последовательности пакетов;
• размеры сообщений;
• структура handshake;
• тайминги;
• используемые транспортные протоколы.

Это позволяет сетевому оборудованию классифицировать трафик.

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

Корпоративный firewall тоже может показать администратору примерно такую статистику:

HTTPS       63%
DNS          8%
QUIC        12%
SSH          2%
Other       15%

То есть способность определить тип соединения ещё не означает чтение его содержимого.

Можно ли увидеть ТСПУ через traceroute

Вот здесь начинается интересная часть.

Интуитивно хочется выполнить:

traceroute 8.8.8.8

или в Windows:

tracert 8.8.8.8

и найти среди узлов что-нибудь вроде:

tspu.provider.ru

Но в реальности всё не настолько просто.

Inline-оборудование может работать прозрачно для IP-маршрутизации и вообще не появляться отдельным hop.

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

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

traceroute полезен прежде всего для другой задачи — понять, на каком участке вообще меняется маршрут или начинаются потери.

Как диагностировать странную недоступность сайта или сервера

Самый полезный подход — не пытаться сразу ответить на вопрос:

«Это точно ТСПУ?»

А последовательно проверить обычную сетевую цепочку.

Например:

DNS
 ↓
TCP
 ↓
TLS
 ↓
HTTP

Проверяем DNS

nslookup example.com

Если адрес получен — переходим дальше.

Проверяем TCP 443

Linux:

nc -vz example.com 443

Windows PowerShell:

Test-NetConnection example.com -Port 443

Если TCP-соединение устанавливается, значит базовая связность до порта есть.

Проверяем TLS

Можно использовать OpenSSL:

openssl s_client -connect example.com:443 -servername example.com

Здесь уже можно увидеть:

• установилось ли TLS-соединение;
• какой сертификат вернул сервер;
• на каком этапе появилась ошибка.

Проверяем HTTP

curl -I https://example.com

Если все четыре этапа работают:

DNS:   OK
TCP:   OK
TLS:   OK
HTTPS: OK

то на базовом уровне соединение исправно.

Если один из этапов ломается — мы хотя бы понимаем, где именно искать проблему.

И это намного полезнее предположения «провайдер что-то режет» после одного неоткрывшегося сайта.

Почему один тест ничего не доказывает

Допустим:

DNS: OK
TCP: TIMEOUT

Причиной может быть далеко не только промежуточная фильтрация.

Точно такой же результат дадут:

• firewall сервера;
• закрытый порт;
• ошибка маршрутизации;
• сломанный reverse proxy;
• проблемы хостинга;
• авария у оператора;
• неверная конфигурация сети.

Или другой пример:

TCP: OK
TLS: ERROR

Возможные причины:

• неправильный SNI;
• истёкший сертификат;
• TLS-конфигурация сервера;
• ошибка nginx;
• неправильный виртуальный хост;
• проблема на промежуточном участке сети.

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

Сравнение нескольких обычных подключений

Если речь идёт о вашем собственном сервере, диагностику можно сделать гораздо убедительнее.

Например, проверить его:

домашний интернет
мобильный интернет
другой провайдер
сам сервер

Представим:

Домашняя сеть:
TCP 443: OK
TLS: OK

Мобильная сеть:
TCP 443: OK
TLS: ERROR

Сам сервер:
HTTPS: OK

Вот это уже интересная информация для администратора.

Но даже здесь технически правильнее сказать:

На одном сетевом пути соединение стабильно перестаёт работать на этапе TLS.

А не:

Мы на 100% нашли ТСПУ.

Причину всё равно придётся исследовать дальше.

Почему HTTPS не делает соединение полностью невидимым

Ещё один популярный миф:

«У меня HTTPS, значит провайдер вообще ничего не видит».

HTTPS действительно защищает содержимое соединения.

Например, при нормальной TLS-сессии промежуточный узел не должен видеть:

пароль пользователя
текст сообщения
содержимое формы
cookie внутри HTTPS
конкретный HTTP-запрос

Но часть метаданных остаётся доступной.

Например:

IP назначения
порт
объём трафика
время соединения
часть параметров установления TLS

Это фундаментальное свойство современной сетевой архитектуры, а не особенность конкретно ТСПУ.

А что насчёт новых версий TLS

Интернет-протоколы постоянно развиваются.

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

Поэтому методы классификации трафика тоже со временем меняются.

Получается своеобразная гонка:

развиваются протоколы
        ↓
меняется сетевой трафик
        ↓
обновляются средства анализа
        ↓
появляются новые версии протоколов

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

Может ли ТСПУ замедлять интернет

Теоретически любое inline-оборудование добавляет ещё один элемент в сетевую цепочку.

Но определить его наличие по одному пингу практически невозможно.

Допустим, вчера было:

25 ms

а сегодня:

31 ms

Причиной могут быть:

• другой маршрут;
• загрузка сети;
• изменение пиринга;
• перегрузка сервера;
• Wi-Fi;
• мобильная сеть;
• временные проблемы оператора.

Поэтому утверждение:

«Пинг вырос на 5 миллисекунд — значит включили ТСПУ»

технически несостоятельно.

Для нормального анализа нужны длительные измерения и сравнение нескольких маршрутов.

Например:

ping -c 100 8.8.8.8

или:

mtr 8.8.8.8

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

Что ТСПУ означает для домашнего администратора

Для человека, который держит дома Raspberry Pi, Rock Pi, Orange Pi, NAS или собственный веб-сервер, главная практическая мысль довольно простая.

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

Сначала проверяем:

DNS
 ↓
маршрут
 ↓
TCP-порт
 ↓
TLS
 ↓
reverse proxy
 ↓
приложение

Очень часто проблема оказывается значительно ближе:

nginx
Apache
firewall
DNS
сертификат
Docker
маршрутизация

Если используется Nginx Proxy Manager, отдельно имеет смысл проверить:

Proxy Host
SSL Certificate
Forward Host
Forward Port
WebSocket Support

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

Безопасный удалённый доступ к своей инфраструктуре

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

Например, Raspberry Pi или Orange Pi можно использовать как узел защищённого удалённого доступа к:

• NAS;
• Home Assistant;
• камерам;
• Grafana;
• серверам;
• другим устройствам домашней сети.

Для этой задачи обычно используют стандартные защищённые сетевые технологии.

Если вы используете одноплатники для своих проектов, Raspberry Pi или Orange Pi могут стать удобной платформой для собственного VPN-сервера или локального DNS-резолвера.

Например, связка Pi-hole + Unbound полезна для собственного DNS и блокировки рекламы внутри домашней сети.

Для тех, кто хочет углубиться именно в тему удалённого доступа к собственной инфраструктуре, отдельно можно почитать про настройку WireGuard на одноплатнике — это удобный способ подключаться к домашней сети из поездки или публичного Wi-Fi.

А если используется Home Assistant, защищённый удалённый канал позволяет получить доступ к умному дому без необходимости публиковать каждый внутренний сервис напрямую в интернет.

Что в итоге

ТСПУ не стоит воспринимать как мистический «чёрный ящик».

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

Для обычного пользователя или системного администратора важнее другое: по одному ping, traceroute или неоткрывшемуся сайту практически невозможно достоверно установить конкретную причину сбоя.

Гораздо правильнее последовательно проверить:

DNS
TCP
TLS
HTTPS

и определить точку, на которой соединение перестало работать.

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

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