Comments 22
Docker на vps чтобы поднять серверную часть прокси? куда катиться этот мир...
Да, серверную часть можно поставить и без Docker — для опытного администратора это нормальный вариант. Но цель статьи другая: дать воспроизводимый способ, который не требует вручную разбирать зависимости, версии и порядок запуска сервисов.
Контейнер здесь не проксирует VPN-трафик: он работает в host-сети, а конфигурация и клиентские ключи хранятся на VDS. Зато установка, обновление и перенос получаются предсказуемыми. Для личного VDS это вполне практичный компромисс между «идеологически чисто» и «легко поддерживать».
примерно туда же, куда и "ться" с "тся".
Есть лайвхак (на самом деле просто реалии жизни) проверенный на практике: даете заранее заготовленный ssh курсору, кодексу или клауду, просите развернуть докер и скиньте ссылку на интересующий вас VPN. Далее за пару итераций он все сделает и вы сможете поменять пароль и спокойно пользоваться.
Да, для чистого VDS это вполне рабочий путь. Я бы даже дал агенту не абстрактную ссылку на VPN, а сразу репозиторий со сценарием установки: https://github.com/chelslava/amneziawg-vds-setup
Тогда задача сводится к: «разверни сервер по README, проверь SSH, healthcheck, HTTP-панель и UDP-порт». Скрипт задаёт повторяемый путь и экономит токены: агенту не нужно с нуля искать совместимый образ, собирать Docker-команду, вспоминать sysctl и придумывать проверки после установки.
Но я бы не передавал агенту постоянный root-пароль от рабочего сервера. Лучше взять свежий VDS, использовать временный доступ или отдельный SSH-ключ, а после установки оставить только ключевой доступ, ограничить firewall и сменить пароль панели. Так это действительно удобно, но без лишнего риска.
Да, тут именно речь под целевой VDS. Прод машину с кучей докеров конечно рискованно давать, если не делать бекапов. Но если есть риски и сложности с этим всегда можно развернуть в тестовой среде, проверить все, сделать скрипт деплоя той же llm и потом 1-2 командами все поднять самостоятельно. Передавать долгоживущие доступы, да еще и root действительно рискованно.
Я, конечно, извиняюсь. Но зачем такие сложности? В моем случае VPN поднялась еще проще
Скачать AmeziaWG, вбить root ssh доступ от сервера
AmneziaWG обфусцирует WireGuard именно набором параметров Jc/Jmin/Jmax/S1/S2/H1–H4, и весь смысл – чтобы они были уникальными для вашего сервера. Если оставить значения по умолчанию из awg-easy, то со временем эта "уникальная" сигнатура становится общеизвестной, и DPI ловит её ровно так же, как чистый WireGuard. Так что первое действие после установки – сгенерировать свой набор параметров и синхронно прописать его и на сервере, и во всех .conf.
Как это применить для Кинетика?
А почему выбран форк от YokiToki, а не оригинал от w0rng для wg-easy?
Я выбрал его по причине что он использует более свежую серверную часть amneziavpn/amneziawg-go вместо старого образа amneziavpn/amnezia-wg.
Мне было важнее, чтобы AmneziaWG внутри контейнера был актуальнее. У YokiToki есть и минус: он рассчитан на обычные x86_64 VDS, для ARM-сервера я бы выбрал другое решение.
Вариант w0rng не считаю плохим — особенно если он уже работает и всё устраивает. Здесь просто выбрал вариант, который лучше подошёл под свежий VDS и мой сценарий установки.
На шаге 3 скрипт не работает, выдаёт:
Line | 57 | … STEXITCODE){throw "Удалённая команда завершилась с кодом $LASTEXITCOD … | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Удалённая команда завершилась с кодом 2.
Я исправил скрипт. Действительно, в некоторых случаях он приводил к подобной ошибке. Пожалуйста, загрузите новую версию с GitHub и попробуйте запустить установку заново.
Если ошибка повторится, скорее всего, на сервере остались артефакты от предыдущей установки. В этом случае есть два пути:
Попробовать запустить скрипт с параметрами принудительной перенастройки:
.\Install-AmneziaWG.ps1 -HostName <IP-адрес_сервера> -Mode Reconfigure -ForceЕсли сервер новый и ошибка сохраняется, рекомендую переустановить ОС для полностью чистой установки. Также советую использовать Ubuntu, так как она лучше всего подходит для этой задачи.
А чем плох оригинальный wg-easy в качестве основы? Он поддерживает awg из коробки (достаточно указать только соответствующую переменную в композе)
Хорошо, что вы про Legacy-совместимость конфигов прямо в статье написали. Добавлю, к чему это на практике - тем более выше уже про уникальность сигнатуры заговорили.
Обфускация в вашем Legacy-профиле (Jc/Jmin/Jmax, S1-S2, H1-H4) меняет форму и заголовки пакетов. Пассивный DPI, который ищет чистый WireGuard по сигнатуре, на такой профиль уже не среагирует. Но рукопожатие остаётся рукопожатием, просто в другой обёртке. А DPI умеет ещё и активно щупать: шлёт пробу и смотрит, как ответит сервер. Вот от этого и защищает CPS, параметры I1-I5, которых в Legacy-наборе нет. CPS подмешивает перед рукопожатием пакеты, снятые с настоящего протокола вроде QUIC или DNS, и прячет хендшейк за них. Причём это даже не 2.0: сам CPS появился ещё в 1.5, а 2.0 сверху доложил S3/S4 (паддинг cookie и data).
Докрутить CPS можно прямо в вашей схеме, awg-easy его поддерживает, просто сам не заполняет. I1-I5 прописывают руками в конфиге, сигнатуру снимают по инструкции Amnezia (new-amneziawg-selfhosted). Одна тонкость с регистром: именно I1, а не i1 - в wg-easy на этом был отдельный баг. И совпадать на сервере и клиенте I1-I5 не обязаны, это пакеты-обманки перед рукопожатием, а не его часть - для Legacy-сервера их вообще ставят только на клиенте, так в официальной инструкции и показано. WireSock, кстати, и 2.0, и CPS понимает, так что на клиенте затыка не будет.
Я сам делаю kernel-native установщик под Ubuntu и Debian, в том числе с ARM-сборками. Весь набор параметров AmneziaWG 2.0 он генерит сам на каждую установку, включая CPS: I1 ставится автоматически, а осмысленную сигнатуру под конкретный протокол при желании добавляют сверху. https://github.com/bivlked/amneziawg-installer . Подход другой, не панель в докере, просто ещё один вариант.
Свой AmneziaWG VPN на VDS за вечер: от аренды сервера до подключения в WireSock Secure Connect