VPN sier tilkoblet, men standardruten er død

Klienten rapporterer tilkoblet, ikonet i systemkurven ser normalt ut, og ingenting lastes. Det begynte rett etter at du gikk fra Wi-Fi til kabel, eller rett etter at en distribusjonsoppgradering var ferdig. Det som gikk i stykker er ikke profilen, men tilstanden som ble bygget for den forrige basistilkoblingen. Kjernen har fortsatt en standardrute som peker på en tunnelenhet ingen eier, eller resolveren lister fortsatt opp servere på en lenke som er borte. Begge feilene ser ut som et dødt nettverk, og begge kan repareres på stedet.

De foreldede bitene var allerede feil før du la merke til dem. Å trekke ut en kabel gjorde dem bare synlige.

Spør kjernen hvor en pakke ville gå

Rutelister er vanskelige å lese fordi de ramser opp alt systemet vet, inkludert oppføringer som ikke lenger gjelder. Et ruteoppslag svarer på det eneste spørsmålet som er verdt å stille: hvilken enhet bærer akkurat denne pakken akkurat nå. Hvis svaret nevner en tunnelenhet, vil kjernen bruke den selv om det ikke finnes noen levende klientprosess bak den, og pakken faller ned i et grensesnitt ingen vedlikeholder. Hvis svaret nevner Ethernet-adapteren mens klienten insisterer på at den er oppe, finnes tunnelen, men har mistet valget, som er det vanlige utfallet av å bytte fra trådløst til kablet.

Kjør oppslaget to ganger, én gang for en offentlig adresse og én gang for en intern, fordi en policy for delt tunnel kan rute den ene ærlig og slippe den andre.

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

Resolveren beholder også den døde lenken

På en vert med systemd-resolved tilhører DNS-servere lenker i stedet for én global liste. En VPN-lenke som er nede kan bli stående registrert med serverne sine en stund, og da venter hvert oppslag på en adresse som aldri vil svare. Den forsinkelsen føles som et dødt nettverk og sender folk til å se på ruter når ruten er i orden.

resolvectl status
resolvectl query intranet.example.com

Les blokkene per lenke og finn ut hvilken lenke som eier domenet det gjelder. En tunnel som er oppe, men ikke eier det interne domenet, videresender interne navn til den offentlige resolveren, og symptomet kan ikke skilles fra en rutingfeil.

Reparer registreringen i stedet for /etc/resolv.conf. På dagens Ubuntu- og Fedora-installasjoner er den stien en symbolsk lenke til resolverens kjøretidstilstand, så en endring blir enten ignorert eller overskrevet ved neste nettverkshendelse.

En VPN starter aldri av seg selv

NetworkManager heiser en VPN oppå en basistilkobling, og den lærer hvilken den skal følge fra connection.secondaries på den basen. referansen for tilkoblingsinnstillinger sier uttrykkelig at autoconnect ikke er implementert for VPN-profiler. Det er hele mekanismen bak denne feilklassen: endre basen, og VPN-en må pares på nytt eller aktiveres manuelt.

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

Når den aktive listen viser basen uten VPN-en, er tunnelen ikke aktiv i det hele tatt, og ruten ble aldri installert i stedet for å være blitt stående foreldet. Når aktiveringen klager over at det ikke finnes noen kildeforbindelse, er basen den var paret med borte, så reparer basen eller paringen først og slutt å prøve VPN-en igjen.

En oppgradering kan miste innstillinger uten en melding

Oppgradering av en distribusjon erstatter klienten og ofte NetworkManager-pluginen, mens den lagrede profilen beholder egenskapsnavnene den ble skrevet med. Alt den nye pluginen ikke lenger kjenner igjen, hoppes over i stillhet. Profilen aktiveres fortsatt og enheten vises fortsatt, men ruten som pleide å komme med den, kommer aldri.

Håndskrevne kroker flytter seg også. Et skript som installerte en rute på et forutsigbart tidspunkt i den gamle sekvensen, kan nå kjøre før grensesnittet finnes, eller etter at klienten allerede har timet ut.

Sammenlign den levende profilen med pluginen du faktisk har, i stedet for med oppførselen du husker. Hvis en nøkkel er borte fra dokumentasjonen, flytt arbeidet til et dispatcher-skript eller en støttet erstatning i stedet for å gjenopprette den gamle egenskapen.

Tre tilstander, tre ulike reparasjoner

Bestem hvilken tilstand du er i før du rører noe, fordi en omstart ødelegger bevisene og feilen kommer tilbake ved neste nettverksendring.

Avslutt med ett oppslag for en offentlig adresse, ett for en intern adresse og én navneforespørsel. Hvis adressene virker og navnet ikke, er den gjenstående feilen domeneomfang i resolveren, og rutetabellen var aldri problemet.