awg-admin: почему я написал свой менеджер для управления Amnezia(WG)-серверами — актуализация 2026
awg-admin: почему я написал свой менеджер для управления Amnezia(WG)-серверами
Архивное переиздание с актуализацией. Оригинал опубликован на Habr (2026), автор — неизвестен. оригинал доступен на Habr по состоянию на ноябрь 2026. Ниже — редакция ноября 2026: что работает сейчас, что изменилось и как правильно повторить рецепт сегодня. Полный текст оригинала — в конце, без купюр.
TL;DR — версия 2026
VLESS+REALITY (Xray) в 2026 — главный рекомендованный способ: маскировка под TLS к чужому крупному сайту, активное зондирование не проходит, домен и сертификат не нужны.
Оригинал попал в первую волну статей о VLESS+Reality — и с тех пор подход не просто выжил, а стал стандартом: фактическим стандартом антицензурного туннелирования в 2026 стал VLESS + REALITY (Xray-core): он маскируется под обычный HTTPS-трафик к крупному сайту и не требует собственного домена и сертификата; по данным РКН, за 2025 год в России заблокировано 258 VPN-сервисов, и почти все выжившие сервисы сидят именно на Xray. Что изменилось с публикации: пару-тройку версий Xray-ядра, новые клиенты, панели 3x-ui/Marzban с автонастройкой Reality, и — увы — статья о том, как это ставить, стала легальной мишенью (российские сайты и сами хабр-авторы начали массово удалять статьи о VPN (статьи отдают HTTP 451 «удалена по юридическим причинам») — именно поэтому появляются проекты-архивы вроде этого).
Статус оригинала
- URL: https://habr.com/ru/articles/1055412/
- Статус на Habr: ЖИВА
- Картинки: 0/0 сохранено локально
Почему REALITY до сих пор непробиваем
REALITY «крадёт» рукопожатие у настоящего TLS-сайта: ваш сервер, не имея сертификата, отдаёт клиенту handshake реального target-сайта (dest), а внутри договаривается о ключах. Со стороны (DPI, активный probe) это обычный HTTPS к популярному ресурсу. Ответить probe-ом «не тем» сервер не может — нечем отличить. В 2025–2026 у операторов блокировок остаётся один приём: резать «подозрительные» IP целиком. Лечится CDN-фронтом или сменой IP.
Минимальный сервер 2026
Актуальный Xray-core (ветка 2x/25.x) — ставится официальным скриптом; ключевые поля:
"inbounds": [{
"listen": "0.0.0.0",
"port": 443,
"protocol": "vless",
"settings": {
"clients": [{ "id": "<uuid>", "flow": "xtls-rprx-vision" }],
"decryption": "none"
},
"streamSettings": {
"security": "reality",
"realitySettings": {
"dest": "www.microsoft.com:443",
"serverNames": ["www.microsoft.com"],
"shortId": "",
"privateKey": "<x25519>"
}
}
}]
Выбор dest: крупный зарубежный сайт с TLS 1.3 + H2, НЕ ваш CDN, не российский, не «за Cloudflare» (цикл). Проверка: openssl s_client -connect dest:443 с сервера должна отдавать нужный SNI.
Что изменилось с 2026 года
- uTLS-фingerprint клиента теперь критичен (chrome/firefox из коробки)
- flow xtls-rprx-vision — норма; старые flow без vision уязвимы к детекту
- XHTTP-транспорт добавился как альтернатива ws/gRPC за CDN
- 3x-ui заменил большинство «костыльных» bash-панелей из статей 2023 года
- iOS-клиенты требуют зарубежный Apple ID чаще, чем в 2024
- в тексте оригинала: у «ванильного» WireGuard статичный хендшейк — DPI его режет; обфусцированный вариант — AmneziaWG
Чек-лист 2026
- dest — живой крупный сайт с TLS1.3, доступный С ВАШЕГО сервера
- shortId непустой
- uTLS fingerprint клиента совпадает с типичным браузером
- сервер не «светится» сканерами (закрыть 80/8080-заглушки)
- fallback на реальный сайт, если probe придёт без правильного SNI
Вердикт
Оригинальная статья была верной — просто Xray с тех пор обновился, панели стали удобнее, а сама тема — юридически горячей. Конфиг выше — минимальная «сегодня-работает»-версия; вся методология оригинала (x25519-ключи, SNI-подбор, проверка blockcheck) неизменна.
ОРИГИНАЛ СТАТЬИ (без изменений)
Недавно друг попросил помочь с настройкой VPN. Казалось бы, обычная задача. Но когда я посмотрел, что у него уже развернуто, удивился.
Для управления четырьмя клиентами использовался полноценный многопользовательский веб-сервис на PHP с MySQL. Более того, под него пришлось выделить отдельный VPS, потому что минимального тарифа с одним ядром и гигабайтом памяти уже не хватало, приложения начинали уходить в своп.
На мой вопрос, почему был выбран именно этот вариант, ответ оказался неожиданно простым:
Мне нужен мониторинг.
Ради мониторинга пришлось разворачивать целый портал со своей инфраструктурой.
К тому моменту у меня уже работали несколько собственных VPS с AmneziaWG. Больше года я управлял ими вручную через консоль, и редкие вмешательства не напрягали. Но в последнее время обстоятельства потребовали уделять значительно больше времени серверам. История друга подтолкнула посмотреть, какие инструменты вообще существуют — и можно ли обойтись без громоздкой инфраструктуры.
Я перебрал популярные решения и в итоге написал awg-admin — десктопное приложение, которое управляет несколькими серверами WireGuard/AmneziaWG с минимумом софта на самих VPS. В этой статье я расскажу, какие проблемы заставили меня взяться за собственный инструмент и чем он отличается от готовых панелей.
Что предлагают существующие решения
Большинство проектов можно разделить на три группы.
Классические веб-панели — wg-easy, WGDashboard, wg-portal и им подобные. Они позволяют добавлять клиентов, смотреть статистику handshake и трафика, генерировать QR-коды. Некоторые поддерживают Prometheus, аутентификацию, экспорт конфигураций.
Это зрелые инструменты, но их архитектура предполагает, что рядом с VPN-туннелем постоянно живёт ещё один сервис: веб-интерфейс, база данных (пусть даже SQLite), контейнер. Даже лёгкая SQLite потребляет ресурсы, и сам факт наличия СУБД на VPN-шлюзе меня не устраивал.
Сетевые платформы — Firezone, NetBird, Tailscale, Headscale. Они дают overlay-сеть с координатором, политиками доступа, автоматическим обходом NAT. Это мощно, но избыточно для личного использования: требования к инфраструктуре значительно выше, а управление завязано на центральный узел.
Десктопные/лёгкие решения — AmneziaVPN и JWG.
AmneziaVPN использует обычное десктопное приложение, которое по SSH настраивает и контролирует VPN-сервер. Никакой СУБД на VPS не нужно. Это было максимально близко к тому, что я хотел.
JWG — компактный CLI-инструмент (один бинарник). Запускается непосредственно на VPS. Простой и удобный, с необходимым функционалом.
Но когда у вас не один сервер, а три или пять, открывать несколько окон Amnezia или несколько ssh-терминалов с JWG уже неудобно. Хотелось единый интерфейс для всех узлов и ещё несколько возможностей, которых не было ни в одном из этих проектов.
Чего не хватало именно в моем сценарии
Почти все современные панели показывают handshake, трафик, статус клиентов и QR. Проблема была не в отсутствии мониторинга, а в другом.
Я составил список того, чего мне реально не хватало:
Управление несколькими серверами в одном интерфейсе. Не открывать по панели на каждый VPS, а видеть их как единый парк: добавлять пиров, смотреть состояние, переключаться между узлами.
Минимум софта на сервере. Если VPS — это VPN-шлюз, пусть он им и остаётся. Никаких веб-серверов, СУБД и лишних демонов. Чем меньше компонентов, тем дешевле тариф и проще обслуживание.
Мониторинг без постоянно работающей инфраструктуры. Я хочу видеть графики загрузки CPU, памяти и активность клиентов только тогда, когда открываю приложение. Хранить метрики круглосуточно на сервере не обязательно.
Десктопное приложение вместо веб-портала. Инструмент для одного администратора. Запустил, сделал дело, закрыл. Это удобнее, чем каждый раз логиниться в браузере.
Быстрое построение туннелей между серверами без правки конфигов вручную.
Готового решения с таким сочетанием я не нашёл. AmneziaVPN отлично справляется с одним сервером, JWG — с одним. Расширений для multi-server там нет. Тогда я решил сделать свой инструмент.
Архитектура: почему десктоп и при чём здесь Zabbix
Мне нужен был инструмент для личного использования: один администратор, несколько VPS, никакого желания поднимать веб-сервис с СУБД ради управления VPN.
Идею подсказал опыт работы с Zabbix. В активном режиме Zabbix-агент кэширует метрики локально, если сервер недоступен, и отдаёт накопленные данные при восстановлении связи. Я подумал: а что если агент сам станет постоянным хранилищем?
Для моего сценария потеря нескольких часов истории не критична. Агент на каждом VPS может собирать статистику (нагрузка, handshake, трафик) и сохранять её в обычный JSON-файл. Никакой базы данных, только ротация по времени. Когда я открываю приложение, оно по SSH (или через mTLS) запрашивает этот JSON и строит графики. Храню последние 48 часов — этого достаточно.
Вся остальная логика управления живёт на моём ноутбуке. Приложение подключается к серверу, передаёт конфигурацию через REST API агента, тот применяет изменения и возвращает актуальное состояние. Доступ к API может идти либо через SSH-туннель до localhost, либо напрямую по защищённому mTLS.
Таким образом, на VPS работает только WireGuard/AmneziaWG и лёгкий агент. Никаких веб-интерфейсов, СУБД и лишних портов. VPN-сервер занимается только VPN.
Что в итоге получилось
awg-admin — это десктопное приложение на Go и Wails, которое управляет несколькими серверами WireGuard и AmneziaWG из одного окна.
Основные возможности:
Единый интерфейс для всех VPS. Все серверы видны в одном списке с ключевыми метриками (CPU, RAM, активные пиры, последний handshake).
Управление клиентами: добавление, отключение, генерация конфигураций и QR-кодов.
Мониторинг с локальным хранением. Приложение запрашивает у агентов JSON с историей за 48 часов и строит графики нагрузки и трафика. Никакой центральной базы метрик.
Туннели между серверами. Несколько кликов — и два узла соединяются site-to-site туннелем с автоматической настройкой маршрутов.
Лёгкий агент на VPS. Только сбор статистики и применение конфигурации. Установка — одной командой.
Работа через SSH и REST API. Административные задачи (установка, обновление) выполняются по SSH. Управление VPN и получение метрик идут через REST API агента — либо через SSH-туннель до localhost, либо напрямую по защищённому mTLS-соединению.
Приложение хранит локальную базу (список серверов, пользователей, настройки), работает на Windows, macOS и Linux.
Вместо заключения
Я не ставил цели сделать “ещё одну панель управления WireGuard”. Скорее попытался объединить подходы, которые подсмотрел в других решениях, и убрать всё, что мне лично мешало.
Получился awg-admin — узкоспециализированный, но решающий мои задачи. Если вы тоже управляете несколькими личными VPN-серверами и устали от веб-порталов, возможно, он пригодится и вам.
Код открыт, ссылка на репозиторий: https://github.com/ks-tool/awg-admin. Буду рад обратной связи и идеям.