WireGuard: нет маршрута к пиру после смены подсети — два выхода

Рукопожатие свежее в wg show, конечная точка верна, ключи никогда не менялись — а ping всё равно сообщает, что маршрута к пиру нет. Вы сменили подсеть туннеля час назад. Этот симптом — подпись несовпадения префикса, а не проблемы с ключами: WireGuard завершил рукопожатие, а затем отбросил данные, потому что адрес источника больше не соответствует тому, что примет принимающий пир. Есть два разумных способа провести смену подсети, и они отказывают в разных местах.

Два способа провести изменение, и сколько стоит каждый

Вариант A — перенумерация на месте: измените адрес интерфейса, диапазоны пиров, маршруты и каждую копию конфигурации, затем перезагрузите. Вариант B — построить второй интерфейс на новом префиксе рядом со старым, перенести пиров и удалить старый интерфейс, когда трафик действительно переехал.

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

Что должно меняться вместе на вашей стороне

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

Сравнивайте настроенное с работающим, а не полагайтесь на одно из двух:

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

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

Для работающего интерфейса примените изменённый файл, не разбирая туннель:

wg syncconf wg0 <(wg-quick strip wg0)

Это обновляет пиров и диапазоны на месте. Это не обновляет адрес интерфейса или маршруты, потому что они не являются настройками WireGuard — поэтому перенумерация по-прежнему требует пересоздания интерфейса или смены адреса через ip, а затем повторной проверки маршрутизации.

Что должно меняться вместе на дальнем конце

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

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

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

Устаревшие копии, переживающие вашу правку

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

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

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

Выбор между двумя, и проверка переключения

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

При любом варианте изменение завершено, когда проходят четыре проверки: рукопожатие свежее, поиск маршрута для назначения с новым префиксом называет туннель, нагрузка в несколько сотен байт проходит в обе стороны, и то же самое верно после перезапуска хоста или менеджера. Официальное руководство wg(8) служит справкой о том, что AllowedIPs означает в каждом направлении, и его стоит перечитать, прежде чем расширять диапазон, чтобы симптом исчез.

• Свежее рукопожатие и нет данных: посмотрите AllowedIPs у получателя, прежде чем трогать ключи.
• Поиск маршрута указывает не на тот интерфейс: маршрутом владеет менеджер или контейнер, а не ваш файл.
• Числовой адрес в порядке, а имя хоста сломано: старая ссылка, а не петля маршрутизации.
• Изменение завершено только тогда, когда после перезапуска всё ещё используется новый префикс.