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

Ситуация встречается чаще, чем кажется: хостер выдал новый IP, машину перенесли в другой дата-центр, провайдер отозвал подсеть. И вот тут выясняется, что разные протоколы переживают это очень по-разному.

Куда вообще записан адрес

В конфигурации WireGuard за это отвечает одна строка в блоке пира:

[Peer]
PublicKey = ...
Endpoint = 198.51.100.10:51820
AllowedIPs = 0.0.0.0/0

В OpenVPN — директива remote:

remote vpn.example.com 1194

Внешне похоже. Разница проявляется, когда адрес перестаёт отвечать.

У WireGuard запасного адреса нет

Формат конфигурации WireGuard допускает ровно одну строку Endpoint на пир. Не «одну основную и несколько запасных» — одну. Написать вторую нельзя: утилита wg разберёт файл, и последнее значение просто перезапишет предыдущее.

Обойти это, добавив второй [Peer] с тем же ключом, тоже не выйдет. Пиры в WireGuard опознаются по публичному ключу, и два блока с одинаковым ключом — это не два маршрута к одному серверу, а конфликт: интерфейс примет последний.

Такова цена минимализма, за который WireGuard и хвалят. Протокол сознательно не умеет многого из того, что умеет OpenVPN, — об этом устройстве мы писали подробно. Отсутствие перебора адресов — часть той же сделки.

Роуминг работает, но в другую сторону

Здесь легко обмануться. WireGuard действительно умеет менять адрес пира на лету: получив корректно подписанный пакет с нового адреса, он запоминает его и отвечает уже туда. Именно так телефон бесшовно переходит с Wi-Fi на мобильную сеть, не разрывая туннель.

Но это работает только от клиента к серверу. Сервер узнаёт новый адрес клиента, потому что клиент присылает пакеты. В обратную сторону приёма нет: клиент не может узнать новый адрес сервера, потому что до сервера ему сначала надо достучаться — а он не знает куда.

У OpenVPN строк remote может быть несколько

remote vpn.example.com 1194
remote 198.51.100.10 1194

Клиент пробует их по очереди сверху вниз, а --resolv-retry определяет, сколько ждать при неудаче. Есть и --remote-random — тогда порядок перемешивается, что заодно распределяет нагрузку между входами.

Отсюда и практический вывод: конфигу OpenVPN можно дать домен основным адресом и IP запасным. Если домен не разрешается — например, провайдер испортил DNS, — клиент перейдёт ко второй строке и подключится напрямую. У WireGuard такой страховки нет по формату.

Домен решает задачу, но не полностью

Логичный шаг — писать в Endpoint не адрес, а домен:

Endpoint = gate.example.com:51820

Тогда при переезде достаточно поправить A-запись, и выданные конфиги продолжат работать. Перевыпускать ничего не нужно, пользователи ничего не заметят.

Важная оговорка: имя разрешается один раз — при поднятии интерфейса. Ядро работает только с IP-адресами, а DNS-запрос делает wg-quick на этапе up. Если адрес сменится, пока туннель уже поднят, клиент продолжит слать пакеты на старый IP, пока соединение не перезапустят. В комплекте wireguard-tools для этого есть отдельный вспомогательный скрипт, а мобильные приложения обычно перерезолвят имя при переподключении.

То есть домен спасает при следующем подключении, а не мгновенно. Для планового переезда этого достаточно: люди переподключаются по нескольку раз в день.

Второй нюанс — DNS должен быть доступен до поднятия туннеля. Если в системе прописан только внутренний резолвер из самого VPN, получается замкнутый круг. Поэтому запасной IP в конфиге OpenVPN ценен именно как страховка от проблем с разрешением имени.

AmneziaWG наследует ограничение целиком

AmneziaWG — форк WireGuard, добавляющий маскировку: мусорные пакеты, случайные заголовки, изменённые размеры служебных сообщений. Формат конфигурации при этом тот же, wg-quick-совместимый, с добавленными параметрами Jc, Jmin, Jmax, S1, S2, H1–H4.

Что унаследовано вместе с форматом: один Endpoint на пир и никакого перебора адресов. Обфускация решает задачу скрытности, а не отказоустойчивости — это разные слои, и смешивать их не стоит.

Что из этого следует при выборе

WireGuard / AmneziaWG OpenVPN
Адресов в конфиге один сколько угодно
Запасной адрес невозможен remote второй строкой
Домен в конфиге можно, резолв при подъёме можно, плюс --resolv-retry
Переезд сервера переживёт, если стоял домен переживёт даже при поломке DNS

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

Там, где формат позволяет запасную строку, её стоит заполнить: это защищает уже не от переезда, а от испорченного DNS у конкретного провайдера. Сравнение протоколов по остальным параметрам — в отдельном разборе, там же про то, чем OpenVPN платит за свою универсальность.

Коротко

Смена адреса сервера — не редкость, а рядовое событие. WireGuard к нему уязвим по формату: один Endpoint, запасного не предусмотрено, роуминг работает только в сторону сервера. OpenVPN переживает переезд легче за счёт нескольких remote. И тот и другой спасает домен вместо IP — при условии, что он там оказался заранее, до переезда, а не после.