Публичный IP сменился, и VPN перестал пропускать трафик

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

Пройдите четыре проверки по порядку и остановитесь на первой, которая не удалась.

Какой адрес действительно изменился

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

Спросите конкретно: изменился внешний источник, внутренний адрес туннеля или и то и другое? Только первое объясняет партнёра, который продолжает отправлять на путь, которого больше нет.

Пусть протокол сам разбирается с перемещением

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

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

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Очистите устаревшую внешнюю привязку

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

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

Проверьте заново новым запросом

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

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

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