Я исправил скрипт. Действительно, в некоторых случаях он приводил к подобной ошибке. Пожалуйста, загрузите новую версию с GitHub и попробуйте запустить установку заново.
Если ошибка повторится, скорее всего, на сервере остались артефакты от предыдущей установки. В этом случае есть два пути:
Попробовать запустить скрипт с параметрами принудительной перенастройки:
Если сервер новый и ошибка сохраняется, рекомендую переустановить ОС для полностью чистой установки. Также советую использовать Ubuntu, так как она лучше всего подходит для этой задачи.
Я выбрал его по причине что он использует более свежую серверную часть amneziavpn/amneziawg-go вместо старого образа amneziavpn/amnezia-wg.
Мне было важнее, чтобы AmneziaWG внутри контейнера был актуальнее. У YokiToki есть и минус: он рассчитан на обычные x86_64 VDS, для ARM-сервера я бы выбрал другое решение.
Вариант w0rng не считаю плохим — особенно если он уже работает и всё устраивает. Здесь просто выбрал вариант, который лучше подошёл под свежий VDS и мой сценарий установки.
Спасибо за комментарий. Я доработал скрипт и теперь в v0.2.0: При каждом Install генерируется новый набор параметров AmneziaWG Legacy: JC, JMIN, JMAX, S1, S2, H1–H4.
Тогда задача сводится к: «разверни сервер по README, проверь SSH, healthcheck, HTTP-панель и UDP-порт». Скрипт задаёт повторяемый путь и экономит токены: агенту не нужно с нуля искать совместимый образ, собирать Docker-команду, вспоминать sysctl и придумывать проверки после установки.
Но я бы не передавал агенту постоянный root-пароль от рабочего сервера. Лучше взять свежий VDS, использовать временный доступ или отдельный SSH-ключ, а после установки оставить только ключевой доступ, ограничить firewall и сменить пароль панели. Так это действительно удобно, но без лишнего риска.
Да, серверную часть можно поставить и без Docker — для опытного администратора это нормальный вариант. Но цель статьи другая: дать воспроизводимый способ, который не требует вручную разбирать зависимости, версии и порядок запуска сервисов.
Контейнер здесь не проксирует VPN-трафик: он работает в host-сети, а конфигурация и клиентские ключи хранятся на VDS. Зато установка, обновление и перенос получаются предсказуемыми. Для личного VDS это вполне практичный компромисс между «идеологически чисто» и «легко поддерживать».
Статью написал как вводную. И да я не робот. У меня более 16 лет опыта разработки и более 3 лет в RPA на различных платформах. Так что есть что рассказать, и следующие статьи постараюсь писать более технические.
Я исправил скрипт. Действительно, в некоторых случаях он приводил к подобной ошибке. Пожалуйста, загрузите новую версию с GitHub и попробуйте запустить установку заново.
Если ошибка повторится, скорее всего, на сервере остались артефакты от предыдущей установки. В этом случае есть два пути:
Попробовать запустить скрипт с параметрами принудительной перенастройки:
Если сервер новый и ошибка сохраняется, рекомендую переустановить ОС для полностью чистой установки. Также советую использовать Ubuntu, так как она лучше всего подходит для этой задачи.
Я выбрал его по причине что он использует более свежую серверную часть amneziavpn/amneziawg-go вместо старого образа amneziavpn/amnezia-wg.
Мне было важнее, чтобы AmneziaWG внутри контейнера был актуальнее. У YokiToki есть и минус: он рассчитан на обычные x86_64 VDS, для ARM-сервера я бы выбрал другое решение.
Вариант w0rng не считаю плохим — особенно если он уже работает и всё устраивает. Здесь просто выбрал вариант, который лучше подошёл под свежий VDS и мой сценарий установки.
Спасибо за комментарий. Я доработал скрипт и теперь в v0.2.0: При каждом Install генерируется новый набор параметров AmneziaWG Legacy: JC, JMIN, JMAX, S1, S2, H1–H4.
Да, для чистого VDS это вполне рабочий путь. Я бы даже дал агенту не абстрактную ссылку на VPN, а сразу репозиторий со сценарием установки: https://github.com/chelslava/amneziawg-vds-setup
Тогда задача сводится к: «разверни сервер по README, проверь SSH, healthcheck, HTTP-панель и UDP-порт». Скрипт задаёт повторяемый путь и экономит токены: агенту не нужно с нуля искать совместимый образ, собирать Docker-команду, вспоминать sysctl и придумывать проверки после установки.
Но я бы не передавал агенту постоянный root-пароль от рабочего сервера. Лучше взять свежий VDS, использовать временный доступ или отдельный SSH-ключ, а после установки оставить только ключевой доступ, ограничить firewall и сменить пароль панели. Так это действительно удобно, но без лишнего риска.
Да, серверную часть можно поставить и без Docker — для опытного администратора это нормальный вариант. Но цель статьи другая: дать воспроизводимый способ, который не требует вручную разбирать зависимости, версии и порядок запуска сервисов.
Контейнер здесь не проксирует VPN-трафик: он работает в host-сети, а конфигурация и клиентские ключи хранятся на VDS. Зато установка, обновление и перенос получаются предсказуемыми. Для личного VDS это вполне практичный компромисс между «идеологически чисто» и «легко поддерживать».
Статью написал как вводную. И да я не робот. У меня более 16 лет опыта разработки и более 3 лет в RPA на различных платформах. Так что есть что рассказать, и следующие статьи постараюсь писать более технические.