OpenVPN через VLESS или Shadowsocks представляет собой составное сетевое соединение, в котором VPN-туннель передаётся через дополнительный прокси-канал. OpenVPN отвечает за собственный VPN-сеанс, а VLESS или Shadowsocks обеспечивает промежуточную доставку соединения до VPN-сервера.
Такую архитектуру применяют, когда необходимо сохранить существующую инфраструктуру OpenVPN, но изменить способ подключения к ней.
Устройство соединения
В варианте с локальным SOCKS5-прокси последовательность следующая:
На устройстве работает клиент VLESS или Shadowsocks.
Клиент предоставляет локальный SOCKS5-интерфейс.
OpenVPN подключается к этому интерфейсу.
Прокси-клиент передаёт соединение своему удалённому серверу.
Удалённый прокси устанавливает соединение с сервером OpenVPN.
Сервер OpenVPN обрабатывает VPN-сеанс и предоставляет предусмотренный настройками доступ.
OpenVPN поддерживает подключение через SOCKS5 с помощью параметра socks-proxy. Поэтому ему не обязательно самостоятельно реализовывать VLESS или Shadowsocks: взаимодействие происходит через промежуточный интерфейс.
Роль Shadowsocks
Shadowsocks состоит из локальной и удалённой частей. Локальная часть принимает соединения приложений, шифрует передаваемые данные и отправляет их серверу. Сервер снимает шифрование Shadowsocks и пересылает содержимое указанному получателю.
Если внутри передаётся OpenVPN, снятие внешнего шифрования Shadowsocks не расшифровывает сам VPN-сеанс. Сервер Shadowsocks получает поток OpenVPN и направляет его дальше.
Протокол Shadowsocks предусматривает передачу TCP и UDP. Однако наличие поддержки UDP в протоколе не означает, что любой набор клиентов и промежуточных интерфейсов сможет передавать его без дополнительных условий.
Роль VLESS
VLESS является протоколом, который может использоваться для связи клиента и сервера Xray. Его параметры аутентификации, транспорт и защита соединения задаются отдельно.
Для распространённых конфигураций с encryption: "none" защита обеспечивается внешним слоем, например TLS или REALITY. В актуальной документации Xray также описывается отдельный механизм VLESS Encryption. Поэтому свойства соединения определяются всей конфигурацией, а не одним названием VLESS.
Документация проекта требует защищённого внешнего транспорта, если не используется VLESS Encryption и соединение не проходит по доверенному частному каналу.
Что необходимо для работы
Для такой схемы требуются совместимые компоненты:
клиент OpenVPN с поддержкой выбранного прокси-интерфейса;
клиент VLESS или Shadowsocks с локальным прокси;
доступный удалённый прокси-сервер;
сервер OpenVPN, принимающий выбранный транспорт;
маршруты, сохраняющие доступ к внешнему прокси после запуска VPN.
Поддержка параметров в настольной версии OpenVPN не означает их автоматической поддержки во всех мобильных приложениях. Возможности конкретного клиента необходимо рассматривать отдельно от возможностей самого протокола.
TCP и UDP
OpenVPN может использовать TCP или UDP. Для варианта с передачей TCP-соединения через SOCKS5 сервер OpenVPN должен принимать TCP. Изменение транспорта только на клиенте не меняет конфигурацию сервера.
Возможность передачи UDP зависит от поддержки дейтаграмм на каждом участке. Если промежуточный клиент предоставляет только TCP-прокси, этого недостаточно для произвольного UDP-соединения.
При передаче потоков TCP внутри туннеля, который также использует TCP, потери пакетов могут вызывать дополнительные задержки из-за взаимодействия механизмов повторной передачи. Дополнительный слой поэтому способен уменьшать скорость и ухудшать отзывчивость соединения.
Маршрутизация и циклическое подключение
Из структуры соединения следует отдельное требование: внешний прокси-клиент должен сохранять путь к своему серверу независимо от внутреннего туннеля OpenVPN.
Если после запуска VPN весь трафик устройства, включая соединение самого прокси, направляется внутрь OpenVPN, может возникнуть цикл. VPN зависит от прокси, а прокси пытается работать через этот же VPN.
При проектировании маршрутов поэтому отдельно рассматривают служебное соединение с прокси-сервером и пользовательский трафик внутри VPN. Сам факт успешной первоначальной аутентификации ещё не подтверждает правильность маршрутизации после установки туннеля.
Особенности Android и GrapheneOS
Android допускает только один активный сервис VpnService на пользователя или профиль. Запуск другого такого сервиса останавливает предыдущий.
Следовательно, одновременное включение двух обычных VPN-приложений в одном профиле не создаёт последовательную цепочку автоматически. Если и OpenVPN, и клиент VLESS используют системный VPN-интерфейс, они могут вытеснять друг друга.
Для составного соединения требуется архитектура, в которой один компонент предоставляет локальный прокси без занятия второго VPN-интерфейса, либо приложение, самостоятельно реализующее необходимые уровни. Возможность такой работы зависит от выбранных программ.
Видимость трафика
При раздельном размещении прокси и VPN-сервера их роли различаются. Из описанной последовательности соединений следуют такие свойства:
Участник | Что доступно наблюдению |
|---|---|
Интернет-провайдер пользователя | Соединение с внешним прокси, его адрес, время и объём передачи |
Оператор прокси | Адрес подключившегося пользователя и соединение с сервером OpenVPN |
Оператор OpenVPN | VPN-сеанс и сетевой трафик после выхода из туннеля |
Конечный сайт | Адрес выхода VPN либо последующего выходного узла |
Шифрование HTTPS продолжает защищать содержимое соответствующего веб-сеанса после выхода из VPN. При этом авторизация на сайте, cookies и другие идентификаторы позволяют сайту узнавать пользователя независимо от количества промежуточных серверов.
DNS, IPv6 и проверка соединения
Проверка составного туннеля включает несколько независимых задач:
определение внешнего IPv4-адреса;
проверку маршрута IPv6, если он доступен;
проверку используемого DNS;
проверку поведения при остановке прокси;
проверку поведения при разрыве OpenVPN;
проверку восстановления после смены сети.
Проверка адреса в одном браузере показывает только маршрут его конкретного запроса. Она не доказывает, что все приложения, DNS-запросы и оба семейства IP используют одинаковый путь.
Назначение и ограничения
Дополнительный прокси меняет внешний участок подключения к OpenVPN. Он может помочь в сетях, где прямое соединение с VPN работает нестабильно или ограничивается.
Такая схема не гарантирует нераспознаваемость трафика и не устраняет доверие к операторам промежуточной инфраструктуры. Её свойства зависят от транспорта, маршрутизации, реализации клиентов и поведения соединения при сбоях.
Комментарии