Перенос VPN-сервера на новый публичный IP: что проверить в первую очередь
Замена на месте и параллельный переход ломаются в разных местах. Проверьте конфигурации, NAT и сертификаты, затем посмотрите, как каждый клиент разрешает имя.
Переназначение адреса занимает минуту. Следующая неделя — это место, где перенос ломается, и редко там, где подсказывает консоль провайдера. Новый публичный IP упоминается в четырёх местах: сокет, на котором слушает демон, якорь доверия, который проверяют клиенты, каждое правило, называющее старый адрес, и DNS-запись, которая их связывает. Два переноса выглядят с панели управления одинаково, но ведут себя совершенно по-разному: переназначить адрес на машине, которой вы управляете, или поднять второй endpoint и перевести клиентов на него. Проверки ниже ставят дешёвые сбои первыми, и каждый раздел указывает, к какому переносу он относится.
Замена на месте и параллельный переход — разные задачи
Замена на месте сохраняет хост, ключи, таблицу маршрутизации и список пользователей; меняется только адрес. Это делает переназначение плавающего IP, и у нескольких провайдеров гость этого вообще не замечает, потому что трансляция происходит перед инстансом. Пересборка или переназначение провайдером жёстче: гость видит изменение, и всё, что держало старое значение в кеше, узнаёт о нём в тот же момент.
Параллельный endpoint — это второй хост, выполняющий ту же работу. Соберите его, проверьте одним профилем и оставьте старый отвечать, пока новый не докажет себя на реальном пути. Цена — состояние. Без общих записей peer, отзывов и логирования у вас две сети, которые случайно делят имя.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
Найдите каждое место, где записан старый адрес
Начните с текстового поиска, потому что конфигурационные файлы — лёгкая половина. Ищите в конфигурации демона, фрагментах брандмауэра, целях мониторинга и любом сгенерированном клиентском пакете на диске. Включите адрес IPv6, если публикуете такой; перенос, следящий только за A-записью, оставляет двухстековых клиентов на старом пути.
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsЗатем пройдитесь по ядру, потому что работающая система держит адрес в местах, о которых не упоминает ни один файл. Статическое правило NAT источника, запись ipset, адрес bind и запись conntrack живут дольше правки конфигурации, которая их удалила, а некоторые переживают и перезагрузку, потому что вернулись из сохранённого набора правил. На уровень выше группы безопасности провайдера, цели балансировщика и проверки мониторинга вообще не на вашей файловой системе.
Запишите инвентаризацию до того, как что-то менять; она же служит скриптом отката.
Клиенты по имени хоста восстанавливаются; клиенты с буквальным IP замолкают
Если клиенты приходят на сервер по имени хоста, переход — в основном проблема DNS, и TTL, заданный вчера, решает, насколько всё будет плохо. Резолверы кешируют, stub-резолверы кешируют ещё раз, и многие клиенты ищут имя только при новом соединении, поэтому установленный туннель сохраняет свой начальный адрес.
Если endpoint — буквальный адрес, ничего не разрешается заново и ничто не пишет жалобу. WireGuard хранит разрешённый адрес сокета: Endpoint = vpn.example.net:51820 становится IP в тот момент, когда запускается wg-quick up, и остаётся этим IP, пока вы его не измените. OpenVPN снисходительнее: он разрешает имя хоста remote при подключении и с resolv-retry infinite снова пробует DNS при переподключении. С буквальным IP оба продолжают набирать машину, которой больше нет.
Людей вводит в заблуждение зеркальная картина. Клиент, уже указывающий на новый адрес, пока старый слушатель ещё отвечает, проходит любую проверку, которую вы делаете со своего рабочего стола. Меня это тоже обмануло: новый endpoint поднялся на телефоне с первой попытки, а клиент со старым профилем обнаружился только когда старый слушатель был выключен намного позже.
Доверие не переезжает вместе с адресом
WireGuard отделяет идентичность от доступности, что делает перенос адреса почти бесплатным. Peer'ы идентифицируются открытым ключом, а endpoint — это лишь то, куда пакеты идут сейчас; хост обновляет endpoint peer'а по адресу источника последнего аутентифицированного пакета. Простаивающему peer'у всё же нужна причина говорить с новым местом, и адрес он узнаёт только когда его сессия стареет, а повторные попытки handshake терпят неудачу в заметном месте. Краткое руководство WireGuard описывает поле endpoint.
Серверы на TLS — обратный случай. Сертификат привязан к имени, и клиент, набирающий адрес, сравнивает набранное с альтернативными именами субъекта. Подключитесь по IP к сертификату, несущему только DNS SAN, и проверка не пройдёт: имени, которое использовал клиент, в сертификате нет. Перевыпуск с IP SAN исправляет это одно соединение и делает следующий перенос хуже. Сохранение имени хоста в профиле и verify-x509-name на месте удерживает проверку строгой, пока адрес под ним меняется.
Затем проверьте, к чему привязан демон; сокет, прикреплённый к старому адресу, тихо отказывает. Сервер OpenVPN, запущенный с local 203.0.113.10, отказывается подниматься, как только адрес исчезает, а слушатель на 0.0.0.0 следует за изменением бесплатно. NAT делится так же: MASQUERADE следует за любым адресом, который машина имеет сейчас, а статический SNAT --to-source 203.0.113.10 продолжает переписывать на адрес, которым вы больше не владеете, поэтому обратный трафик исчезает. Если новый адрес приходит с другим upstream-шлюзом, проверьте rp_filter: фильтрация обратного пути отбрасывает обратный трафик, приходящий на интерфейс, которого ядро не ожидало.
Порядок перехода и доказательства, что он сработал
Снизьте TTL за день, поднимите новый слушатель и докажите его профилем, который есть только у вас. Проверка изнутри той же сети почти ничего не доказывает, поэтому используйте телефон в сотовой сети и проверьте то, что туннель должен переносить, а не ping до endpoint.
Следите за обоими адресами всё окно. wg show all latest-handshakes на новом хосте или файл состояния OpenVPN скажет, сколько peer'ов действительно переехало. Когда у нового endpoint'а есть ожидаемые peer'ы, а у старого только отставшие, выведите старый слушатель из эксплуатации, удалите устаревшее правило NAT и уберите адрес из брандмауэра провайдера. Удаление старого слушателя — это шаг, который пропускают, и он закрывает щель, где устаревший профиль всё ещё доходит до старой сети.
Запишите триггер отката письменно до начала: если после согласованного окна у нового endpoint'а нет handshake ни от одного реального клиента, восстановите старый адрес и прекратите раздачу профилей. Затем повторите поиск и подтвердите, что ни один слушатель не привязан к выведенному адресу. Две вещи переходят в следующий перенос: имя хоста в клиентском профиле, чтобы следующее изменение было правкой DNS, и инвентаризация, хранящаяся рядом с заметками о восстановлении сервера.