Как работает глубокая инспекция пакетов

Что видит сеть на уровне адресов и портов

Самая простая форма разбора трафика работает на третьем и четвёртом уровнях модели OSI. На L3 устройство читает IP-заголовок: адрес отправителя, адрес получателя, значение TTL, флаги фрагментации. На L4 добавляются номера портов TCP или UDP, флаги SYN, ACK, RST и размер окна.

Этой информации достаточно, чтобы построить правило вида «трафик к сети 198.51.100.0/24 на порт 443 не пропускать». Обработка требует минимума ресурсов: заголовок IPv4 занимает 20 байт, решение принимается по таблице за единицы наносекунд. Маршрутизаторы делают это аппаратно, на скорости линка.

Ограничение подхода очевидно с распространением облачных платформ. Один IP-адрес CDN обслуживает тысячи доменов, а порт 443 несёт и банковский интерфейс, и видеохостинг, и почтовый клиент. Правило по адресу и порту либо задевает лишнее, либо не задевает ничего.

Седьмой уровень: разбор содержимого соединения

Глубокая инспекция начинается там, где устройство собирает поток из отдельных пакетов и интерпретирует прикладной протокол. Для незашифрованного HTTP это заголовок Host, метод запроса и путь. Для DNS — имя в секции вопроса. Для FTP, SMTP, SIP — свои поля.

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

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

Пассивное зеркалирование и устройства в разрыв

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

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

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

TLS ClientHello и поле SNI

Более 95% веб-трафика идёт по HTTPS, где содержимое зашифровано. Однако первый пакет рукопожатия — ClientHello — передаётся открытым текстом, потому что стороны ещё не договорились о ключах. В нём указывается версия протокола, список поддерживаемых шифронаборов, набор расширений и, что важнее всего для анализа, поле server_name, оно же SNI.

SNI содержит имя хоста, к которому обращается клиент. Изначально расширение появилось в RFC 3546 в 2003 году ради виртуального хостинга: один IP-адрес, много сайтов, серверу нужно понять, какой сертификат отдавать. Побочный эффект — любое устройство на пути видит имя запрашиваемого ресурса, не расшифровывая ни байта полезной нагрузки.

Ответом стали механизмы сокрытия этого поля. Черновик ESNI 2018 года шифровал только имя, ECH из TLS 1.3 шифрует весь внутренний ClientHello целиком, оставляя снаружи имя-обёртку. Развёртывание ECH требует публикации ключей в DNS-записи HTTPS и поддержки на стороне и клиента, и сервера, поэтому охват пока частичный.

Сертификаты, размеры пакетов и тайминги

До TLS 1.3 сертификат сервера передавался открыто, и поле subjectAltName служило вторым источником имён после SNI. В TLS 1.3 сертификат зашифрован, поэтому этот канал наблюдения закрылся для новых соединений, но остаётся актуальным для устаревших клиентов и внутренних систем.

Когда содержимое недоступно, анализ переходит к статистике. Полезны распределение размеров пакетов, соотношение исходящего и входящего объёма, длительность пауз, регулярность служебных сообщений. Видеопоток даёт характерные пачки по 1,2–1,4 КБ с паузами в несколько секунд; интерактивный туннель — россыпь мелких пакетов по 60–200 байт с равномерным интервалом; загрузка файла — непрерывную последовательность пакетов размером в MTU.

Такая классификация вероятностная. Она хорошо отделяет крупные классы трафика друг от друга, но ошибается на пограничных случаях: видеозвонок и игровой трафик статистически похожи, а туннель внутри туннеля выглядит как обычная передача файла. Практическая точность моделей на реальных смесях трафика редко превышает 85–92%.

Отпечатки JA3 и JA4

Разные реализации TLS формируют ClientHello по-разному. Порядок шифронаборов, набор расширений, поддерживаемые эллиптические кривые, форматы точек — всё это зависит от библиотеки и её версии. Методика JA3, опубликованная в 2017 году, собирает эти значения в строку и берёт от неё MD5-хеш.

Полученный отпечаток характеризует не пользователя, а стек. Chrome определённой версии на Windows даёт один хеш, Firefox — другой, стандартная библиотека Go — третий. Если приложение заявляет себя браузером, а его отпечаток совпадает с сигнатурой языковой библиотеки, несоответствие видно сразу.

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

Активное зондирование

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

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

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

Пропускная способность и правило fail-open

Оборудование глубокой инспекции всегда работает в условиях дефицита ресурсов. Стойка операторского класса обрабатывает порядка 100–400 Гбит/с, а магистраль крупного региона в пиковые часы легко даёт больше. Поэтому нагрузка распределяется между узлами, а часть трафика по заранее заданным правилам проходит без разбора: например, потоки от известных крупных источников или сессии сверх лимита таблицы состояний.

Инлайновое устройство обязано быть спроектировано с расчётом на отказ. Режим fail-open означает, что при сбое питания, зависании или переполнении буферов аппаратный байпас замыкает канал напрямую, и трафик идёт мимо анализатора. Альтернатива fail-closed допустима в корпоративном контуре, но неприемлема на магистрали: она превратила бы поломку одного устройства в отключение целого региона.

Отсюда наблюдаемое пользователями непостоянство. В час пик, при аварии на узле или при резком росте числа сессий поведение сети меняется: то, что утром обрабатывалось одним образом, вечером обрабатывается иначе. Это не признак настройки под конкретного абонента, а следствие того, что любая система разбора трафика имеет конечную ёмкость.