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 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

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.

Kapcsolódó cikkek