TSPU Checker: как я написал инструмент для диагностики блокировок

Идея этого проекта появилась после попыток разобраться, почему на одних провайдерах VPN работает нормально, а на других соединение либо режется, либо просто зависает без каких-либо ошибок. Обычные проверки через ping почти ничего не показывали: ICMP проходил, а TCP уже мог отваливаться.

В какой‑то момент стало понятно, что нужен простой инструмент, который можно быстро запустить на сервере, в WSL или даже в Termux и за пару минут понять, где именно проблема — DNS, TCP, TLS или уже HTTP.

Так появился TSPU Checker — bash-скрипт для диагностики блокировок и анализа работы ТСПУ в российских сетях. Скрипт умеет проверять доступность портов, определять признаки SNI-фильтрации, сравнивать DNS-ответы и искать типичные симптомы DPI.

Код выложен на GitHub под MIT-лицензией, чтобы любой мог спокойно дорабатывать его под свои задачи.

Почему вообще пришлось писать свой инструмент

Начиная примерно с 2025 года у российских операторов всё чаще начали появляться признаки работы по модели allowlist — когда разрешён доступ только к определённым IP-адресам, а остальной трафик либо дропается, либо начинает вести себя нестабильно.

На практике это выглядело странно я подключаюсь к VPN, но трафик не идёт, ping до сервера проходит, а TCP — нет. При этом DNS отвечает нормально, но TLS-соединение внезапно зависает. Некоторые облачные сервера начинали частично отваливаться. Иногда было непонятно, где именно ломается соединение.

Я читал о нескольких существующих решениях вроде OONI Probe и rkn-block-checker, но для повседневной диагностики они показались мне либо слишком тяжёлыми, либо не очень удобными. Хотелось чего-то максимально простого: запустил скрипт и через 30 секунд понял, что именно режет провайдер. Так и появился TSPU Checker.

Архитектура и подход

Скрипт написан на bash. Сначала была мысль делать всё на Python, но потом стало понятно, что я его не знаю от слова совсем:). В консоли он не требует много ресурсов значит можно запустить даже на минимальном VPS сервере. Получается, что для сетевой диагностики стандартных инструментов более чем достаточно.

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

Чтобы скрип легко было запустить на большинстве машин с Linux я решил использовать стандартные утилиты такие как ping, nc, curl, openssl, dig, hping3, nmap. Вся идея скрипта заключается в том, чтобы последовательно проверить несколько сетевых уровней и понять, где начинается проблема.

 К примеру:

а.        ICMP помогает понять, жив ли вообще сервер;

б.       TCP показывает, режется ли подключение;

в.       TLS позволяет увидеть признаки SNI-фильтрации;

г.        HTTP помогает обнаружить заглушки;

д.       сравнение DNS и DoH показывает возможную подмену ответов.

Не знаю достаточно ли умеет мой скрипт

========================================     ТСПУ Диагностический инструмент                  v1.0                      ======================================== Текущий целевой сервер: 192.168.1.1Выберите действие:  0)   Сменить IP сервера (сейчас: 192.168.1.1)  1)   Определить режим ТСПУ  2)   Проверить активность ТСПУ (curl)  3)   Проверить доступность портов (TCP)  4)   Проверить SNI-фильтрацию (L7)  5)   Проверить UDP-порты  6)   Проверить внешние DNS  7)   Запустить веб-сервер на 443  8)   Полная проверка сервера  9)   Детальный анализ портов  10)  Определить ваш IP  11)  Расширенная диагностика блокировок  12)  Проверить Split DNS/утечку  q)  ВыходВаш выбор: 

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

Скрипт идёт по этапам:

• Проверяет DNS;

• Пытается открыть TCP-соединение;

• Делает TLS handshake;

• Проверяет HTTP-ответ.

Я думаю, что такой подход помогает довольно быстро локализовать проблему. Когда, например DNS отвечает нормально, но TCP не подключается или же TCP есть, но TLS зависает. А иногда вообще TLS проходит, но HTTP возвращает заглушку.

Пример:

=======================================     ТСПУ Диагностический инструмент                  v1.0                      ======================================== Текущий целевой сервер: 192.168.1.1[11] Расширенная диагностика блокировок (4 слоя)--- Белый список (контрольная группа) ---Проверка: Яндекс (ya.ru)  DNS системный: OK → 5.255.255.242  DNS DoH (1.1.1.1): OK → 77.88.44.242  TCP порт 443: ОТКРЫТ--- Чёрный список (заблокированные ресурсы) ---Проверка: Twitter (twitter.com)  DNS системный: OK → 172.66.0.227  DNS DoH (1.1.1.1): OK → 162.159.140.229  TCP порт 443: ОТКРЫТ  TLS Handshake: УСПЕШНОНажмите Enter для продолжения...

Если внимательно изучить полученную информацию становится видно, где именно начинает вмешиваться DPI.

В процессе тестирования я заметил несколько странных случаев, когда TLS-соединение работало только при определённом SNI. Тогда я и задумался об этой проверки. Я подумал, что скрип бы мог устанавливать TLS-соединение с разными доменами и показывает результат.

Пример:

========================================     ТСПУ Диагностический инструмент                  v4.2                      ======================================== Текущий целевой сервер: 192.168.1.1[4] Проверка SNI-фильтрации на L7... Тестовый IP (Яндекс): 77.88.55.242  SNI: ya.ru (Яндекс): ПРОПУЩЕН ✓  SNI: google.com (Google): ПРОПУЩЕН ✓  SNI: twitter.com (Twitter): НЕТ ОТВЕТА  SNI: youtube.com (YouTube): ПРОПУЩЕН ✓  SNI: vk.com (VK): ПРОПУЩЕН ✓Нажмите Enter для продолжения...

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

Для тестирования VPN необходимо было проверить, какой IP видят разные сервисы и не утекает ли реальный адрес мимо туннеля.

========================================     ТСПУ Диагностический инструмент                  v1.0                      ========================================Текущий целевой сервер: 192.168.1.1[12]  Проверить Split DNS/утечку WebRTC ВНИМАНИЕ: Запустите этот тест ПРИ ВКЛЮЧЁННОМ VPNНажмите Enter если VPN включён, или 'q' для выхода: [Проверка, какой IP видят сайты]:  ya.ru видит IP: 77.88.44.242  ifconfig.me видит IP: 144.31.198.40 Анализ:   Split DNS/туннелирование РАБОТАЕТНажмите Enter для продолжения...

Сначала хотел добавить полноценную WebRTC-проверку, но для bash это оказалось уже слишком неудобно.

Что получилось на практике

 Тест VPS внутри РФ

Для тестов мною использовался обычный VPS. Результаты были примерно такие:

В моём случае сервер отвечал нормально и признаков блокировки не было.

 Проверка через мобильного оператора

А вот мобильная сеть показала уже более интересное поведение. Наблюдалась такая картина:

То есть ping ещё проходил, а нормальное TCP-соединение уже не устанавливалось.

С DNS тоже было интересно: часть внешних резолверов просто переставала отвечать.

Установка и запуск

На Linux / WSL

# Установка зависимостейsudo apt updatesudo apt install -y hping3 nmap netcat-openbsd openssl dnsutils curl# Скачать скриптwget -O tspu_check.sh https://raw.githubusercontent.com/ku78/tspu-checker/refs/heads/main/tspu_check.sh# Запускchmod +x tspu_checker.shsudo ./tspu_checker.sh

На Android (Termux)

pkg update && pkg install -y openssl-tool netcat-openbsd curl tsu nano# Далее — скопировать скрипт в файл и запустить

На Windows (PowerShell)

Полноценная работа возможна только через WSL. Упрощённая версия на PowerShell доступна в репозитории.

Планы на развитие

• Добавить проверку ECH (Encrypted Client Hello)

• Реализовать бенчмарки скорости для разных протоколов

Ссылки и благодарности

• Ссылка на GitHub

• Вдохновение: статья zarazaexe «Всё, что вам надо знать о белых списках: как устроены и 6 способов обхода»  

• Идеи диагностики: проект rkn-block-checker от MayersScott

TSPU Checker изначально делался как небольшой вспомогательный скрипт «для себя», чтобы не разбираться каждый раз вручную, почему очередной VPN внезапно перестал работать.

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

• ломается ли DNS

• режется ли TCP

• есть ли признаки SNI-фильтрации

• подменяются ли ответы

• работает ли туннелирование

Понятно, что это не полноценная система анализа DPI, но для быстрой диагностики скрипта обычно хватает.

ПС: это моя первая статья, жду хейта по максимуму.