VPN mówi, że jest połączony, ale domyślna trasa jest martwa

Klient zgłasza połączenie, ikona w zasobniku wygląda normalnie, a nic się nie ładuje. Zaczęło się zaraz po przejściu z Wi-Fi na kabel albo zaraz po zakończeniu aktualizacji dystrybucji. Zepsuł się nie profil, ale stan zbudowany dla poprzedniego połączenia bazowego. Jądro nadal ma domyślną trasę wskazującą urządzenie tunelowe, którego nikt nie posiada, albo resolver wciąż wymienia serwery na łączu, które zniknęło. Oba błędy wyglądają jak martwa sieć i oba da się naprawić na miejscu.

Nieaktualne elementy były błędne już wcześniej, zanim je zauważyłeś. Wyjęcie kabla tylko je ujawniło.

Zapytaj jądro, dokąd pójdzie pakiet

Listy tras są trudne do czytania, bo wyliczają wszystko, co zna system, łącznie z wpisami, które już nie obowiązują. Wyszukanie trasy odpowiada na jedyne pytanie warte postawienia: które urządzenie niesie właśnie ten pakiet teraz. Jeśli odpowiedź wskazuje urządzenie tunelowe, jądro go użyje, nawet gdy za nim nie ma żadnego żywego procesu klienta, a pakiet wpada w interfejs, którego nikt nie utrzymuje. Jeśli odpowiedź wskazuje kartę Ethernet, podczas gdy klient upiera się, że połączenie jest aktywne, tunel istnieje, ale stracił wybór, co jest zwykłym skutkiem przejścia z sieci bezprzewodowej na przewodową.

Uruchom wyszukiwanie dwa razy, raz dla adresu publicznego i raz dla wewnętrznego, bo polityka podzielonego tunelu może jeden poprowadzić uczciwie, a drugi zgubić.

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

Resolver też trzyma martwe łącze

Na hoście z systemd-resolved serwery DNS należą do łączy, a nie do jednej globalnej listy. Łącze VPN, które padło, może przez jakiś czas pozostać zarejestrowane ze swoimi serwerami, a wtedy każde wyszukiwanie czeka na adres, który nigdy nie odpowie. To opóźnienie wygląda jak martwa sieć i wysyła ludzi do oglądania tras, gdy trasa jest w porządku.

resolvectl status
resolvectl query intranet.example.com

Przeczytaj bloki według łączy i ustal, które łącze posiada daną domenę. Tunel, który jest podniesiony, ale nie jest właścicielem domeny wewnętrznej, przekazuje nazwy wewnętrzne do publicznego resolvera, a objaw jest nie do odróżnienia od błędu routingu.

Napraw rejestrację, a nie /etc/resolv.conf. W obecnych instalacjach Ubuntu i Fedory ta ścieżka jest dowiązaniem symbolicznym do stanu działania resolvera, więc zmiana jest albo ignorowana, albo nadpisywana przy następnym zdarzeniu sieciowym.

VPN nigdy nie startuje sam

NetworkManager podnosi VPN ponad połączeniem bazowym i uczy się, za którym podążać, z connection.secondaries na tej bazie. Dokumentacja ustawień połączenia mówi wprost, że automatyczne łączenie nie jest zaimplementowane dla profili VPN. To cały mechanizm stojący za tą klasą awarii: zmień bazę, a VPN trzeba ponownie sparować albo włączyć ręcznie.

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

Gdy aktywna lista pokazuje bazę bez VPN, tunel w ogóle nie jest aktywny, a trasa nigdy nie została zainstalowana, a nie pozostała przestarzała. Gdy aktywacja skarży się, że nie ma połączenia źródłowego, baza, z którą była sparowana, zniknęła, więc najpierw napraw bazę lub parowanie i przestań ponownie próbować VPN.

Aktualizacja może zgubić ustawienia bez komunikatu

Aktualizacja dystrybucji zastępuje klienta i często jego wtyczkę NetworkManager, podczas gdy zapisany profil zachowuje nazwy właściwości, z którymi został zapisany. Wszystko, czego nowa wtyczka już nie rozpoznaje, jest po cichu pomijane. Profil nadal się aktywuje i urządzenie nadal się pojawia, ale trasa, która dawniej przychodziła razem z nim, już nie przychodzi.

Ręcznie pisane haki też się przesuwają. Skrypt, który instalował trasę w przewidywalnym momencie starej sekwencji, może teraz działać, zanim interfejs istnieje, albo po tym, jak klient już przekroczył limit czasu.

Porównuj żywy profil z wtyczką, którą naprawdę masz, a nie z zachowaniem, które pamiętasz. Jeśli klucz zniknął z dokumentacji, przenieś pracę do skryptu dyspozytora lub obsługiwanego zamiennika, zamiast przywracać starą właściwość.

Trzy stany, trzy różne naprawy

Zdecyduj, w jakim stanie jesteś, zanim czegokolwiek dotkniesz, bo restart niszczy dowody, a usterka wraca przy następnej zmianie sieci.

Zakończ jednym wyszukaniem dla adresu publicznego, jednym dla adresu wewnętrznego i jednym zapytaniem o nazwę. Jeśli adresy działają, a nazwa nie, pozostałą usterką jest zakres domeny w resolverze, a tablica tras nigdy nie była problemem.