Миграция сервера WireGuard начинается с подготовки нового хоста, переключения одного устройства и проверки его фактического пути. До массового переноса подтвердите возврат клиента на старый сервер; отдельно решайте вопросы Endpoint, серверной идентичности и вывода ресурсов из эксплуатации.

Ключевые выводы:

На обоих хостах сохраняйте рабочую консоль и последнюю доверенную конфигурацию.

Сначала переносите один клиент: изменение DNS не заставляет всех клиентов повторно разрешить имя.

Проверенный откат здесь является вашим критерием приёмки, а не заявлением об авторском эксперименте.

Что фиксирует миграция сервера WireGuard до начала работ?

Область инструкции — Ubuntu 24.04 LTS, нативная служба wg-quick@wg0, один действующий сервер и одна замена. Материал составлен по официальным документам без полного сквозного авторского тестирования. Описанные результаты являются ожиданиями для вашей разрешённой среды. Границы ответственности объясняет обзор самостоятельного обслуживания сети.

Нужны sudo, проверенные независимые от туннеля консоли обоих хостов, окно обслуживания, защищённые копии и клиент, который разрешено временно отключить. Не используйте производственную подсеть без права управления или общий хост, чьи службы вам нельзя останавливать. Процедура не разрешает эксперименты на чужих конечных узлах.

Запишите старые и новые внешние адреса, UDP-порты, открытые ключи серверов, туннельные адреса, ключи клиентов и AllowedIPs, частные либо интернет-направления, владельцев DNS и межсетевого экрана, исходящий интерфейс. Добавьте поддержку IPv6, правила маршрутизации, поведение клиентского резолвера и реестр ресурсов старого провайдера. Ограничьте доступ к записи; закрытым ключам и полным профилям не место в публичной заявке.

Прежде чем оплачивать перекрывающиеся хосты, сравните обязанности владельца VPS и управляемого VPN. Если вам по-прежнему необходим контроль ключей или частных маршрутов, продолжайте перенос. Поздняя смена решения не отменяет старые ресурсы автоматически.

Шаг 1: Как устроена миграция VPS WireGuard?

Заранее запишите причины отката: потеря управления, неработающий обязательный запрос контрольного клиента, неправильный DNS-путь или неразрешённый выход IPv6. Выберите максимальное окно наблюдения под свой график и назначьте человека с доступом к обеим консолям. Универсальное время ожидания не заменяет это решение.

Сохраните проверенную конфигурацию старого сервера и журнал отзывов под уникальными защищёнными именами. Запишите состояние автозапуска, текущую активность, пересылку и правила межсетевого экрана. Один файл не содержит облачных правил, настроек IP forwarding или состояния оплаты.

До копирования согласуйте устройства через учёт пиров и отзыв доступа. Историческая копия не должна вернуть позже удалённый ключ. На время переключения заморозьте правки пиров либо ведите единый датированный журнал, применяемый обоими хостами до допуска трафика.

На замене установите инструменты WireGuard дистрибутива утверждённым пакетным процессом и создайте только необходимый путь. Ограничьте управление, разрешите нужный UDP-порт, включите пересылку только для шлюза и ограничьте обратные маршруты или NAT нужным туннельным диапазоном и исходящим интерфейсом. Документация Ubuntu рассматривает эти компоненты отдельно. Не копируйте имя чужого интерфейса и не очищайте весь межсетевой экран.［2］

Шаг 2: Выберите перенос или замену серверной идентичности

Вариант	Изменение клиента	Условие эксплуатации
Новая идентичность сервера	Новый открытый ключ сервера и Endpoint для каждого перенесённого клиента	Хосты могут сосуществовать с явно разными идентичностями
Сохранение доверенной идентичности	Прежний открытый ключ и новый Endpoint	Секреты передаются безопасно, работает только назначенный хост
Подозрение на утечку ключа	Новая идентичность и затронутые общие секреты	Не возвращать скомпрометированный ключ ради отката

Для описанного параллельного переноса одного клиента предпочтительна новая идентичность. Создайте пару ключей на новом хосте с ограничительной umask, оставьте закрытый ключ там и распространяйте только открытый. WireGuard аутентифицирует пиры по ключам; смена адреса сама по себе не создаёт новую идентичность.［1］

При намеренном сохранении идентичности передавайте секретный материал только по аутентифицированному административному каналу с проверенными ключами хоста и правами назначения только для root. Остановите старый туннель до запуска клона. Этот вариант прерывает обслуживание и не подходит для неизменённой параллельной процедуры с двумя идентичностями. Неясное владение общим ключом на доступных хостах затрудняет обучение Endpoint и диагностику.

Одинаковая туннельная подсеть допустима на независимых серверах только при действительной изоляции сетей и одном выбранном активном профиле клиента. Не соединяйте оба клона мостом в одном маршрутизируемом домене. Если меняете подсеть, пересмотрите адреса всех клиентов, маршруты, ACL и DNS-зависимости, а не считайте операцию простой сменой Endpoint.

Шаг 3: Подготовьте новый путь без переключения всех клиентов

Установите конфигурацию в /etc/wireguard/wg0.conf, владелец root, режим 0600. Перенесите только разрешённых пиров и примените все отзывы. Для управления файлом оставьте SaveConfig отсутствующим либо false: сохранение при остановке может перезаписать изменения. DNS и хуки должны соответствовать новому хосту.［3］［4］

Для новой идентичности запустите замену, пока старый сервер остаётся доступным:

sudo systemctl start wg-quick@wg0
sudo systemctl is-active wg-quick@wg0
sudo wg show wg0 public-key
sudo wg show wg0 listen-port
sudo wg show wg0 peers

Команды выполняются на новом хосте. Сравните ключ и порт с записью миграции; статус active не является достаточным доказательством. Не выводите showconf или дамп секретных полей. Через соответствующий механизм управления проверьте адрес туннеля и облачное входящее правило UDP.

При ошибке запуска остановитесь, оставьте клиентов на старом хосте и используйте проверки службы и загрузки системы. Сначала установите собственную рабочую базу нового сервера, затем меняйте парк устройств.

Шаг 4: Выполните перенос Endpoint WireGuard на одном клиенте

Локально сохраните последнюю доверенную конфигурацию контрольного клиента и подпишите хост назначения каждого профиля. Для новой идентичности обновите открытый ключ сервера вместе с Endpoint и портом; общий предварительный ключ (preshared key) меняйте, только если он используется этой парой. Закрытый ключ клиента сохраняется, если его ротация не запланирована отдельно.

Активируйте лишь один из старого и нового профилей одновременно. Иначе пересечение маршрутов клиента испортит сравнение. Создайте запрос к разрешённой туннельной службе и проверьте новое рукопожатие и изменение счётчиков именно этого клиента на новом сервере. Открытие страницы через обычную сеть не доказывает использование туннеля.

Доменный Endpoint разрешается согласно реализации клиента и его жизненному циклу. Изменение DNS не гарантирует немедленную смену назначения активного туннеля. Запишите клиент, версию, фактический разрешённый адрес и документированное действие переподключения или повторной активации. Используйте объяснение Endpoint и смены адресов; не перезапускайте несвязанные службы ради борьбы с кэшем.［1］［4］

По возможности сначала задайте явный новый Endpoint в разрешённом контрольном профиле, затем отдельно проверьте нужный домен. До DNS-переключения сохраните старую запись и TTL. Для отката тоже нужно подтвердить реальное назначение клиента, а не только возвращённую запись в панели управления.

Шаг 5: Чем подтверждается работоспособность нового пути?

Оставьте неизменённого клиента на старом хосте как контроль. Для проверяемого устройства запишите время, идентичность профиля, назначение, ожидание и сервер, увидевший рукопожатие. Секретные значения в отчёт не переносите.

Метод проверки	Ожидаемый признак	Действие при ошибке
Контрольный клиент обращается к разрешённому туннельному адресу	Новый сервер видит свежее рукопожатие и ответ службы	Проверить идентичность, UDP-путь и политику приложения
Обязательное интернет-приложение использует полный туннель	Выбранный трафик выходит через новый хост	Исследовать маршруты, пересылку и NAT
Клиент разрешает нужное имя	Используется предусмотренный резолвер и ответ	Проверить DNS-хуки и политику разрешения
Проверка IPv6 и намеренного отключения туннеля	Поведение соответствует заявленному туннелированию, блокировке или прямому пути	Прекратить приёмку при неразрешённом выходе
Старый контроль повторяет запрос	Прежний путь доступен	Сначала восстановить независимый путь отката

Для интернет-шлюза проверьте текущий публичный IP контрольного клиента в браузере, который должен использовать туннель. При раздельной маршрутизации обычный выход этого браузера может быть правильным; зафиксируйте ожидание вместо ложного вывода о сбое. Наблюдение IPv4 не доказывает DNS-маршрутизацию, IPv6, UDP или защиту при отключении.

Если рукопожатие есть, а приложение не работает, примените диагностику маршрутизации и пересылки. Исправляйте только отказавший слой. Одновременная замена ключей, DNS и правил межсетевого экрана уничтожает основу для осмысленного отката.

Шаг 6: Подтвердите откат и выведите старый сервер из эксплуатации

До переноса остальных устройств намеренно верните контрольный клиент на сохранённый доверенный профиль в разрешённом окне. Отключите новый профиль, совместно восстановите старый ключ сервера и Endpoint, выполните документированную активацию клиента. Подтвердите новое рукопожатие на старом хосте и повторите обязательные проверки приложения, DNS, IPv6 и разрыва. Если старая идентичность скомпрометирована, такой откат небезопасен: подготовьте доверенный путь восстановления.

Повторно переносите контрольный клиент вперёд только после успешного восстановления. При сохранении идентичности сначала остановите замену, восстановите текущую проверенную конфигурацию и журнал отзывов старого хоста, затем запустите старый экземпляр. Оба клона не должны работать вместе. Отмените только миграционные изменения DNS и межсетевого экрана, отдельно подтвердив доступ к консоли.

Остальные устройства переносите небольшими группами с учётом выбранного серверного ключа и фактического Endpoint каждого клиента. Наблюдайте новый путь в заранее согласованном окне и проверьте характерные переподключения. Отсутствие трафика на старом хосте — вспомогательный признак, а не доказательство переноса спящих устройств. До завершения свяжитесь с их ответственными владельцами.

Включайте автозапуск замены после приёмки конфигурации, затем проверьте разрешённую перезагрузку с доступной консолью. Старые ресурсы отката сохраняйте до закрытия окна. Для вывода остановите и отключите старый туннель, отзовите старые эксклюзивные учётные данные, уберите миграционные правила и обработайте копии по политике хранения. Удалите ненужные экземпляры, диски, зарезервированные адреса и снимки средствами провайдера. Прекращение оплаты проверяйте отдельно от выключения питания.

Итоги

До копирования зафиксируйте идентичности, маршруты и отзывы.
Перед массовой сменой подтвердите новый путь одного клиента и возврат на старый.
Удаляйте инфраструктуру после приёмки и проверки учёта ресурсов.

Часто задаваемые вопросы (FAQ)

Должен ли измениться открытый ключ сервера?

При выборе новой серверной идентичности он меняется. Доверенный старый ключ можно сохранить, но нужны безопасная передача секретов и исключительное владение активным хостом.

Низкий DNS TTL сразу перенесёт клиентов?

TTL влияет на кэширование резолвера, а не на каждый работающий Endpoint WireGuard. Проверьте фактический адрес и документированный способ повторного разрешения имени.

Могут ли серверы использовать один ключ во время пробного переноса?

Здесь параллельная работа использует разные идентичности. При намеренном сохранении одной идентичности остановите старый туннель до запуска замены.

Новое рукопожатие доказывает доступ к интернету?

Рукопожатие подтверждает связь пиров, но не пересылку и DNS-политику. Проверяйте приложение, нужный IP, DNS и IPv6 отдельно.

Может один клиентский ключ находиться на обоих хостах?

При контролируемой миграции он может быть подготовлен на двух изолированных хостах. Сохраняйте разные серверные идентичности, один активный профиль и согласованные отзывы.

Когда удалять старую виртуальную машину?

Дождитесь выполнения письменных условий по устройствам, откату и окну наблюдения. Отдельно проверьте продолжающиеся расходы на диски, адреса и снимки.

Что означает проверенный откат?

Вы действительно возвращаете разрешённый контрольный клиент на доверенный старый путь и проверяете нужное поведение. Статья описывает процедуру, не заявляя об авторском эксперименте.

Источники:

WireGuard — Quick Start — https://www.wireguard.com/quickstart/
Ubuntu — Using the VPN as the default gateway — https://ubuntu.com/server/docs/how-to/wireguard-vpn/vpn-as-the-default-gateway/
Ubuntu — Common tasks in WireGuard VPN — https://ubuntu.com/server/docs/how-to/wireguard-vpn/common-tasks/
Ubuntu Noble — wg-quick(8) — https://manpages.ubuntu.com/manpages/noble/man8/wg-quick.8.html

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

Миграция сервера WireGuard с проверяемым откатом