Предисловие

Документ для тех, кто совсем не знает, что такое Vless, Xray и прочие штуки, связанные с «ВПН», но кому это нужно для планирования организации доступа через данные инструменты. Или если кому-то просто интересен принцип работы «на пальцах».

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

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

Термины и определения

TLS, SNI, Fingerprint

TLS – шифрование транспортного уровня (Transport Layer Security).

Что важно понимать про TLS:

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

Например, обычно браузер при подключении к веб-серверу передает SNI (Server Name Indication) – имя сервера, к которому браузер подключается, чтобы веб-сервер мог сразу подключить клиента к нужному сайту (если сайтов на сервере много) и далее начать общаться с клиентом с помощью сертификата на указанное имя.

Fingerprint –отпечаток, уникальные признаки того или иного приложения. Например по определенным признакам на начальном этапе подключения можно определить какой именно браузер используется и какой именно веб-сервер отвечает.

Актуальные версии TLS: 1.2 и 1.3. 1.3 лучше, быстрее и т.п, но потенциально могут блокировать\замедлять соединения по TLS. TLS 1.1 и 1.0 признаны устаревшими и не применяются.

Ядро

https://xtls.github.io/ru/

Ядром называется программа (исполняемый файл), который принимает конфигурацию и запускает прослушиватели (inbounds), производит обработку трафика (маршрутизацию, фильтрацию, балансировку) и последующий пересыл трафика на outbounds (точки выхода трафика)

Пример: Xray, Singbox, Clash

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

Минимальная конфигурация узла: 1 инбаунд + 1 аутбаунд.

Inbound:

Socks/http – обычные socks5/http прокси. В большинстве случаев используются для приема клиентского трафика в приложение на клиентском устройства

Dokodemo-door (tunnel)– инбаунд для мапинга портов с удаленного сервера или приема трафика, перенаправленного через nftables\iptables transparent proxy правила.

Vless – самый продвинутый на сегодняшний день протокол маскировки.

Так же поддерживаются Vmess, Trojan, Shadowsocks и Wireguard

Outbound:

               Те же Socks/http, Vless, Vmess, Trojan, Shadowsocks и Wireguard

Blackhole – аутбаунд для блокировки (если трафик необходимо заблокировать, то маршрутизацией он перенаправляется сюда.

Freedom – директ (использовать для подключения сеть сервера). Как и в другие инбаунды\аутбаунды можно указать доп настройки вроде исходящего IP, интерфейса, меток, и прочих fragment/noises.

DNS – в основном используется для маршрутизации перехваченных днс запросов, если такое используется.

Маршрутизация.

               https://xtls.github.io/ru/config/routing.html

Важно: если трафик не попал ни под одно из правил маршрутизации, он отправляется на первый по счет outbound, так что случае если доступ должен контролироваться, первым Outbound должен стоять blackhole.

Панель

Надстройка над ядром

Комбайн, который занимается управлением пользователями, генерацией ссылок и QR-кодов для подключения, управление нодами, раздает конфигурации на пользовательские устройства через специальные уникальные ссылки (подписки). GUI для ядра с кучей доп функционала и веб-интерфейсом управления.

Из самого интересного функционала панелей можно отметить возможность выдачи конфигурации в специальной формате с уже прописанной маршрутизацией для конечного (клиентского) ядра.  

Например, архитектурно возможно сделать автоматическую выдачу клиенту правил вида «весь трафик в РФ идёт напрямую минуя прокси, все dns запросы на ресурсы доменов РФ тоже идут напрямую через родной dns устройства».

Среди клиентских приложений есть 3 основных типа форматов конфигураций (самих клиентских приложений больше). Так что для выдачи маршрутизации с панели нужно поддерживать сразу 3 шаблона клиентских конфигураций

- v2ray. Формат json. Такие приложения как Happ, v2rayNG и другие с ядром v2ray

-clash. Формат yaml. Многочисленные виды клешей

-singbox. Формат json. Клиенты на ядре singbox

Более сложные конфигурации чем «РФ прямо» тоже возможны, зависит от потребностей.

Примеры: 3X-UI, Pasarguard, Remnawave

Клиент

Само ядро или надстройка над ядром (клиентское приложение)

Приложение, которое запускается на клиентском месте (телефон, пк, планшет, android tv и т.п).

Это может быть как голое ядро, так и готовые приложения, которые бывают как попроще с «импорт» и «включить» (например Happ, v2rayNG на андроид и другие), так и посложнее в первоначальной настройке (такие зачастую могут быть и сервером).

Клиентские приложения (далее клиенты) предлагают маршрутизацию. В некоторых случаях в клиентах возможен выбор приложений, которые пойдут в прокси, или наоборот не пойдут. В основном в клиентах возможно редактирование правил маршрутизации. Маршрутизация возможна по различным параметрам, в том числе доменное имя из сертификата подключения. С клиентами в комплекте обычно идет куча предустановленных списков (geosite:telegram, geoip:ru).

Способы получения конфигурации клиентским приложением:

• Готовый файл конфигурации в формате клиента (json или yml)

• Ссылка на веб-сервер панели, при заходе на которую клиент будет сам (упрощение) получать конфигурацию от панели.

• Ссылка вида {клиент}:// , которую можно пересылать например через телеграм, и при нажатии на такую ссылку телеграм открывает приложение (если оно установлено) и передает ему конфигурацию.

Автообновление клиента

Во-первых, зачастую важно иметь последнюю версию приложения т.к. вместе с приложением обновляется и ядро. А в ядре порой закрывают серьезные уязвимости, позволяющие детектировать даже Vless.

Во-вторых, при получении клиентом конфигурации в виде ссылки вида https://sub.example.com/a832nvasd32/sub/771418xaqjlan41 (ссылка обычно длиннее) клиент должен еще ее периодически обновлять. Частота обновления зависит от частоты внесения изменений в конфигурацию на сервере. Например, конфигурация может включать большое количество отдельных серверов (нод), некоторые из которых на крупных впн серверах могут периодически блокироваться по тем или иным причинам, и для получения нового списка серверов клиент должен обратиться на ту же самую ссылку еще раз. Для этого у клиентов предусмотрена функция автообновления. Причем она зачастую выключена по-умолчанию. И это настройка клиента, так что настраивается на клиенте. И клиенты порой даже поддерживают http header времени автообновления (панели его выдают), но сами при этом не автообновляются пока пользователь не включит функцию автообновления в настройках.

Например в Happ for Desktop (Windows) параметр автообновления подписки находится в Настройки->Подписки (раздел Дополнительные настройки.

Важной настройкой клиента является режим работы. Т.к. это все-таки прокси, а не роутинг, приложения имеют 2 режима работы:

• Proxy режим. Поднимается http и\или socks5 прокси на клиенте и в клиент прописывается настройка прокси сервера. Большинство клиентов умеют делать это автоматически.

• Tun режим (или VPN режим). В этом режиме тоже поднимается socks5 прокси на клиенте, но обычно оно не прописывается в настройке (хотя некоторые клиенты делают и это), а вместо этого создается tun интерфейс через специальное по, которое перенаправляет весь трафик на указанный сокс прокси. Важная техническая деталь: работают только tcp и udp. На icmp тун обычно просто отвечает сам (на все запросы просто прилетает reply в ttl <1c, даже если такого сервера не существует).

Прокси и VPN

Технически это не впн, это прокси. Даже в tun режиме ядро работает как приложение прокси сервера. С несколько дополненным набором критически важных протоколов это архитектурно обычный socks5\http прокси.

На момент написания статьи гугл ответил на запрос «что такое прокси» следующим образом

«Прокси — это промежуточный сервер, который действует как посредник между вашим устройством и интернетом. Он принимает ваш запрос, отправляет его на целевой сервер от своего имени, а затем передает ответ обратно вам.»

Принципиально отличие от VPN (Virtual Private Network) здесь заключается в том, что это не сеть и здесь нет маршрутизации и это порождает целую кучу бонусов, а еще целую сферу проблем. Две главные проблемы — это клиентские приложения, которые не умеют работать с прокси, и конкретно UDP трафик от них.

Современные клиентские приложения для xray предлагают помимо классического внесения изменений в настройки прокси системы (пусть и автоматического) специальный TUN интерфейс, в который заворачивается весь трафик клиента и далее проходит через ядро Xray. TUN интерфейс создается такими программами как Tun2Socks, Tun2Proxy или самими ядрами (например Singbox умеет создавать tun)

Реверс-прокси (обратный прокси)

Обратный прокси – сервис, который проксирует подключения «с другой стороны», т.е это сервис, устанавливающийся перед приложением (например перед серверным ядром xray) в интернете. обычно реверс-прокси занимается ssl терминацией и фильтрацией, и дальше пересылает на локальный порт на 127.0.0.1 или на unix-socket.

Два основных режима работы реверс-прокси:

• Реверс прокси слушает указанный порт (например 443) как HTTP (веб-сервер), обрабатывает http запросы и пересылает нужное на приложение в зависимости от настроек на реверс прокси

• Реверс прокси прослушивает указанный порт как TCP. И далее либо просто пересылает всё на один бэкенд без модификаций, либо анализирует SNI и на основе SNI пересылает подключения на указанный для данного SNI бэкенд.

Нюанс использования реверс прокси в режиме TCP:

В таком варианте конечное приложение получает клиентский IP не настоящий, а адрес реверс прокси (127.0.0.1, если трафик шел локально). Для обхода этой проблемы существует proxy_protocol. Это расширение, которое необходимо включить на передачу на реверс прокси и при этом так же включить на пример на принимающем приложении, т.к. этот режим не совместим с обычным режимом пересыла и требует одинаковой настройки как на реверс прокси, так и в приложении, на которое пересылают.

Примеры приложений реверс прокси: nginx, haproxy

Основы фильтрации

Фильтрация бывает разная и в разных местах. Начиная от клиентского устройства, на каждом узле интернета до сервера назначения, и на самом сервере назначения...

Но, нас в первую очередь интересует фильтрация на пограничных (между страной и внешним интернетом) узлах.

Модель OSI

https://ru.wikipedia.org/wiki/Сетевая_модель_OSI

Чем выше уровень, тем больше ресурсов потребляет фильтрация. Т.е. фильтровать на низком уровне дёшево, фильтровать на L7 очень дорого (кушает процессор).

Даже в случае если оператор не станет тратить свои ресурсы на скан на l7 всего вашего трафика, какие-то данные с этого уровня он будет знать в любом случае.

Даже если фильтрация идет на l3-l5, а не идет полное сканирование вашего трафика..

Пример.

Вы открываете сайт https://www.rbc.ru в браузере Chrome.

Что видит оператор (и собственно все узлы вплоть до веб-сервера rbc.ru):

123.45.67.89:63152 -> 178.248.234.119:443 https://www.rbc.ru, Chrome(с версией относительной точности), Nginx (наверно у rbc нгинкс), страну источника, страну назначения, количество данных туда\обратно и прочую не супер важную для данной статьи информацию

На самом деле соединений сильно больше, но для простоты рассмотрим главное из них.

123.45.67.89 это ваш условный ВНЕШНИЙ ip. т.е не из 172.16.0.0/12,192.168.0.0/16,10.0.0.0/8, если они не выданы такие провайдером, да и даже так дальше провайдера будет виден внешний IP.

178.248.234.119 это соответственно ip адрес сервера, на который ссылается dns имя www.rbc.ru

https://www.rbc.ru Chrome(клиентское приложение) и Nginx(серверное приложение) - это то что сканер может узнать из первых нескольких пакетов. И это даже не ретроспективная информация в логах, это элемент правил доступа.

https://www.rbc.ru - именно так. не https://www.rbc.ru/politics/ и т.п, а именно https://www.rbc.ru. SNI. чтобы видеть куда именно вы ходили и что там на веб-сервере делали, это уже перепаковка трафика.

Клиентское и серверное приложение соответственно определяется по фингерпринту.

Всю эту информацию ваш оператор видит в любом случае.

Access List

Это список правил (может быть фильтрации на фаерволе, правила доступа в приложении и т.п.).

Пример базового абстрактного access list

destination 10.0.0.0/8 drop # запрещаем всем ходить на 10.0.0.0/8

source 192.168.0.0/16 allow # разрешаем все из 192.168.0.0/16

destination site.loc port 443 allow # разрешаем всем ходить на site.loc

Важное:

Правила применяются сверху вниз. Соответственно в данном примере трафик из

192.168.0.0/16 разрешается куда угодно кроме 10.0.0.0/8, т.к. правила для дропа выше чем разрешающее правило для 192.168.0.0/16.

На site.loc можно ходить всем и отовсюду, но только если site.loc не в сети 10.0.0.0/8 т.к. самым первым правилом у нас идет дроп трафика в ту сторону.

Access List везде. Какие бы мудрено и сложно ни выглядел гуй или даже конфигурационный файл того или иного списка доступа, в конце он все равно формируется в логический access list, вложенный, возможно со своими особенностями применения, но по сути это access list со своими общими нюансами.

Вы хотите быть вверху access list, в самом верхнем allow как только можно.

Усложним пример.

destination 10.0.0.0/8 drop

source 192.168.0.0/16 allow

destination site.loc port 443 browser amigo allow

Теперь в нижнем правиле отовсюду можно ходить на site.loc только браузером amigo, а из сети 192.168.0.0/16 можно ходить чем угодно, но тоже только если site.loc не в сети 10.0.0.0/8

Фильтрация многоуровнева. И фильтруется помимо access list доступа как такового, еще много чего и в политиках фильтрации приложений.

 Представим дополнительную политику l7 фильтра для сети из примера.

destination site.loc port 443 browser amigo filterpolicy internal

source 192.168.0.0/16 browser amigo filterpolicy light

source 192.168.0.0/16 filterpolicy strict

«Логические направления фильтрации»

Под таким непонятным названием скрывается краткое описание основных направлений фильтрации вашего трафика со стороны оборудования.

Черный список

Фильтрующее оборудование фильтрует по списку явно запрещенное.

Из-за особенностей работы современных фаерволов фильтровать даже не включая на полную l7 фильтрацию для всех подключений можно не только по адресам, но и по SNI и фингерпринтам клиента\сервера.

Общая фильтрация обычно идет в самом начале access list.

IP и порт адрес и назначения видно всегда. Остальная информация может быть не видна, если оборудование не в курсе что это такое там вообще летит (не смогло определить).

Один из подходов к обходам блокировок - маскировка трафика чтобы как раз было не понятно что это за трафик. Но тут есть нюанс: фильтр должен пропускать непонятное, а не фильтровать непонятное.

Самый скрытный способ обхода блокировок архитектурно это все равно не "прикидываться непонятно чем", а "прикидываться тем что можно".

Потому как прохождение даже черного списка возможно только при условии что он настроен логически на «неизвестное можно».

Белый список

Фильтрующее оборудование разрешает по списку явно разрешенного.

Список того что явно можно.

Что важно понимать про белый список, так это что такое Default rule.

В ситуации когда мобильный оператор включает «белые списки сайтов» и на мобильном телефоне работает только то что должно работать, это белый список сайтов с отбрасыванием по-умолчанию всего остального (Default rule drop).

Если мы представим идеальные условия, где белый список настроен правильно, то архитектурно единственный способ обойти ограничения это иметь сервер в белом списке. Ну вот так. (например прятать вход иксрей за легитимным сервисом, который еще и как-то надо пропихнуть в белый список…)

Если мы не будем представлять идеальные условия, то много где белые списки могут быть настроены не совсем правильно (не успели\не смогли) и потенциально могут работать Reality например за счет того что у оператора белый список настроен только по SNI, а не по SNI + сеть того чей это собственно SNI.

Рассчитывать что такой SNI будет долго и надежно работать смысла мало. Может и будет, а может и наоборот сервер грохнут довольно быстро за обходы таких вот фильтров.

 

Самым перспективным на сегодняшний день способом борьбы с фильтрацией является прикидываться тем чего в принципе больше всего - https. причем легитимным https. т.е. https на какой-то сайт не из черного списка и https, который выглядит максимально обычно.

Посему самым продвинутым (это не значит единственным рабочим) способом является VLESS.

VLESS

Основной на сегодняшний день протокол.

«Сервер VLESS» это сервер, на котором поднято ядро и настроен inbound типа VLESS

Вот что пишет википедия:

VLESS (VMess Less) — это лёгкий, stateless транспортный протокол, разработанный в рамках проекта V2Ray и его форка Xray. Он предназначен для проксирования интернет-трафика и обхода цензуры, обеспечивая гибкую интеграцию с внешними методами шифрования, такими как TLS или XTLS

Общий принцип работы:

• Inbound слушает на внешнем порту или за реверс-прокси в режиме TCP:

Inbound принимает входящие соединения, определяет трафик ли это от xray клиента или нет, и далее если это не трафик xray, такие соединения передаются на dest – маскировочный веб-сервер.

 

• Реверс прокси слушает на внешнем порту в режиме HTTP:

Реверс прокси принимает входящее соединение, делает ssl терминацию и работает как обычный веб-сайт, но по определенному пути /somepath пересылает трафик на внутренний порт с VLESS

 

Актуальные реализации:

Способов настройки довольно немало, вот главные на сегодняшний день

VLESS Reality. В таком режиме VLESS использует SNI другого домена (обычно внешнего сайта) таким образом что в начале соединения (client hello) клиент устанавливает соединение с внешним сайтом (точнее это сервер иксрей инициирует соединение со своей стороны) и соответственно по косвенным признакам клиент подключается к этому самому внешнему сайту. Т.е. xray не просто пересылает неизвестных на dest, он использует dest при установке любого подключения (даже если пришел впн клиент). Главный минус – накладные расходы по латенси (при каждой установке соединения добавляется латенси между сервером xray и маскировочным сервером). Reality можно настроить на локальный веб-сервер (self-steal), тогда накладных расходов на латенси нет + при заходе через браузер на сервер xray сайт открывается с валидным сертификатом.

Важное о Reality: реалити поменяет вам адрес сервера назначения, например вы можете сделать так чтобы при подключении к вашему впну в логах.

Но реалити НЕ поменяет IP назначения. IP будет вашего сервера. И как бы хорош VLESS ни был, верификация сертификата в подключении это отличный способ борьбы с не selfsteal Reality. Только дорого наверно в каждом подключении в интернете сертификаты верифицировать.

Selfsteal – это вариант реалити, когда веб-сервер для маскировки стоит там же где и впн, и соответственно ip в днс для адреса SNI совпадает с IP сервера, следовательно сертификат валидный.

VLESS xHTTP. https://habr.com/ru/articles/913324/

Главный бонус - http3, умеет еще много чего, в том числе и иметь разные сервера для uplink\downlink.

В чем Vless преуспел?

Это протокол. Он преуспел в том чтобы ваш tcp/udp до ваших сайтиков при прохождении между инбаундом клиента иксрей и инбаундом сервера иксрей выглядели как обычный https://domain1.com (где domain1.com это ваш сервер маскировки) между Chrome (фигнерпринт клиента настраивается) и каким-нибудь нгинксом.

В чем Vless НЕ преуспел?

В том в чем он и не мог:

Vless не преуспел в выборе сервера как такового.

Сервер это скорее всего VPS какого-то хостинга. Хостинг может быть либо сам по себе заблокирован маской, либо может быть под жесткой фильтрацией. Может вообще до вас там убили сервер за vpn и ip в черном списке все еще.

Vless не преуспел в выборе сайта для маскировки за вас.

Комьюнити идет на встречу новичкам (порой) и даже есть рекомендуемые sni. Так сказать народные. Чтобы не пришлось долго объяснять как выбрать, просто то что работает.

Чего зачастую не понимают многие новички и порой дажен не очень новички, это тот факт что Vless не только не выбирает SNI за вас, но еще и то что это в целом довольно важный выбор.

И это далеко не только пинг.

Вот например вы не хотите долго думать и берете "народный" sni. И он у вас поработал.

И далее ситуация выдуманная, но далеко не невозможная. Призванная дать примерное представление о том как это работает, человеку с этим не знакомому, а не предостеречь от использования таких SNI.

В руки специалиста занимающегося фильтрацией попадает информация о сервере ВПН. Не вашем.

Просто вот сервер, какой-нибудь школьник настроил себе впн с автопродажей через телеграм, и каким-то образом это вылилось в проблемы, но т.к. он школотрон, все чем это закончилось этоп приказом разобраться с тем что там было.

А там была куча трафика. В момент когда впн работал туда шел трафик с https://easysni.domain (пример именно народного sni).

И человек попался ответственный, да к тому же немного умеющий пользоваться фильтром в логах. И вот он берет и делает запрос вида "трафика больше чем Х гб, назначение https://easysni.domain, сеть назначения не равно Y", где Y это сеть где живет easysni.domain на самом деле (можно в целом и ip посмотреть).

Что этот запрос выдает? Это выгрузка впнов. Его так в целом в бан можно скриптом выгружать. Но это история, как я уже сказал, выдуманная.

"Как это работает для тех кто не понимает как это работает". И большинству это к счастью не принципиально.

Домашний пользователь ну перенастроит себе сервер, или купит новый айпи.

Реселлер впнов наверное вообще систему развертывания имеет на такие случаи подготовленную.

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

Vless не преуспел в настройке себя за вас.

Причем это не про формирование конфигурации, а в целом про параметры inbound как такового.

Самый главный пункт, по которому ваш впн можно отфильтровать из общей массы трафика это порт.

Vless маскируется под HTTPS, а HTTPS это 443.

Если мы возьмем выгрузку пользовательского трафика. Легитимного. Без впн. То АБСОЛЮТНОЕ большинство HTTPS будет на 443. И даже из тех кто там глядит на нас из дальней дали графика со своими 1-2%, это будут скорее всего 8443 и еще какой-нибудь 8080 может быть.

Соответственно, если вы настраиваете сервер например на 3000 порту, и в логах виден трафик из сети мобильных клиентов в сеть хостинга в Нидерландах на порт 3000 и это https на yandex.ru, то уже даже не важно что у вас Яндекс, который почему-то хостится в Нидерландах, в глаза вы бросаетесь одним только портом.

И это не означает что такая конфигурация не будет работать на момент настройки, она может и долго проработает. Но грамотно настроенный Vless всегда на 443 порту.

Vless не преуспел в настройке роутинга за вас.

Клиентское приложение не должно роутить вообще всё через сервер.

Во-первых есть локальные ресурсы, которым полезно было бы работать даже с включенным впн

Во-вторых, что более важно, когда в��сь трафик роутится через впн,в логах оператора видно что от вас было много трафика на один единственный порт на сервере в условных Нидерландах. Как бы идеально VLESS не прикидывался легитимным HTTPS, по одному факту того что у вас все идет туда сразу понятно что это впн.

Роутить домашний регион (внутренний периметр страны) в direct на клиенте во многих случаях это довольно полезно.

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