{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Блог Петра Дондукова: заметки с тегом IT", "_rss_description": "Блог айтишника, активиста и волонтёра из Бурятии.", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/blog.kinsei.top\/tags\/it\/", "feed_url": "https:\/\/blog.kinsei.top\/tags\/it\/json\/", "icon": "https:\/\/blog.kinsei.top\/pictures\/userpic\/userpic@2x.jpg?1766651165", "authors": [ { "name": "Пётр Дондуков", "url": "https:\/\/blog.kinsei.top\/", "avatar": "https:\/\/blog.kinsei.top\/pictures\/userpic\/userpic@2x.jpg?1766651165" } ], "items": [ { "id": "6", "url": "https:\/\/blog.kinsei.top\/all\/fuck-rkn\/", "title": "Анализ ситуации с блокировками и методы обхода", "content_html": "
\n\"\"\n<\/div>\n

По ситуации с доступностью протокола VLESS в России хотелось бы дать развернутый комментарий. Благодарю подписчиков и пользователей некоммерческого проекта VPN Baikal<\/a> за помощь в тестировании различных конфигураций серверов и клиентов.<\/p>\n

Как показали тесты, полной блокировки сигнатур самого протокола VLESS на данный момент не наблюдается. Протокол достаточно сложен для анализа системами DPI (Deep Packet Inspection), что подтверждается его успешной работой в условиях жесткой цензуры в Китае и Иране. То, с чем мы столкнулись — это не блокировка протокола как такового, а эвристический анализ поведения трафика. Системы фильтрации выявляют и разрывают (дропают) соединения, если их количество к одному серверу и порту превышает определенный лимит (rate limiting). В стандартной конфигурации браузеры могут открывать десятки параллельных сессий, но VPN-клиенты могут генерировать их тысячи, что и становится триггером для блокировки.<\/p>\n

Решение 1: VLESS TCP + Reality с мультиплексированием (Mux)<\/h2>\n

Для классической связки VLESS TCP + Reality эффективным решением является включение опции Mux (мультиплексирование) на стороне клиента. Это позволяет упаковывать множество запросов в одно или несколько TCP-соединений, что «успокаивает» системы анализа трафика. При этом на стороне сервера необходимо отключить XTLS-Vision.<\/p>\n

Техническое пояснение: Технология XTLS-Vision предназначена для минимизации задержек при рукопожатии (handshake) и улучшения маскировки TLS-отпечатков под обычный браузерный трафик, однако она архитектурно требует соотношения «один запрос — одна TCP-сессия». Поскольку Mux объединяет множество потоков в один, эти технологии несовместимы. Отключение Vision в данном случае безопасно и компенсируется механизмами протокола Reality.<\/p>\n

Рекомендуемые настройки Mux:<\/b> 4 сессии для TCP и 8 для UDP.
\nТакже критически важно грамотно подобрать SNI (домен для маскировки). Лучший вариант — поднять собственный безобидный сайт и маскироваться под него, либо использовать SNI ресурса, который хостится в том же дата-центре или подсети, что и ваш сервер, ну или хотя-бы в одном городе или регионе. Использование популярных публичных SNI рискованно не столько из-за провайдеров, сколько из-за самих сервисов, которые могут разрывать соединения при массовой проверке сертификатов.<\/p>\n

Решение 2: Переход на транспортные протоколы xHTTP или gRPC.<\/h2>\n

Еще более эффективный метод — смена транспортного уровня с TCP на xHTTP или gRPC. Эти протоколы работают поверх TCP\/UDP (уровень L7 модели OSI), но изначально спроектированы с поддержкой мультиплексирования, используя одно или малое количество постоянных соединений.<\/p>\n

С точки зрения противодействия блокировкам РКН, xHTTP сейчас предпочтительнее. Протокол gRPC генерирует больше служебного трафика (overhead), что может снижать скорость на мобильных сетях. xHTTP лишен этих недостатков. В связке с Reality и добавлением «мусорного» трафика (Padding в диапазоне 10—50 байт) отличить сигнатуры xHTTP от легитимного веб-серфинга крайне сложно.<\/p>\n

Ситуация с «белыми списками»<\/h2>\n

Текущие веерные блокировки на мобильных операторах в ряде регионов РФ связаны с внедрением так называемых «белых списков» (allowlists). В этом режиме блокируется всё, что явно не разрешено. Некоторые VPN-сервисы пытаются обходить это, используя серверы и\/или CDN отечественных облачных провайдеров (Yandex Cloud, VK Cloud, Edge Center), которые находятся в белых списках. Однако это временное решение: хостинг-провайдеры уже начали блокировать такие аккаунты. В условиях тотальных белых списков классические методы обфускации могут не сработать, и придется прибегать к инкапсуляции в разрешенные протоколы (например, DNS-туннелирование), хотя и эти лазейки могут быть закрыты.<\/p>\n

Планы развития VPN Baikal<\/a><\/h2>\n

Сейчас я тестирую новые методы обфускации трафика для работы в условиях жестких ограничений. Кроме того, для удобства пользователей сервис переводится на систему подписок. Вам больше не придется вручную менять ключи доступа — достаточно будет нажать кнопку «Обновить подписку» в приложении. Это стандарт для коммерческих сервисов, но поскольку мой проект некоммерческий и весь бюджет уходит на оплату инфраструктуры, внедрение таких фич требует свободного времени. Я планирую переход на систему подписок в районе Новогодних праздников.<\/p>\n

За сим откланиваюсь, всем удачи!<\/p>\n

Ещё больше постов в моём телеграм-блоге<\/a><\/p>\n", "date_published": "2025-12-07T05:13:46-08:00", "date_modified": "2025-12-25T23:45:11-08:00", "tags": [ "IT", "VPN" ], "image": "https:\/\/blog.kinsei.top\/pictures\/rkn-glavny-s.jpg", "_date_published_rfc2822": "Sun, 07 Dec 2025 05:13:46 -0800", "_rss_guid_is_permalink": "false", "_rss_guid": "6", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.kinsei.top\/pictures\/rkn-glavny-s.jpg" ] } } ], "_e2_version": 4171, "_e2_ua_string": "Aegea 11.4 (v4171)" }