regsc
Проверен
24.07.26
5
Проверенный
0
Всем привет! Раз тут раздел про гайды и IT — разберу техническую сторону того, как сейчас устроена борьба VPN vs DPI, без воды.
Как DPI вообще детектит VPN
DPI не видит содержимое зашифрованного трафика — только форму хендшейка: домен назначения, сертификат, поведение сессии. Обычный VPN (WireGuard/OpenVPN поверх своего TLS) выдаёт себя именно формой: домен не совпадает ни с чем известным, сертификат самоподписанный или только что выпущен, паттерн трафика характерный для туннеля. Этого достаточно для блокировки по паттерну, без анализа контента — самый дешёвый способ для DPI резать VPN массово.
Как Reality это обходит
VLESS + XTLS Reality вместо своего сертификата использует хендшейк настоящего популярного сайта — домен, сертификат, поведение сессии полностью совпадают с обычным заходом на этот сайт. Ключ для настоящего туннеля проверяется уже после этого внешне обычного хендшейка. Снаружи — неотличимо от реального HTTPS к этому сайту.
— Fingerprint клиента важен: chrome в некоторых версиях ловит DPI-блокировку из-за post-quantum расширения в ClientHello, которого настоящие браузеры ещё массово не шлют. firefox стабильнее
— У Reality жёсткий лимит ~8192 байт на TLS Certificate record сайта-прикрытия — если сертификат разрастётся при ротации у самого сайта, хендшейк массово ломается у всех клиентов разом
— Резервный протокол на UDP (Hysteria2) нужен на случай, если именно TCP-путь где-то заблокируют
Умный роутинг — отдельная тема
Если делать сплит-роутинг (локальные сайты — напрямую, остальное — через VPN), не стоит завязываться на geoip-базы на устройстве клиента — часть приложений просто падает на таком правиле. Надёжнее — явные routing.rules прямо в шаблоне конфига, который получает клиент.
Собрали всё это на практике в своём сервисе (
Как DPI вообще детектит VPN
DPI не видит содержимое зашифрованного трафика — только форму хендшейка: домен назначения, сертификат, поведение сессии. Обычный VPN (WireGuard/OpenVPN поверх своего TLS) выдаёт себя именно формой: домен не совпадает ни с чем известным, сертификат самоподписанный или только что выпущен, паттерн трафика характерный для туннеля. Этого достаточно для блокировки по паттерну, без анализа контента — самый дешёвый способ для DPI резать VPN массово.
Как Reality это обходит
VLESS + XTLS Reality вместо своего сертификата использует хендшейк настоящего популярного сайта — домен, сертификат, поведение сессии полностью совпадают с обычным заходом на этот сайт. Ключ для настоящего туннеля проверяется уже после этого внешне обычного хендшейка. Снаружи — неотличимо от реального HTTPS к этому сайту.
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки или изображения.
Практические грабли (на реальном опыте):— Fingerprint клиента важен: chrome в некоторых версиях ловит DPI-блокировку из-за post-quantum расширения в ClientHello, которого настоящие браузеры ещё массово не шлют. firefox стабильнее
— У Reality жёсткий лимит ~8192 байт на TLS Certificate record сайта-прикрытия — если сертификат разрастётся при ротации у самого сайта, хендшейк массово ломается у всех клиентов разом
— Резервный протокол на UDP (Hysteria2) нужен на случай, если именно TCP-путь где-то заблокируют
Умный роутинг — отдельная тема
Если делать сплит-роутинг (локальные сайты — напрямую, остальное — через VPN), не стоит завязываться на geoip-базы на устройстве клиента — часть приложений просто падает на таком правиле. Надёжнее — явные routing.rules прямо в шаблоне конфига, который получает клиент.
Собрали всё это на практике в своём сервисе (
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки или изображения.
, VPN-бот в Telegram) — если кому-то интересны детали конкретных решений или грабли, которые не поместились сюда — спрашивайте в теме, отвечу.
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки или изображения.