VPN сообщает, что подключён, но маршрут по умолчанию мёртв

Клиент сообщает о подключении, значок в трее выглядит обычно, а ничего не загружается. Это началось сразу после перехода с Wi-Fi на кабель или сразу после завершения обновления дистрибутива. Сломался не профиль, а состояние, построенное для предыдущего базового подключения. В ядре всё ещё есть маршрут по умолчанию на туннельное устройство, которым никто не владеет, либо резолвер по-прежнему перечисляет серверы на интерфейсе, который исчез. Оба отказа выглядят как мёртвая сеть, и оба можно исправить на месте.

Устаревшие части были неверны ещё до того, как вы это заметили. Отключение кабеля лишь сделало их заметными.

Спросите у ядра, куда пойдёт пакет

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

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

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

Резолвер тоже хранит мёртвый интерфейс

На хосте с systemd-resolved DNS-серверы принадлежат интерфейсам, а не одному глобальному списку. Интерфейс VPN, который упал, может какое-то время оставаться зарегистрированным со своими серверами, и тогда каждый запрос ждёт адрес, который никогда не ответит. Эта задержка ощущается как мёртвая сеть и отправляет людей смотреть маршруты, когда маршрут в порядке.

resolvectl status
resolvectl query intranet.example.com

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

Исправляйте регистрацию, а не /etc/resolv.conf. В текущих установках Ubuntu и Fedora этот путь — символическая ссылка на состояние резолвера во время работы, поэтому правка либо игнорируется, либо перезаписывается при следующем сетевом событии.

VPN никогда не запускается сам

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

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

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

Обновление может потерять настройки без сообщения

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

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

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

Три состояния, три разных исправления

Определите, в каком состоянии вы находитесь, прежде чем что-либо трогать, потому что перезагрузка уничтожает доказательства, и неисправность возвращается при следующем изменении сети.

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