VPN seier tilkopla, men standardruta er daud

Klienten rapporterer tilkopla, ikonet i systemkurva ser normalt ut, og ingenting blir lasta. Det byrja rett etter at du gjekk frå Wi-Fi til kabel, eller rett etter at ein distribusjonsoppgradering var ferdig. Det som gjekk i stykker er ikkje profilen, men tilstanden som vart bygd for den førre basistilkoplinga. Kjernen har framleis ei standardrute som peikar på ein tunneleining ingen eig, eller resolveren listar framleis opp tenarar på ei lenkje som er borte. Båe feila ser ut som eit daudt nettverk, og båe kan reparerast på staden.

Dei forelda bitane var allereie feil før du la merke til dei. Å dra ut ein kabel gjorde dei berre synlege.

Spør kjernen kvar ein pakke ville gå

Rutelister er vanskelege å lese fordi dei rammar opp alt systemet veit, inkludert oppføringar som ikkje lenger gjeld. Eit ruteoppslag svarar på det einaste spørsmålet som er verdt å stille: kva eining ber akkurat denne pakken akkurat no. Viss svaret nemner ei tunneleining, vil kjernen bruke ho sjølv om det ikkje finst nokon levande klientprosess bak, og pakken fell ned i eit grensesnitt ingen vedlikeheld. Viss svaret nemner Ethernet-adapteren medan klienten insisterer på at han er oppe, finst tunnelen, men har mista valet, som er det vanlege utfallet av å bytte frå trådlaust til kabel.

Køyr oppslaget to gonger, éin gong for ei offentleg adresse og éin gong for ei intern, fordi ein politikk for delt tunnel kan rute den eine ærleg og sleppe den andre.

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

Resolveren held òg på den daude lenkja

På ein vert med systemd-resolved høyrer DNS-tenarar til lenkjer i staden for éi global liste. Ei VPN-lenkje som er nede kan bli ståande registrert med tenarane sine ei stund, og då ventar kvart oppslag på ei adresse som aldri vil svare. Den forseinkinga kjennest som eit daudt nettverk og sender folk til å sjå på ruter når ruta er i orden.

resolvectl status
resolvectl query intranet.example.com

Les blokkene per lenkje og finn ut kva lenkje som eig domenet det gjeld. Ein tunnel som er oppe, men ikkje eig det interne domenet, videresender interne namn til den offentlege resolveren, og symptomet kan ikkje skiljast frå ein rutefeil.

Reparer registreringa i staden for /etc/resolv.conf. På dagens Ubuntu- og Fedora-installasjonar er den stien ei symbolsk lenkje til køyretidstilstanden til resolveren, så ei endring blir anten ignorert eller overskriven ved neste nettverkshending.

Ein VPN startar aldri av seg sjølv

NetworkManager heisar ein VPN oppå ei basistilkopling, og han lærer kva han skal følgje frå connection.secondaries på den basen. referansen for tilkoplingsinnstillingar seier uttrykkeleg at autoconnect ikkje er implementert for VPN-profilar. Det er heile mekanismen bak denne feilklassen: endre basen, og VPN-en må parast på nytt eller aktiverast manuelt.

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

Når den aktive lista viser basen utan VPN-en, er tunnelen ikkje aktiv i det heile, og ruta vart aldri installert i staden for å bli ståande forelda. Når aktiveringa klagar over at det ikkje finst noka kjeldekopling, er basen han var para med borte, så reparer basen eller paringa først og slutt å prøve VPN-en igjen.

Ei oppgradering kan miste innstillingar utan ei melding

Oppgradering av ein distribusjon erstattar klienten og ofte NetworkManager-pluginen, medan den lagra profilen held på eigenskapsnamna han vart skriven med. Alt den nye pluginen ikkje lenger kjenner igjen, blir hoppa over i stillheit. Profilen blir framleis aktivert og eininga viser seg framleis, men ruta som brukte å kome med henne, kjem aldri.

Handskrivne krokur flyttar seg òg. Eit skript som installerte ei rute på eit føreseieleg tidspunkt i den gamle sekvensen, kan no køyre før grensesnittet finst, eller etter at klienten alt har tima ut.

Samanlikn den levande profilen med pluginen du faktisk har, i staden for med åtferda du hugsar. Viss ein nøkkel er borte frå dokumentasjonen, flytt arbeidet til eit dispatcher-skript eller ei støtta erstatning i staden for å gjenopprette den gamle eigenskapen.

Tre tilstandar, tre ulike reparasjonar

Bestem kva tilstand du er i før du rører noko, fordi ein omstart øydelegg bevisa og feilen kjem tilbake ved neste nettverksendring.

Avslutt med eitt oppslag for ei offentleg adresse, eitt for ei intern adresse og éin namneforespurnad. Viss adressene verkar og namnet ikkje, er den gjenverande feilen domenesvidde i resolveren, og rutetabellen var aldri problemet.