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, а збережений профіль зберігає ті назви властивостей, з якими був записаний. Усе, що новий плагін більше не розпізнає, пропускається мовчки. Профіль і далі активується, і пристрій і далі з’являється, але маршрут, який раніше приходив разом із ним, більше не приходить.

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

Порівнюйте робочий профіль із тим плагіном, який у вас справді є, а не з поведінкою, яку ви пам’ятаєте. Якщо ключ зник із документації, перенесіть роботу до скрипту диспетчера або до підтримуваної заміни, замість того щоб відновлювати стару властивість.

Три стани, три різні виправлення

Визначте, у якому стані ви перебуваєте, перш ніж щось чіпати, бо перезавантаження знищує докази, і несправність повертається під час наступної зміни мережі.

Завершіть одним пошуком для публічної адреси, одним для внутрішньої адреси і одним запитом імені. Якщо адреси працюють, а ім’я ні, залишкова несправність — це область домену в резолвері, і таблиця маршрутів тут ніколи не була проблемою.