НЕ РАБОТАЕТ В РФ _

Методология_

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

01 / Архитектура

Система состоит из трёх независимых слоёв сбора данных. Каждый слой покрывает отдельный класс сетевых ограничений и работает автономно — выход одного компонента из строя не влияет на остальные.

VPS Зонды
Go-бинарь на Linux VPS

Серверы в разных регионах РФ. Запускают полный стек проверок: DNS, TCP, TLS с timing-анализом, HTTP GET. Работают под systemd, опрашивают API каждые 10 секунд.

Browser Probe
5-векторный JS-движок

Проверка прямо из браузера пользователя — zero-WASM, чистый JS. 5 векторов: DoH DNS, Fetch (no-cors), Image Probe, WebSocket Timing, Resource Timing API. Детектирует ТСПУ RST по таймингу соединения.

GeoIP Intelligence
Server-side, Privacy-first

Серверный GeoIP-резолвинг. IP пользователя никогда не возвращается клиенту и не сохраняется. Определяет город, провайдера и VPN-флаг. Иммунен к блокировщикам рекламы.

02 / Конвейер VPS-зондов

Каждый VPS-зонд последовательно выполняет 4 этапа. При провале на любом этапе метод блокировки уже определён.

1.
DNS Resolution

Запрос через системный резолвер + Google (8.8.8.8) и Яндекс (77.88.8.8). Расхождение = DNS_POISON.

2.
TCP Connect :443

TCP-соединение с портом 443. Нет SYN-ACK = IP_BLOCK.

3.
TLS Handshake + Timing

ClientHello с SNI → замер RST timing. RST < 5ms при TCP > 10ms = DPI_RST (ТСПУ). SHA256 cert fingerprint для MITM-детекции.

4.
HTTP GET + Block Page Detection

HTTP GET → сигнатуры заглушек РКН (eais.rkn.gov.ru, warning.rt.ru). При совпадении = HTTP_REDIRECT.

02.1 / Browser Probe (5-векторный)

Проверка запускается прямо из браузера пользователя. Все 5 векторов работают параллельно. Не требует WASM, плагинов или расширений — чистый JavaScript и Web APIs.

1.
DoH DNS (Google + Cloudflare)

DNS-резолвинг через DNS-over-HTTPS. Обходит DNS poisoning оператора. Возвращает реальные IP-адреса домена.

2.
Fetch (no-cors)

HTTP-запрос в режиме no-cors. Opaque response = TLS-хэндшейк прошёл. Ошибка за <15ms = RST-инъекция ТСПУ.

3.
Image Probe (Favicon)

Загрузка /favicon.ico через new Image(). Проверяет и TCP/TLS, и передачу данных. Ошибка за <15ms = RST, ошибка за >3s = throttle.

4.
WebSocket Timing

Попытка WSS-соединения. Ключевой вектор: ошибка быстрее baseline RTT = TCP RST от middlebox. Ошибка в ~2x baseline = нормальное отклонение сервером.

5.
Resource Timing API

Разбивка соединения по фазам: DNS lookup, TCP connect, TLS handshake. Позволяет определить, на каком именно этапе происходит блокировка.

Калибровка (Baseline RTT)

Перед запуском проверки система измеряет baseline RTT до Google и Яндекса (3 замера, берётся минимум). Это позволяет отличить реальную блокировку от медленного интернета. RST threshold = max(baseline × 0.5, 15ms).

03 / Классификация блокировок

КодМетодУровеньОписание
DNS_POISONDNS-перехватL7 / DNSОператор подменяет или блокирует DNS-ответы для целевого домена через свой резолвер. Обходится сменой DNS на 8.8.8.8 / DoH.
IP_BLOCKIP-блокировкаL3 / IPТрафик блокируется на уровне IP-адреса или подсети. TCP SYN не получает SYN-ACK. Жёсткая блокировка, обход только через VPN/прокси.
DPI_RSTТСПУ / DPI ResetL4-L7 / TLSОборудование ТСПУ инспектирует SNI в TLS ClientHello и отправляет поддельный TCP RST. Характерный признак: RST приходит за 1–3 мс при RTT 20+ мс.
DPI_DROPDPI DropL4-L7 / TLSTLS handshake зависает без ответа (таймаут). ТСПУ молча сбрасывает пакеты вместо отправки RST. Более скрытный вариант DPI.
HTTP_REDIRECTЗаглушкаL7 / HTTPTLS работает, но HTTP-ответ содержит редирект на страницу-заглушку РКН или оператора. Обнаруживается по сигнатурам в теле ответа.
THROTTLEЗамедление ТСПУL4-L7 / TLSTLS-хэндшейк проходит, но передача данных нарушена. WSS >3x baseline + Fetch >2x baseline. Характерно для SNI-throttling на ТСПУ.
NONEНет ограниченийВсе этапы проверки пройдены. Ресурс доступен с данной точки наблюдения.

04 / AI-анализ

После сбора телеметрии со всех зондов данные агрегируются и передаются в YandexGPT (модель yandexgpt-5-lite). Модель получает структурированный отчёт: метод блокировки, тайминги, статусы по каждому зонду — и формирует краткий технический вердикт.

Что передаётся в модель
  • Код блокировки (DNS_POISON / DPI_RST / IP_BLOCK / HTTP_REDIRECT / NONE)
  • Результат DNS через системный и внешние резолверы
  • TCP connect: успех/провал + латентность в мс
  • TLS handshake: статус + ошибка + timing RST
  • Признак middlebox (RST < 5 мс при TCP > 10 мс)
  • HTTP: статус-код, наличие заглушки, URL редиректа
  • Локация зонда (город/регион)
Что НЕ передаётся
  • Имя проверяемого домена (модель анализирует паттерн, а не репутацию)
  • Содержимое HTTP-ответа (только хеш первых 2 КБ)
  • Персональные данные пользователей

Вердикт кешируется: если статус домена не изменился с прошлого цикла, повторный вызов YandexGPT не производится. Это экономит ресурсы и снижает задержку.

05 / Ограничения и честная оценка

Покрытие

Зонды расположены в ограниченном числе регионов. Блокировки могут различаться между операторами в одном городе. Система не претендует на абсолютную полноту данных.

Browser Probe

Браузерные проверки ограничены Web APIs: нет raw TCP/DNS, только fetch/image/WSS. Сайты без favicon.ico дают неполные данные. VPN может искажать результаты.

AI-вердикты

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

Приватность

IP-адреса хешируются SHA256 перед записью. GeoIP определяется серверно — IP не возвращается клиенту. Телеметрия не содержит персональных данных.

06 / Правовая позиция

Система работает в режиме пассивного мониторинга. Зонды выполняют стандартные сетевые операции (DNS-запросы, TCP-соединения, TLS handshake, HTTP GET) — аналогичные тем, что выполняет любой веб-браузер при открытии сайта.

Не используются: сканирование портов, перехват трафика, эксплуатация уязвимостей, обход средств защиты. Система не нарушает Ст. 272–274 УК РФ, Ст. 13.11 КоАП РФ. Аналогичную методологию (без активного сканирования) применяют проекты OONI, Censored Planet и RIPE Atlas.

Связь с проектом

Обсуждение, баг-репорты, предложения по расширению сети зондов.

Telegram-канал