VPN падает после обновления DHCP? Сравните адреса

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

Начните с клиента, который отвалился

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

Записывайте хронологию по ходу, а не держите в памяти. Метки времени разных инструментов редко совпадают идеально, и само расхождение иногда и есть объяснение.

Сравните четыре значения вокруг события

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

Что обновление может и чего не может изменить

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

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

Когда клиент не может адаптироваться

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

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

Повторите событие, прежде чем винить его

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

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