- PVSM.RU - https://www.pvsm.ru -
VPN обычно обсуждают через шифрование: клиент устанавливает защищенное соединение с сервером, данные передаются внутри туннеля, а промежуточный наблюдатель не получает их содержимое в открытом виде. Из этого легко сделать вывод, что зашифрованный VPN‑трафик невозможно распознать. Однако шифрование содержимого и сокрытие характеристик соединения — разные задачи.
Система фильтрации может не знать, что именно передает пользователь, но при этом наблюдать, как выглядит само соединение: куда оно установлено, какой транспорт использует, как начинается обмен, какие размеры имеют пакеты, с какими интервалами они передаются и как ведет себя поток во времени.
Этого иногда достаточно, чтобы классифицировать трафик без расшифровки его содержимого. Разберемся, какие данные остаются наблюдаемыми, что в этом контексте означает fingerprint, зачем применяется active probing и почему VLESS, XHTTP и REALITY корректнее рассматривать как компоненты разных уровней архитектуры, а не как три альтернативных «VPN‑протокола».
Рассмотрим обычное VPN‑соединение. Клиент устанавливает защищенный канал с VPN‑сервером, внутри которого передаются пользовательские данные. Промежуточный наблюдатель не должен получать их в открытом виде.
Однако наблюдатель находится снаружи туннеля. Поэтому в зависимости от используемой технологии и своего положения в сети он может иметь доступ к некоторым характеристикам соединения:
IP‑адресу назначения;
порту и транспорту;
особенностям установления соединения;
размерам пакетов и их распределению;
интервалам между пакетами;
продолжительности соединения;
направлениям передачи;
поведению потока во времени.
Отсюда следует принципиальное различие: Прочитать содержимое трафика и классифицировать соединение — не одна и та же задача. На этом различии основана значительная часть методов анализа зашифрованного сетевого трафика.
Далеко не каждая блокировка требует глубокого анализа. Самый очевидный вариант — IP‑фильтрация: если известен адрес сервера, используемого VPN‑провайдером, доступ к нему можно ограничить независимо от того, насколько хорошо защищен туннель. Другой вариант — фильтрация определенных портов или транспортов.
Условно методы можно расположить от простых признаков к более сложному анализу:
IP / subnet
↓
port / transport
↓
protocol characteristics
↓
traffic behavior
↓
active interaction with endpoint
Чем ниже мы спускаемся по этой схеме, тем меньше классификация зависит от одного простого признака. И здесь появляется DPI.
Deep Packet Inspection — не одна конкретная программа и не один алгоритм. Это класс технологий анализа сетевого трафика. Возможности конкретных систем различаются, поэтому утверждение «DPI определяет VPN вот таким способом» почти всегда будет чрезмерным упрощением.
Система классификации может учитывать комбинацию сигналов:
destination
+
transport
+
handshake characteristics
+
packet sizes
+
timings
+
flow behavior
↓
classification
При этом наличие слова Packet в DPI не означает, что системе обязательно требуется прочитать пользовательское содержимое пакетов. Для классификации зашифрованного соединения могут использоваться доступные метаданные и статистические характеристики потока. Иными словами, шифрование скрывает содержимое, но само по себе не превращает передачу данных в поток без наблюдаемых свойств.
Разные сетевые протоколы и реализации могут по‑разному устанавливать соединение и передавать данные. В результате возникает совокупность признаков, которую можно использовать при классификации.
Упрощенная аналогия — автомобиль в темноте. Необязательно видеть водителя или содержимое салона, чтобы предположить тип объекта: иногда достаточно силуэта, размеров, скорости и характера движения. С трафиком похожая ситуация — содержимое пакетов может быть недоступно, но наблюдателю могут оставаться доступны их размеры, последовательность, интервалы и направления передачи.
Один такой параметр обычно ничего не доказывает. Но комбинация признаков, повторяющаяся на множестве соединений, уже может быть полезным сигналом. Поэтому в данном контексте fingerprint правильнее рассматривать не как одну фиксированную сигнатуру, а как профиль наблюдаемых свойств соединения. В конкретной системе для его анализа могут использоваться правила, статистические модели, эвристики, машинное обучение или комбинация подходов.
WireGuard, OpenVPN и IKEv2/IPsec прежде всего решают задачу построения защищенного сетевого соединения. Их основная инженерная задача — построить защищенное сетевое соединение. Это не недостаток: в сети без специальной фильтрации такой дизайн может давать отличное сочетание безопасности, производительности, надежности и простоты эксплуатации.
Проблема появляется, когда меняется модель угроз. Теперь от соединения хотят одновременно двух вещей:
надежно защищать передаваемые данные;
усложнять классификацию самого соединения как определенного типа VPN‑трафика.
Это разные инженерные задачи. Поэтому вопрос «какой VPN‑протокол лучше?» без описания сетевых условий не особенно содержателен. Если сеть не пытается обнаруживать VPN, дополнительная работа с внешним профилем соединения может вообще не требоваться. Если пытается — наблюдаемые характеристики становятся частью модели угроз.
Распространено предположение, что использование TCP/443 автоматически делает VPN‑соединение похожим на обычный HTTPS‑трафик. Однако номер порта — только один из параметров соединения. Два потока могут использовать TCP/443 и при этом различаться особенностями установления соединения и дальнейшего обмена данными. Для более сложного классификатора значение могут иметь handshake, транспортное поведение и последующий профиль потока.
Обфускация не делает криптографию «сильнее» — у нее другая задача. Если шифрование прежде всего защищает содержимое, то обфускационные механизмы работают с наблюдаемым профилем соединения, пытаясь сделать его менее характерным для определенных методов классификации.
Но здесь особенно важно избегать абсолютных утверждений. Менее характерный не означает необнаружимый. Нет технических оснований обещать, что конкретный стек невозможно определить или заблокировать: системы классификации меняются, появляются новые эвристики, IP‑адрес можно заблокировать независимо от транспортного профиля, а разные операторы используют разные политики. Поэтому корректнее говорить об усложнении классификации определенными методами и при определенных условиях.
До сих пор мы предполагали, что система только наблюдает соединение реального пользователя. Но возможна другая модель — active probing.
|
Этап |
Кто подключается |
Что происходит |
|---|---|---|
|
Обычное соединение |
Пользователь → Сервер |
Система наблюдения замечает потенциально интересную конечную точку |
|
Active probing |
Система наблюдения → Сервер |
Система самостоятельно инициирует новое соединение и анализирует ответ сервера |
Система может обнаружить потенциально интересное соединение, определить конечную точку и затем самостоятельно обратиться к ней. Ответ сервера становится дополнительным сигналом для классификации. При active probing важен уже не только профиль соединения настоящего клиента, но и то, как сервер ведет себя при постороннем подключении. Поэтому устойчивость к сетевой фильтрации может зависеть как от характеристик пользовательского потока, так и от поведения серверной стороны.
В пользовательском интерфейсе удобно написать Protocol: X, но реальное соединение может состоять из нескольких компонентов, выполняющих разные функции: протокольного уровня, транспорта, transport security и серверной инфраструктуры.
Поэтому выражение «антиблокировочный протокол» иногда скрывает гораздо более интересную архитектуру. Хороший пример — комбинация VLESS + XHTTP + REALITY.
Названия часто перечисляют рядом: VLESS + XHTTP + REALITY. Из‑за этого может возникнуть впечатление, что речь идет о трех последовательно вложенных VPN‑протоколах. Это не так. Для понимания архитектуры удобнее разделить их роли.
VLESS [1] относится к протокольному уровню экосистемы Xray и задает взаимодействие между клиентской и серверной сторонами. Но слово VLESS само по себе еще не описывает всю архитектуру соединения: транспорт и transport security задаются отдельно.
XHTTP [2] относится к транспортному уровню Xray. Упрощенно его роль можно описать так: VLESS определяет протокольное взаимодействие, а XHTTP — способ передачи данных этого уровня между сторонами соединения. Разделение важно, поскольку транспорт влияет на наблюдаемое поведение соединения после его установления.
REALITY [3] выполняет другую функцию и относится к уровню transport security. В контексте рассматриваемой архитектуры достаточно отметить, что этот уровень защищает транспортное соединение и влияет на его внешний TLS‑профиль.
То есть REALITY — не «еще один VLESS» и не альтернатива XHTTP. Поэтому более содержательно описывать такую конфигурацию как VLESS с транспортом XHTTP и transport security REALITY, а не как «VPN на трех протоколах».
Разделение архитектуры на уровни позволяет понять происхождение наблюдаемых характеристик соединения. Внешний наблюдатель получает итоговый сетевой профиль, на который в разной степени влияют протокол, транспорт, transport security и инфраструктура.
|
Уровень |
Роль |
|---|---|
|
Protocol |
логика взаимодействия сторон |
|
Transport |
способ передачи данных |
|
Transport security |
защита транспортного соединения и его внешний security‑контекст |
|
Infrastructure |
адресация, серверная среда и доступность конечной точки |
После такого разделения проще понимать и DPI, и fingerprints, и active probing, и смысл многоуровневых архитектур вроде VLESS + XHTTP + REALITY. Это не означает, что каждый компонент автоматически «обходит DPI». Смысл архитектурного подхода в другом: вместо предположения, что один VPN‑протокол должен одновременно решать все задачи, разные аспекты соединения рассматриваются отдельно.
Поэтому бинарное деление VPN‑технологий на «блокируемые» и «неблокируемые» плохо описывает реальную ситуацию. Устойчивость соединения зависит не только от выбранного протокола, но и от транспорта, наблюдаемого сетевого профиля, инфраструктуры, методов классификации и возможностей конкретной системы фильтрации.
Нет оснований обещать это технически. Даже если конкретный сетевой профиль трудно классифицировать по известной сигнатуре, остаются другие способы воздействия:
можно заблокировать IP‑адрес;
можно изменить правила фильтрации;
можно использовать другие признаки или комбинацию сигналов;
можно активно исследовать конечные точки;
оператор может ограничить целый класс трафика, если готов принять сопутствующие блокировки легитимных соединений.
Кроме того, это динамическая система: появляются новые способы передачи трафика, системы фильтрации наблюдают их, появляются новые методы классификации, после чего меняются и способы построения соединений.
Поэтому «неблокируемый VPN» — плохая инженерная категория. Гораздо полезнее оценивать, к каким методам классификации и ограничения устойчиво конкретное соединение, при какой модели наблюдателя и какой ценой. На этот вопрос уже можно пытаться отвечать экспериментально.
Основную мысль статьи можно представить как две независимые оси:
трудно классифицировать
↑
|
|
слабое шифрование --------+-------- сильное шифрование
|
|
↓
легко классифицировать
Сильное шифрование не гарантирует верхнюю половину диаграммы. Соединение может надежно защищать содержимое и при этом иметь достаточно характерный внешний профиль. И наоборот, попытка сделать сетевое взаимодействие менее характерным не заменяет нормальную криптографическую защиту.
Поэтому при обсуждении VPN и устойчивости к фильтрации полезно задавать два отдельных вопроса:
Насколько хорошо защищено содержимое?
Что остается доступным внешнему наблюдателю для классификации соединения?
После такого разделения проще понимать и DPI, и fingerprints, и active probing, и смысл многоуровневых архитектур вроде VLESS + XHTTP + REALITY. Более подробно практические способы блокировки VPN и архитектуру устойчивых соединений мы разбирали в материале «Почему VPN блокируют и как работают устойчивые соединения [4]».
Этот материал посвящен прежде всего модели наблюдения за зашифрованным трафиком, а не сравнению конкретных VPN‑решений. На практике результат зависит от сочетания протокола, транспорта, параметров соединения, серверной инфраструктуры и возможностей системы фильтрации. Поэтому отдельные технологии корректнее оценивать не по обещанию «невидимости», а по тому, какие наблюдаемые признаки они меняют и в каких условиях это имеет значение.
Автор: mr_tom
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/vpn/456724
Ссылки в тексте:
[1] VLESS: https://github.com/XTLS/Xray-core/tree/main/proxy/vless
[2] XHTTP: https://github.com/XTLS/Xray-core/discussions/4113#discussioncomment-11468947
[3] REALITY: https://github.com/XTLS/REALITY
[4] Почему VPN блокируют и как работают устойчивые соединения: https://altairvpn.com/ru/blog/pochemu-vpn-ne-rabotaet-blokirovka-protokolov
[5] Источник: https://habr.com/ru/articles/1071252/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1071252
Нажмите здесь для печати.