К контенту
habrforever
ЖИВА #vless 2026 · ~6 мин чтения

awg-admin: почему я написал свой менеджер для управления Amnezia(WG)-серверами — актуализация 2026

оригинал на Хабре habr.com/…/1055412
снимок Wayback не сохранялся
статус на Хабре (ноябрь 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 «удалена по юридическим причинам») — именно поэтому появляются проекты-архивы вроде этого).

Статус оригинала

Почему 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. Буду рад обратной связи и идеям.

по теме #vless