Как я сделал WireGuard-шлюз, который самостоятельно переживает блокировку VLESS-сервера
Идея проекта появилась после нескольких попыток использовать бесплатные VLESS-конфигурации. Найти такие наборы несложно, однако стабильной их работу назвать трудно: один сервер внезапно перестаёт отвечать, другой теряет скорость, третий продолжает открывать сайты, но не пропускает отдельные сервисы. В результате пользователю приходится вручную возвращаться к подписке, перебирать конфиги и искать рабочую замену.
Платные решения тоже не всегда избавляют от проблемы. Внешний узел может попасть под блокировку, изменить характеристики или временно оказаться перегруженным. Поэтому возникла задача: оставить на смартфоне, компьютере и роутере один постоянный профиль, а выбор исправного внешнего маршрута полностью перенести на сервер.
Так появился Hydrat - шлюз, к которому устройства подключаются через WireGuard. Дальше трафик направляется через выбранный VLESS-сервер либо Tor-мост. Если внешний узел перестаёт работать, система подбирает другой вариант автоматически. Пользователь при этом не меняет профиль и не замечает сам факт переключения.
Принцип работы системы
Работа Hydrat состоит из нескольких этапов:
1. В административную панель добавляются VLESS-ссылки, подписки и Tor-мосты.
2. Система извлекает из них отдельные конфигурации и формирует список кандидатов.
3. Каждый кандидат проходит проверку доступности, скорости, нужных сервисов и поддерживаемых протоколов.
4. Подходящие варианты попадают в рабочий пул.
5. Для каждого WireGuard-клиента назначаются основной и резервный маршруты.
6. При отказе или заметном ухудшении качества шлюз проверяет альтернативы и при необходимости переносит клиента на другой выход.
WireGuard в этой схеме используется как постоянная точка входа. Телефон или ноутбук всегда подключается к одному и тому же адресу, а вся логика выбора внешнего сервера остаётся внутри шлюза. Благодаря этому смена VLESS-конфигурации не требует повторной настройки устройств.
До самого WireGuard-сервера подключение, разумеется, должно оставаться доступным. Поэтому шлюз размещён в российской юрисдикции - в моём случае это домашний сервер, на котором уже работают собственные проекты. Внешние VLESS- и Tor-маршруты используются только после прохождения этого первого участка.
Отдельные маршруты для TCP и UDP
У клиента предусмотрено два независимых назначения. TCP может передаваться через VLESS либо через подготовленный Tor-мост. UDP работает только через VLESS-конфигурации, которые отдельно подтвердили поддержку UDP.
Такое разделение важно на практике. Например, конкретный выход может продолжать нормально обслуживать TCP, но перестать пропускать UDP. В этом случае TCP останется рабочим, а проблема затронет только UDP. Если подходящей замены нет, отключается лишь соответствующий транспорт, а не весь интернет-доступ.
Система не переводит трафик на прямое соединение без явного разрешения. Это исключает неприятную ситуацию, когда после отказа прокси приложения продолжают работать, но уже раскрывают реальный маршрут или адрес назначения.
Правила маршрутизации
Hydrat поддерживает базы geoip.dat и пользовательские правила маршрутизации. С их помощью можно определить, какие направления должны идти напрямую, а какие - через выбранный внешний маршрут.
Это особенно удобно для приложений, которые чувствительно реагируют на VPN-подключения. Часть российских сервисов можно оставить на прямом маршруте, а международный трафик направить через VLESS или Tor. В результате приложения маркетплейсов и банковских сервисов реже сталкиваются с ошибками, связанными с необычным сетевым выходом.
Правила применяются централизованно, поэтому их не нужно копировать на каждый телефон или компьютер. Достаточно изменить конфигурацию на шлюзе - все клиенты начинают работать по новым условиям.
Архитектура из контроллера и агента
На сервере работают два Go-процесса, размещённых в отдельных сетевых пространствах имён.
Контроллер отвечает за управление:
- хранит источники, конфигурации и историю проверок в SQLite;
- запускает тестирование кандидатов;
- рассчитывает назначения для клиентов;
- управляет рабочим пулом;
- предоставляет административную панель.
Агент занимается непосредственным применением изменений:
- настраивает WireGuard;
- обновляет nftables;
- управляет Xray и Tor;
- выполняет сетевые проверки;
- применяет рассчитанный план маршрутизации.
Такое разделение создаёт чёткую границу между принятием решения и его выполнением. Контроллер может подготовить новый план, пока агент продолжает обслуживать текущие соединения. Если управляющий процесс перезапустится, уже применённые маршруты не исчезнут.
Агент сохраняет последний рабочий план. После перезапуска он дожидается готовности Xray, восстанавливает внешние выходы и правила фильтрации, а затем сообщает системе о готовности. Благодаря этому сетевой слой восстанавливается независимо от управляющей части.
Как формируется рабочий пул
После добавления подписки шлюз может получить сотни или тысячи VLESS-конфигураций и Tor-мостов. На этом этапе о большинстве кандидатов ничего не известно. Полная проверка каждого варианта требует времени, соединений и вычислительных ресурсов.
Если сразу отправить все конфигурации в одну очередь, заведомо нерабочие варианты будут конкурировать с перспективными наравне с ними. Поэтому импортированный каталог и рабочий пул разделены.
В базе допускается хранение до 10 000 уникальных кандидатов, тогда как в активный рабочий пул попадает не более 200 вариантов. Сначала VLESS-конфигурации проходят короткую предварительную проверку. Для неё используются восемь обработчиков, а максимальное время на одного кандидата ограничено тремя секундами.
Успешно прошедшие предварительный этап варианты получают более глубокую проверку. На ней оцениваются стабильность соединения, доступность нужных направлений, задержка, скорость, прохождение TCP и UDP, а также поведение прокси при повторных запросах.
Деградация и автоматическая замена маршрутов
Одного факта "сервер отвечает" недостаточно. Узел может формально быть доступен, но работать настолько медленно, что пользоваться им невозможно. Поэтому Hydrat отслеживает не только отказ, но и постепенное ухудшение качества.
Для маршрутов собирается история проверок. В ней учитываются доля успешных запросов, задержка, скорость установления соединения и стабильность работы отдельных транспортов. Кратковременный сбой не приводит к немедленному переносу клиента: система старается отличать случайную ошибку от устойчивой деградации.
Если качество выходит за заданные пределы, контроллер оценивает резервные варианты. Замена применяется только тогда, когда альтернативный маршрут действительно лучше текущего. Это снижает количество лишних переключений и предотвращает ситуацию, при которой клиент постоянно перемещается между одинаково нестабильными выходами.
Для разных клиентов могут быть назначены разные маршруты. Один пользователь получит наиболее быстрый VLESS-сервер, другому будет выбран более стабильный, а третьему - вариант, который лучше проходит нужные сервисы.
Что происходит при блокировке VLESS-сервера
Когда внешний сервер перестаёт отвечать, агент фиксирует отказ и сообщает результат контроллеру. Контроллер исключает маршрут из активного назначения, выбирает подходящую замену и передаёт агенту новый план.
WireGuard-подключение при этом не разрывается. Меняется только следующий участок маршрута - тот, который находится за шлюзом. Для конечного устройства это выглядит как обычное продолжение работы через тот же VPN-профиль.
Если новый VLESS-выход не найден, система может сохранить доступный TCP-маршрут через Tor, а UDP оставить отключённым. Такой подход безопаснее, чем незаметно выпускать трафик напрямую.
Работа с Tor-мостами
Для Tor предусмотрена поддержка мостов obfs4 и webtunnel. Они также проходят проверку и включаются в общий механизм назначения маршрутов.
Tor используется прежде всего как резервный TCP-канал. Он не заменяет VLESS во всех сценариях, поскольку имеет собственные ограничения по скорости и задержке, но способен сохранить доступность отдельных направлений при проблемах с основными прокси.
Мосты проверяются не только на возможность установить соединение, но и на пригодность для реальной передачи данных. Наличие успешного рукопожатия само по себе ещё не означает, что маршрут годится для постоянной эксплуатации.
Важные эксплуатационные детали
Для стабильной работы такой системы необходимо учитывать несколько факторов:
- сервер WireGuard должен иметь устойчивый внешний адрес или механизм динамического обновления;
- резервные маршруты нужно проверять заранее, а не только после отказа основного;
- состояние конфигураций следует хранить отдельно от временных результатов проверок;
- обновление правил должно быть атомарным, чтобы не оставлять шлюз в промежуточном состоянии;
- при диагностике нужно разделять неисправность WireGuard, Xray, Tor, DNS и самого внешнего сервера.
Административная панель показывает назначенные маршруты, состояние клиентов, результаты последних тестов и причины исключения кандидатов из рабочего пула. Это значительно упрощает поиск проблем: вместо субъективного "VPN медленный" можно увидеть, на каком именно этапе возникла ошибка.
Итог
Hydrat решает не задачу создания ещё одного прокси-клиента, а задачу автоматического управления постоянно меняющимся набором внешних маршрутов. WireGuard остаётся неизменной точкой входа, а VLESS и Tor превращаются в сменный пул выходов.
Главный результат - отсутствие необходимости вручную менять конфигурации на каждом устройстве. Источники обновляются на сервере, кандидаты проверяются автоматически, рабочие маршруты распределяются между клиентами, а отказавшие варианты заменяются без полного разрыва пользовательской схемы подключения.
При этом система не пытается скрыть проблему любой ценой: если для конкретного транспорта нет исправного маршрута, отключается именно он. Такой принцип делает поведение предсказуемым и не допускает незаметного перехода на прямое соединение.