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

Симптом: правильная запись, устаревшие туннели

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

Ни одно из этих двух поведений не является дефектом, и именно это делает симптом запутанным. Клиент работает с ответом, полученным ранее, и ничто на стороне сервера не показывает, какой это был ответ. Запланируйте переподключение в окно обслуживания и скажите пользователям, что они увидят, или потратьте окно на ответы на заявки. Очередь одинаковых отчётов — обычный результат.

Кто управляет именем и что проверяет клиент

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

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

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

Когда каждый клиент перечитывает имя

Момент разрешения — свойство каждого клиента, поэтому проверьте реализацию, которую вы действительно поставляете, прежде чем обещать окно переключения. wg-quick разрешает конечную точку при подъёме интерфейса и сохраняет этот адрес до перезапуска туннеля. Клиент OpenVPN ищет имя при подключении, а будет ли он смотреть снова при переподключении, зависит от его опций.

ClientWhen it resolvesWhat it verifies
wg-quickAt interface start, cached for the sessionPeer public key, not the name
OpenVPN 2.6On connect, possibly again on reconnectCertificate identity or pinned name
Mobile clientsMay hold the answer across sleep or a network changePlatform trust store, same certificates

Мобильные клиенты — обычный сюрприз, потому что они могут сохранять разрешённый адрес во время сна или смены сети. Публикуйте записи A и AAAA только если замена отвечает в обоих семействах. Адрес, который отвечает в одном семействе, ничего не доказывает о другом, а мёртвая запись AAAA добавляет тайм-аут к каждой попытке. Задокументируйте поведение разрешения для каждого поддерживаемого клиента, а затем тестируйте на устройствах, которые люди действительно используют.

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

Переходите на основании доказательств, затем выведите старую конечную точку

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

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

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

Тест перехода — это сессия приложения через новую конечную точку, а не ping. Как только эта сессия работает и старая конечная точка не регистрирует ни одной авторизованной попытки за полный цикл переподключения, перенос завершён.

Похожие статьи