VPN siger forbundet, men standardruten er død

Klienten rapporterer forbundet, ikonet i proceslinjen ser normalt ud, og intet indlæses. Det begyndte lige efter, du skiftede fra Wi-Fi til kabel, eller lige efter en distributionopgradering blev færdig. Det, der gik i stykker, er ikke profilen, men den tilstand, der blev bygget til den forrige basisforbindelse. Kernen har stadig en standardrute, der peger på en tunneleenhed, som ingen ejer, eller resolveren oplister stadig servere på et link, der er forsvundet. Begge fejl ser ud som et dødt netværk, og begge kan repareres på stedet.

De forældede dele var allerede forkerte, før du lagde mærke til dem. At trække et kabel ud gjorde dem bare synlige.

Spørg kernen, hvor en pakke ville gå hen

Rutelister er svære at læse, fordi de opregner alt, hvad systemet kender, inklusive poster, der ikke længere gælder. Et ruteopslag besvarer det eneste spørgsmål, der er værd at stille: hvilken enhed bærer netop denne pakke lige nu. Hvis svaret nævner en tunneleenhed, vil kernen bruge den, selv om der ikke er nogen levende klientproces bag den, og pakken falder ned i et interface, som ingen vedligeholder. Hvis svaret nævner Ethernet-adapteren, mens klienten insisterer på, at den er oppe, findes tunnelen, men har mistet valget, hvilket er det sædvanlige resultat af at skifte fra trådløst til kablet.

Kør opslaget to gange, én gang for en offentlig adresse og én gang for en intern, fordi en politik for delt tunnel kan route den ene ærligt og tabe den anden.

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

Resolveren beholder også det døde link

På en vært med systemd-resolved hører DNS-servere til link i stedet for til én global liste. Et VPN-link, der er gået ned, kan forblive registreret med sine servere et stykke tid, og så venter hvert opslag på en adresse, der aldrig vil svare. Den forsinkelse føles som et dødt netværk og sender folk til at kigge på ruter, når ruten er fin.

resolvectl status
resolvectl query intranet.example.com

Læs blokkene for hvert link, og find ud af, hvilket link der ejer det pågældende domæne. En tunnel, der er oppe, men ikke ejer det interne domæne, videresender interne navne til den offentlige resolver, og symptomet kan ikke skelnes fra en routingfejl.

Reparér registreringen i stedet for /etc/resolv.conf. På nuværende Ubuntu- og Fedora-installationer er den sti et symbolsk link til resolverens kørselstilstand, så en ændring bliver enten ignoreret eller overskrevet ved næste netværkshændelse.

En VPN starter aldrig af sig selv

NetworkManager rejser en VPN oven på en basisforbindelse, og den lærer, hvilken den skal følge, fra connection.secondaries på den basis. Referencen for forbindelsesindstillinger siger udtrykkeligt, at autoconnect ikke er implementeret for VPN-profiler. Det er hele mekanismen bag denne klasse af fejl: skift basis, og VPN’en skal parres igen eller genaktiveres manuelt.

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

Når den aktive liste viser basis uden VPN’en, er tunnelen slet ikke aktiv, og ruten blev aldrig installeret i stedet for at være blevet efterladt forældet. Når aktiveringen klager over, at der ikke findes nogen kildeforbindelse, er den basis, den blev parret med, forsvundet, så ret først basis eller parringen og stop med at prøve VPN’en igen.

En opgradering kan tabe indstillinger uden en besked

Opgradering af en distribution erstatter klienten og ofte dens NetworkManager-plugin, mens den gemte profil beholder de egenskabsnavne, den blev skrevet med. Alt, hvad det nye plugin ikke længere genkender, springes over i stilhed. Profilen aktiveres stadig, og enheden vises stadig, men den rute, der plejede at komme med den, kommer aldrig.

Håndskrevne hooks flytter sig også. Et script, der installerede en rute på et forudsigeligt tidspunkt i den gamle sekvens, kan nu køre, før interfacet findes, eller efter klienten allerede er timet ud.

Sammenlign den levende profil med det plugin, du faktisk har, i stedet for med den adfærd, du husker. Hvis en nøgle er væk fra dokumentationen, flyt arbejdet til et dispatcher-script eller en understøttet erstatning i stedet for at genskabe den gamle egenskab.

Tre tilstande, tre forskellige reparationer

Afgør, hvilken tilstand du er i, før du rører noget, fordi en genstart ødelægger beviserne, og fejlen vender tilbage ved næste netværksændring.

Slut af med ét opslag for en offentlig adresse, ét for en intern adresse og én navneforespørgsel. Hvis adresserne virker, og navnet ikke gør, er den resterende fejl domæneomfanget i resolveren, og rutetabellen var aldrig problemet.