A VPN azt mondja, kapcsolódva van, de az alapértelmezett útvonal halott
A Wi-Fi-ről Ethernetre váltás az útvonalat és a feloldót a régi alagúton hagyhatja. Olvassa el a két állapotot külön, majd javítsa a rosszat.
A kliens kapcsolódott állapotot jelez, a tálcán lévő ikon normálisnak tűnik, és semmi sem töltődik be. Közvetlenül azután kezdődött, hogy Wi-Fi-ről kábelre váltott, vagy közvetlenül egy disztribúció-frissítés befejeződése után. Nem a profil tört el, hanem az az állapot, amelyet az előző alapkapcsolat számára építettek. A kernelnek még mindig van egy alapértelmezett útvonala, amely egy senki által nem birtokolt alagúteszközre mutat, vagy a feloldó még mindig olyan kapcsolaton listáz szervereket, amely eltűnt. Mindkét hiba halott hálózatnak látszik, és mindkettő helyben javítható.
Az elavult darabok már azelőtt rosszak voltak, hogy észrevette volna őket. A kábel kihúzása csak láthatóvá tette őket.
Kérdezze meg a kernelt, hová menne egy csomag
Az útvonallistákat nehéz olvasni, mert mindent felsorolnak, amit a rendszer ismer, beleértve azokat a bejegyzéseket is, amelyek már nem érvényesek. Az útvonalkeresés arra az egyetlen kérdésre válaszol, amelyet érdemes feltenni: melyik eszköz viszi most ezt a konkrét csomagot. Ha a válasz alagúteszközt nevez meg, a kernel használni fogja, még akkor is, ha mögötte nincs élő kliensfolyamat, és a csomag olyan interfészbe esik, amelyet senki sem tart karban. Ha a válasz az Ethernet-adaptert nevezi meg, miközben a kliens ragaszkodik ahhoz, hogy kapcsolódva van, az alagút létezik, de elvesztette a kiválasztást, ami a vezeték nélküliről vezetékesre váltás szokásos eredménye.
Futtassa a keresést kétszer, egyszer egy nyilvános címre és egyszer egy belső címre, mert a megosztott alagút szabályzata az egyiket tisztességesen irányíthatja, a másikat pedig elejtheti.
ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40
A feloldó is megtartja a halott kapcsolatot
Egy systemd-resolved gazdagépen a DNS-szerverek kapcsolatokhoz tartoznak, nem egyetlen globális listához. Egy leállt VPN-kapcsolat egy ideig regisztrálva maradhat a szervereivel, és ilyenkor minden keresés olyan címre vár, amely soha nem fog válaszolni. Ez a késleltetés halott hálózatnak érződik, és akkor is az útvonalakhoz küldi az embereket, amikor az útvonal rendben van.
resolvectl status
resolvectl query intranet.example.com
Olvassa el a blokkokat kapcsolatonként, és állapítsa meg, melyik kapcsolat birtokolja a kérdéses tartományt. Az az alagút, amely fel van ugyan, de nem birtokolja a belső tartományt, a belső neveket a nyilvános feloldóhoz továbbítja, és a tünet megkülönböztethetetlen az útválasztási hibától.
Javítsa a regisztrációt, ne /etc/resolv.conf. A jelenlegi Ubuntu- és Fedora-telepítéseken ez az útvonal szimbolikus hivatkozás a feloldó futásidejű állapotára, ezért a szerkesztés vagy figyelmen kívül marad, vagy a következő hálózati eseménynél felülíródik.
A VPN soha nem indul el magától
A NetworkManager egy alapkapcsolat fölé emeli a VPN-t, és onnan tanulja meg, melyiket kövesse, connection.secondaries ezen az alapon. A kapcsolatbeállítások referenciája kifejezetten kimondja, hogy az automatikus kapcsolódás VPN-profilokhoz nincs megvalósítva. Ez a teljes mechanizmus e hibatípus mögött: változtassa meg az alapot, és a VPN-t újra kell párosítani vagy kézzel újra kell aktiválni.
nmcli device status
nmcli connection show --active
nmcli connection up office-vpn
Amikor az aktív lista az alapot VPN nélkül mutatja, az alagút egyáltalán nem aktív, és az útvonal soha nem települt, nem pedig elavultan maradt. Amikor az aktiválás azt panaszolja, hogy nincs forráskapcsolat, az alap, amellyel párosítva volt, eltűnt, ezért először az alapot vagy a párosítást javítsa, és hagyja abba a VPN újrapróbálását.
Egy frissítés üzenet nélkül ejtheti el a beállításokat
Egy disztribúció frissítése lecseréli a klienst és gyakran a NetworkManager-bővítményét is, miközben a mentett profil megtartja azokat a tulajdonságneveket, amelyekkel íródott. Mindent, amit az új bővítmény már nem ismer fel, csendben kihagynak. A profil továbbra is aktiválódik, és az eszköz továbbra is megjelenik, de az útvonal, amely korábban vele érkezett, soha nem érkezik meg.
A kézzel írt horgok is elmozdulnak. Egy szkript, amely a régi sorrend kiszámítható pillanatában telepített egy útvonalat, most már azelőtt futhat, hogy az interfész létezne, vagy miután a kliens már túllépte az időkorlátot.
Hasonlítsa össze az élő profilt azzal a bővítménnyel, amely valóban van, és ne azzal a viselkedéssel, amelyre emlékszik. Ha egy kulcs eltűnt a dokumentációból, vigye át a munkát egy diszpécserszkriptbe vagy egy támogatott helyettesítőbe, ahelyett hogy visszaállítaná a régi tulajdonságot.
Három állapot, három különböző javítás
Döntse el, melyik állapotban van, mielőtt bármihez hozzányúl, mert az újraindítás megsemmisíti a bizonyítékokat, és a hiba a következő hálózati változásnál visszatér.
| 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 |
Fejezze be egy nyilvános címre vonatkozó kereséssel, egy belső címre vonatkozóval és egy névlekérdezéssel. Ha a címek működnek és a név nem, a fennmaradó hiba a tartomány hatóköre a feloldóban, és az útvonaltábla soha nem volt a probléma.