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

Сначала спросите у ядра, какое устройство оно выберет

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

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

ip route show default
ip route get 203.0.113.9

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

Затем читайте резолвер по интерфейсам, а не по файлу

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

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

resolvectl status
resolvectl query app.internal.example

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

Как устаревший маршрут переживает изменение

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

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

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

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Отличите устаревшее состояние от отсутствующего родителя

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

Перезагрузка скрывает, какое из трёх состояний у вас было, и именно поэтому она кажется исправлением.

После починки спросите у ядра один публичный и один внутренний адрес, а затем запросите внутреннее имя. Если адрес работает, а имя нет, вы нашли проблему области домена в резолвере, а не проблему маршрутизации. Запишите, какое состояние вы нашли, потому что следующее сетевое изменение воспроизведёт то, которое вы оставили в покое.

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