<?xml version="1.0" encoding="utf-8"?> 
<rss version="2.0"
  xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
  xmlns:atom="http://www.w3.org/2005/Atom">

<channel>

<title>Блог Петра Дондукова: заметки с тегом VPN</title>
<link>https://blog.kinsei.top/tags/vpn/</link>
<description>Блог айтишника, активиста и волонтёра из Бурятии.</description>
<author></author>
<language>ru</language>
<generator>Aegea 11.4 (v4171)</generator>

<itunes:subtitle>Блог айтишника, активиста и волонтёра из Бурятии.</itunes:subtitle>
<itunes:image href="" />
<itunes:explicit></itunes:explicit>

<item>
<title>Анализ ситуации с блокировками и методы обхода</title>
<guid isPermaLink="false">6</guid>
<link>https://blog.kinsei.top/all/fuck-rkn/</link>
<pubDate>Sun, 07 Dec 2025 05:13:46 -0800</pubDate>
<author></author>
<comments>https://blog.kinsei.top/all/fuck-rkn/</comments>
<description>
&lt;div class="e2-text-picture"&gt;
&lt;img src="https://blog.kinsei.top/pictures/rkn-glavny-s.jpg" width="600" height="454" alt="" /&gt;
&lt;/div&gt;
&lt;p&gt;По ситуации с доступностью протокола VLESS в России хотелось бы дать развернутый комментарий. Благодарю подписчиков и пользователей некоммерческого проекта &lt;a href="https://t.me/vpnbaikal_bot"&gt;VPN Baikal&lt;/a&gt; за помощь в тестировании различных конфигураций серверов и клиентов.&lt;/p&gt;
&lt;p&gt;Как показали тесты, полной блокировки сигнатур самого протокола VLESS на данный момент не наблюдается. Протокол достаточно сложен для анализа системами DPI (Deep Packet Inspection), что подтверждается его успешной работой в условиях жесткой цензуры в Китае и Иране. То, с чем мы столкнулись — это не блокировка протокола как такового, а эвристический анализ поведения трафика. Системы фильтрации выявляют и разрывают (дропают) соединения, если их количество к одному серверу и порту превышает определенный лимит (rate limiting). В стандартной конфигурации браузеры могут открывать десятки параллельных сессий, но VPN-клиенты могут генерировать их тысячи, что и становится триггером для блокировки.&lt;/p&gt;
&lt;h2&gt;Решение 1: VLESS TCP + Reality с мультиплексированием (Mux)&lt;/h2&gt;
&lt;p&gt;Для классической связки VLESS TCP + Reality эффективным решением является включение опции Mux (мультиплексирование) на стороне клиента. Это позволяет упаковывать множество запросов в одно или несколько TCP-соединений, что «успокаивает» системы анализа трафика. При этом на стороне сервера необходимо отключить XTLS-Vision.&lt;/p&gt;
&lt;p&gt;Техническое пояснение: Технология XTLS-Vision предназначена для минимизации задержек при рукопожатии (handshake) и улучшения маскировки TLS-отпечатков под обычный браузерный трафик, однако она архитектурно требует соотношения «один запрос — одна TCP-сессия». Поскольку Mux объединяет множество потоков в один, эти технологии несовместимы. Отключение Vision в данном случае безопасно и компенсируется механизмами протокола Reality.&lt;/p&gt;
&lt;p&gt;&lt;b&gt;Рекомендуемые настройки Mux:&lt;/b&gt; 4 сессии для TCP и 8 для UDP.&lt;br /&gt;
Также критически важно грамотно подобрать SNI (домен для маскировки). Лучший вариант — поднять собственный безобидный сайт и маскироваться под него, либо использовать SNI ресурса, который хостится в том же дата-центре или подсети, что и ваш сервер, ну или хотя-бы в одном городе или регионе. Использование популярных публичных SNI рискованно не столько из-за провайдеров, сколько из-за самих сервисов, которые могут разрывать соединения при массовой проверке сертификатов.&lt;/p&gt;
&lt;h2&gt;Решение 2: Переход на транспортные протоколы xHTTP или gRPC.&lt;/h2&gt;
&lt;p&gt;Еще более эффективный метод — смена транспортного уровня с TCP на xHTTP или gRPC. Эти протоколы работают поверх TCP/UDP (уровень L7 модели OSI), но изначально спроектированы с поддержкой мультиплексирования, используя одно или малое количество постоянных соединений.&lt;/p&gt;
&lt;p&gt;С точки зрения противодействия блокировкам РКН, xHTTP сейчас предпочтительнее. Протокол gRPC генерирует больше служебного трафика (overhead), что может снижать скорость на мобильных сетях. xHTTP лишен этих недостатков. В связке с Reality и добавлением «мусорного» трафика (Padding в диапазоне 10—50 байт) отличить сигнатуры xHTTP от легитимного веб-серфинга крайне сложно.﻿&lt;/p&gt;
&lt;h2&gt;Ситуация с «белыми списками»&lt;/h2&gt;
&lt;p&gt;Текущие веерные блокировки на мобильных операторах в ряде регионов РФ связаны с внедрением так называемых «белых списков» (allowlists). В этом режиме блокируется всё, что явно не разрешено. Некоторые VPN-сервисы пытаются обходить это, используя серверы и/или CDN отечественных облачных провайдеров (Yandex Cloud, VK Cloud, Edge Center), которые находятся в белых списках. Однако это временное решение: хостинг-провайдеры уже начали блокировать такие аккаунты. В условиях тотальных белых списков классические методы обфускации могут не сработать, и придется прибегать к инкапсуляции в разрешенные протоколы (например, DNS-туннелирование), хотя и эти лазейки могут быть закрыты.&lt;/p&gt;
&lt;h2&gt;Планы развития &lt;a href="https://t.me/vpnbaikal_bot"&gt;VPN Baikal&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Сейчас я тестирую новые методы обфускации трафика для работы в условиях жестких ограничений. Кроме того, для удобства пользователей сервис переводится на систему подписок. Вам больше не придется вручную менять ключи доступа — достаточно будет нажать кнопку «Обновить подписку» в приложении. Это стандарт для коммерческих сервисов, но поскольку мой проект некоммерческий и весь бюджет уходит на оплату инфраструктуры, внедрение таких фич требует свободного времени. Я планирую переход на систему подписок в районе Новогодних праздников.&lt;/p&gt;
&lt;p&gt;За сим откланиваюсь, всем удачи!&lt;/p&gt;
&lt;p&gt;Ещё больше постов в &lt;a href="https://t.me/kinseigo"&gt;моём телеграм-блоге&lt;/a&gt;&lt;/p&gt;
</description>
</item>


</channel>
</rss>