Klient hlásí připojení, ikona v oznamovací oblasti vypadá normálně a nic se nenačítá. Začalo to hned poté, co jste přešli z Wi-Fi na kabel, nebo hned po dokončení aktualizace distribuce. Nepokazil se profil, ale stav vytvořený pro předchozí základní připojení. Jádro stále má výchozí trasu ukazující na tunelové zařízení, které nikomu nepatří, nebo resolver stále uvádí servery na spoji, který zmizel. Obě poruchy vypadají jako mrtvá síť a obě lze opravit na místě.

Zastaralé kusy byly špatné už předtím, než jste si jich všimli. Vytáhnutí kabelu je jen zviditelnilo.

Zeptejte se jádra, kam paket půjde

Výpisy tras se čtou obtížně, protože vypisují všechno, co systém zná, včetně položek, které už neplatí. Vyhledání trasy odpovídá na jedinou otázku, která stojí za to: které zařízení právě teď nese tento konkrétní paket. Pokud odpověď jmenuje tunelové zařízení, jádro ho použije, i když za ním není žádný živý klientský proces, a paket spadne do rozhraní, které nikdo neudržuje. Pokud odpověď jmenuje adaptér Ethernet, zatímco klient tvrdí, že je spojení aktivní, tunel existuje, ale ztratil volbu, což je obvyklý výsledek přechodu z bezdrátové na drátovou síť.

Spusťte vyhledání dvakrát, jednou pro veřejnou adresu a jednou pro vnitřní, protože zásada rozděleného tunelu může jednu směrovat poctivě a druhou zahodit.

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

Resolver drží mrtvý spoj také

Na hostiteli se systemd-resolved patří DNS servery spojům, ne jednomu globálnímu seznamu. VPN spoj, který spadl, může nějakou dobu zůstat registrovaný se svými servery, a pak každé vyhledání čeká na adresu, která nikdy neodpoví. To zpoždění působí jako mrtvá síť a posílá lidi k trasám, i když je trasa v pořádku.

resolvectl status
resolvectl query intranet.example.com

Přečtěte bloky po spojích a určete, který spoj vlastní dotyčnou doménu. Tunel, který je nahoře, ale není vlastníkem vnitřní domény, předává vnitřní jména veřejnému resolveru, a příznak je nerozeznatelný od poruchy směrování.

Opravte registraci, ne /etc/resolv.conf. V současných instalacích Ubuntu a Fedory je tato cesta symbolickým odkazem do běhového stavu resolveru, takže úprava se buď ignoruje, nebo se přepíše při další síťové události.

VPN nikdy nezačne sama

NetworkManager zvedá VPN nad základní připojení a učí se, které má následovat, z connection.secondaries na tomto základu. Referenční příručka nastavení připojení výslovně uvádí, že automatické připojování není pro profily VPN implementováno. To je celý mechanismus za touto třídou poruch: změňte základ a VPN se musí znovu spárovat nebo ručně aktivovat.

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

Když aktivní seznam ukazuje základ bez VPN, tunel není vůbec aktivní a trasa nebyla nikdy nainstalována, místo aby zůstala zastaralá. Když si aktivace stěžuje, že neexistuje zdrojové připojení, základ, se kterým byl spárován, zmizel, takže nejprve opravte základ nebo spárování a přestaňte VPN znovu zkoušet.

Aktualizace může zahodit nastavení bez zprávy

Aktualizace distribuce nahradí klienta a často i jeho plugin pro NetworkManager, zatímco uložený profil si ponechá názvy vlastností, se kterými byl zapsán. Vše, co nový plugin už nerozpozná, se tiše přeskočí. Profil se stále aktivuje a zařízení se stále objevuje, ale trasa, která dřív přicházela s ním, už nepřichází.

Ručně psané háčky se také posouvají. Skript, který instaloval trasu v předvídatelném okamžiku staré posloupnosti, teď může běžet dřív, než rozhraní existuje, nebo poté, co klient už vypršel.

Porovnávejte živý profil s pluginem, který skutečně máte, ne s chováním, které si pamatujete. Pokud klíč z dokumentace zmizel, přesuňte práci do skriptu dispečera nebo do podporované náhrady, místo abyste obnovovali starou vlastnost.

Tři stavy, tři různé opravy

Rozhodněte, v jakém stavu jste, než se čehokoli dotknete, protože restart ničí důkazy a porucha se vrátí při další síťové změně.

What the lookup showsWhat it meansRepair
A default route via a device that exists but is unusedLeftover route from an earlier activationRemove the stale entry, or bounce the profile that installed it
A tunnel device with no client processThe client skipped its cleanupFix the disconnect path, then clear the leftover device state
No tunnel device and no active profileMissing base connection or broken pairingBring up the base, then pair the VPN with it again

Skončete jedním vyhledáním pro veřejnou adresu, jedním pro vnitřní adresu a jedním dotazem na jméno. Pokud adresy fungují a jméno ne, zbývající porucha je rozsah domény v resolveru a tabulka tras nikdy nebyla problémem.

Související články