Как измерять блокировку правильно
Прежде чем что-то чинить, надо уметь измерить. С ограничениями трафика это сложнее, чем кажется: большинство доступных инструментов измеряет не ту величину, по которой сеть в действительности ломается. Отсюда типичная картина: инструмент показывает зелёный статус, пользователи жалуются, и обе стороны правы.
Разберём четыре требования, без которых измерение не даёт ответа.
Требование первое: объём#
Ключевой принцип формулируется одной фразой: проба измеряет ту величину, по которой ломается сеть.
Если ограничение считает килобайты, проба обязана их передать. Проверка, отправляющая полтора килобайта при пороге в шестнадцать, не измеряет ничего относящегося к делу — она измеряет установку соединения.
Практический минимум: не менее 256 килобайт, то есть на порядок выше известного порога. Запас нужен, потому что порог наблюдался разными людьми в диапазоне, а не как точное число.
Записывать нужно не время, а на каком байте поток встал. Это единственная величина, различающая объёмное ограничение и обычную медленную сеть.
Требование второе: последовательность#
Второе требование неочевидно и потому нарушается чаще всего.
Проба, открывающая много соединений одновременно, сама создаёт условие, при котором срабатывает ограничение параллелизма. Она измеряет собственный эффект и получает отказ, который сама же и вызвала.
Это не теоретическая тонкость: массовое обновление списка серверов в клиентах — ровно такой веер, и он объясняет часть ложных отметок «недоступен».
Правило: пробы идут последовательно, с паузой между ними. Медленнее, зато результат относится к сети, а не к пробе.
Требование третье: классификация типа отказа#
«Не работает» — не результат измерения. Результат — какой именно тип отказа наблюдался, потому что от типа зависит контрмера.
Минимальный набор различимых классов:
| Класс | Признак | На что указывает |
|---|---|---|
| Нет ответа на SYN | таймаут установки | ограничение по адресу |
| Разрыв после рукопожатия | RST после ClientHello | инъекция разрыва |
| Остановка после N килобайт | байты шли, потом тишина без разрыва | объёмное ограничение |
| Занижена полоса, соединение живо | всё работает, но медленно | ограничение полосы |
| Таймаут во время рукопожатия | нет ответа после ClientHello | ограничение по имени |
| Расхождение системного DNS и DoH | разные адреса | подмена разрешения имён |
| Соединение принято, данных нет | порт открыт, ответ пуст | приём и отбрасывание на входе |
Различать первые две строки существенно: отсутствие ответа на SYN и отказ в соединении — разные диагнозы. Второй обычно означает, что сервис не слушает, то есть это не цензура, а конфигурация.
Готового открытого инструмента, дающего такую классификацию, на сегодня нет — сообщество обсуждало необходимость, но реализация остаётся за теми, кому она нужна.
Требование четвёртое: точка наблюдения#
Самое дорогое требование и самое часто игнорируемое.
Механизмы ограничения работают в конкретных сетях. Измерение из другой сети доказывает корректность сервера, но не пригодность сервиса. Успешная проба из зарубежного дата-центра ничего не говорит о том, что увидит пользователь на домашнем провайдере в целевом регионе.
Отсюда неудобное следствие: одна точка наблюдения даёт наблюдение, но не приёмку. Для вывода нужны несколько независимых операторов — потому что, как разбиралось отдельно, фильтрация распределена и различается между сетями.
Если независимых точек меньше нужного, честный результат — «наблюдение с ограничением», а не «работает». Разница в формулировке, но она предотвращает выводы, которые потом придётся отзывать.
Разбор: одна проба, четыре разных вывода#
Один и тот же отказ, записанный четырьмя способами. Сравните, что каждый позволяет сделать дальше.
ЗАПИСЬ 1 — вердикт
"не работает"
→ следующий шаг: неизвестен
ЗАПИСЬ 2 — вердикт со временем
"не работает, 15.2 с"
→ следующий шаг: неизвестен, но видно, что это таймаут
ЗАПИСЬ 3 — с этапами
dns 15мс · tcp 41мс · tls 380мс · первый байт 402мс · таймаут
→ уже видно: соединение и рукопожатие ПРОШЛИ, ломается позже
ЗАПИСЬ 4 — с объёмом
dns 15мс · tcp 41мс · tls 380мс · первый байт 402мс
получено 16 384 Б · встало на 16 384 · разрыва нет · 15.2 с
→ объёмное ограничение, класс определён, контрмера известна
Все четыре записи описывают одно и то же событие. Первые две не позволяют действовать вообще; третья сужает область; и только четвёртая называет причину.
Разница в стоимости сбора — нулевая: эти величины доступны в момент пробы. Разница в ценности — решающая.
Числовой пример: сколько повторов нужно#
Ограничения вероятностны, и единичное наблюдение мало о чём говорит. Простая арифметика.
| Повторов | Успехов | Что можно утверждать |
|---|---|---|
| 1 | 0 | ничего — совпадение неотличимо от закономерности |
| 1 | 1 | ничего — то же самое |
| 5 | 0 | вероятно ограничение, но выборка мала |
| 20 | 0 | ограничение, если контроль напрямую проходит |
| 20 | 12 | частичное — интереснее, чем полный отказ |
Последняя строка часто оказывается самой информативной: 60% успеха — это не «работает» и не «не работает», а признак вероятностного механизма или зависимости от условий, которые различаются между попытками.
Вердикт «прошло / не прошло» такую картину уничтожает целиком.
Три способа обмануть себя#
Единичная успешная проба. Ограничения носят характер временных состояний и вероятностны. Один успех не отличается от совпадения. Повторов нужно достаточно, чтобы говорить о доле, а не о факте.
Проба без контроля. Наблюдение «через VPN не работает» без параллельного «напрямую тоже не работает» не отделяет ограничение канала от недоступности самого ресурса.
Смешение симптома и причины. «Медленно» может быть ограничением полосы, объёмным ограничением на медленной фазе, перегрузкой узла или проблемой у ресурса. Без записи байтов и времени по этапам различить невозможно.
Что записывать#
Для каждой пробы полезно сохранять вектор, а не вердикт:
время DNS
время установки TCP
время рукопожатия TLS
время до первого байта
байт получено
байт, на котором поток встал
общее время
класс отказа
Вердикт «прошло / не прошло» выбрасывает всё, что позволяет отличить одну причину от другой. Через неделю по нему нельзя восстановить, что наблюдалось.
Зачем сравнивать доменное имя с адресом?#
Дешёвый и недооценённый приём — прогнать одну и ту же пробу дважды: по доменному имени и по адресу напрямую.
| По имени | По адресу | Вывод |
|---|---|---|
| отказ | успех | проблема в разрешении имён на стороне сервера |
| отказ | отказ | причина не в именах |
| успех | отказ | ожидаемо: вход отбрасывает соединения с адресом вместо имени |
Третья строка объясняет, почему простые проверки доступности показывают живыми мёртвые хосты — и почему её стоит знать заранее, чтобы не принять за находку.
Вывод#
Измерение блокировки — не «попробовать и посмотреть». Это четыре требования, каждое из которых при нарушении даёт правдоподобный, но неверный ответ:
достаточный объём, иначе не видно объёмных ограничений; последовательность, иначе проба измеряет себя; классификация типа, иначе результат не подсказывает действие; точка наблюдения в целевой сети, иначе результат относится не к тем условиям.
Инструмент, нарушающий любое из них, не бесполезен — он опасен, потому что даёт уверенность без основания.
Термины#
- Контрольное измерение - параллельная проба по заведомо не ограничиваемому маршруту, выполняемая в тех же условиях.
- Серийность - повторение измерения несколько раз подряд, отделяющее устойчивый отказ от случайного.
- Классификация отказа - отнесение неудачи к конкретному типу вместо общей отметки «не сработало».
FAQ: частые вопросы#
Сколько повторов достаточно?#
Не менее трёх. Одно измерение не отличает отказ от флуктуации, а два не позволяют увидеть, какой из результатов выпадает.
Зачем нужно контрольное измерение?#
Без него провал допускает два объяснения: не работает маршрут или не работает сеть. Контроль отделяет одно от другого.
Что записывать вместе с результатом?#
Время, сеть, оператора, версию клиента и переданный объём. Без этих условий результат нельзя сравнить с будущим.
Что читать дальше#
- Проверка показывает timeout, а VPN работает
- Тихие отказы: когда отвергает сервер
- Три оси формы трафика
- Пройдите маршрут от настройки до диагностики в VPN-гайдах GigaTap.
- Выберите следующий шаг с помощью помощника VPN start.
- Импорт профиля под конкретное устройство — в хабе настройки клиентов.