Deep Packet Inspection — технология анализа сетевого трафика, которая смотрит не только на заголовки пакетов (откуда, куда, какой порт), но и на содержимое. Изначально она создавалась для управления сетями: приоритизации трафика, борьбы с вирусами, учёта нагрузки. Те же методы применяются и для классификации протоколов.

Понимание механики полезно практически: становится ясно, почему одни протоколы распознаются мгновенно, а другие — нет.

Уровень 1: поиск сигнатур

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

Примеры того, что ищется:

  • HTTP-запрос начинается со слова GET, POST или HEAD;
  • TLS-рукопожатие начинается с байта 0x16, затем версия протокола;
  • пакет WireGuard — первый байт равен 1, длина ровно 148 байт;
  • OpenVPN содержит характерный код операции в первом байте.

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

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

Уровень 2: статистика потока

Если сигнатуры нет, анализируется поведение соединения. Полезная нагрузка при этом не расшифровывается — оценивается форма трафика.

Что учитывается:

  • распределение размеров пакетов — у видеопотока оно одно, у веб-сёрфинга другое, у туннеля третье;
  • соотношение входящего и исходящего — при просмотре сайтов входящий трафик многократно больше исходящего, у VPN пропорция ровнее;
  • тайминги — регулярные keepalive-пакеты через равные интервалы выдают постоянное соединение;
  • энтропия содержимого — зашифрованные данные выглядят случайными с первого байта, тогда как у настоящего HTTPS в начале идёт структурированное рукопожатие;
  • длительность сессии — обычные веб-соединения короткие, туннель держится часами.

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

Именно статистика со временем научилась выявлять Shadowsocks: поток с высокой энтропией с первого байта и без рукопожатия — уже сам по себе аномалия.

Уровень 3: активная проверка

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

Логика простая: если сервер утверждает, что он веб-сервер на 443 порту, к нему можно постучаться и посмотреть на ответ. Настоящий сайт вернёт корректное TLS-рукопожатие, сертификат и HTML-страницу. Прокси-сервер ответит иначе: разорвёт соединение, вернёт мусор или промолчит.

Такая проверка выявляет большинство самодельных схем маскировки, где сервер притворяется веб-сервером только для «своих».

Ответ на эту угрозу — проксирование посторонних соединений на настоящий сайт. Так устроены Reality и Fake TLS в MTProto: клиент без правильного секрета получает ответ реального ресурса, потому что сервер честно передаёт его соединение туда.

Уровень 4: машинное обучение

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

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

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

Что видно даже при идеальной маскировке

Ни один протокол не скрывает метаданные соединения:

  • IP-адрес назначения. Даже если содержимое неотличимо от HTTPS, факт соединения с конкретным адресом виден. Если на адрес приходят соединения от тысяч пользователей с многочасовыми сессиями — это заметно независимо от протокола.
  • Объём переданных данных.
  • Время начала и конца сессии.
  • DNS-запросы, если они идут в обход туннеля. Классическая утечка: трафик замаскирован идеально, а имя домена ушло открытым текстом на DNS-сервер провайдера.

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

Практические следствия

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

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

Работает на мобильном, не работает на домашнем интернете (или наоборот). Разные провайдеры используют разное оборудование и разные политики.

Работало, перестало после обновления. Обновились правила детектирования.

Коротко

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