VPN hlásí připojeno, ale výchozí trasa je mrtvá
Přechod z Wi-Fi na Ethernet může nechat trasu i resolver na starém tunelu. Přečtěte oba stavy odděleně a opravte ten, který je špatný.
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 shows | What it means | Repair |
|---|---|---|
| A default route via a device that exists but is unused | Leftover route from an earlier activation | Remove the stale entry, or bounce the profile that installed it |
| A tunnel device with no client process | The client skipped its cleanup | Fix the disconnect path, then clear the leftover device state |
| No tunnel device and no active profile | Missing base connection or broken pairing | Bring 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.