VPN siger forbundet, men intet routes: to steder at kigge

En tunnel kan melde sig forbundet, mens intet når den, og de to fakta bor forskellige steder. Det ene er rutetabellen, som stadig kan sende pakker til en enhed, ingen ejer. Det andet er resolveren, som stadig kan liste en server på et link, der er væk. Netværksændringen beskadigede ikke profilen, den efterlod tilstanden fra den forrige forbindelse forældreløs, og reparationen afhænger af, hvilken af de to du faktisk kigger på.

Spørg først kernen, hvilken enhed den ville bruge

En ruteoversigt viser, hvad der findes; et ruteopslag viser, hvad der ville ske. Spørg til en offentlig adresse og læs enhedsnavnet i svaret, for det ene felt afgør, om pakken når noget nyttigt. Når svaret nævner en tunnelenhed, giver kernen pakkerne videre til den, selv om ingen klientproces stadig kører bag det interface. Når svaret nævner den fysiske adapter, mens klienten påstår at være forbundet, er tunnelen oppe og blot ikke den valgte vej.

Det andet tilfælde er det sædvanlige, efter at et kabel har afløst trådløst, og det præsenterer sig som en ødelagt VPN.

ip route show default
ip route get 203.0.113.9

Læs derefter standardposterne, for en rute tilføjet af den forrige basisforbindelse kan overleve et linkskifte og stå foran den nye. En standardrute gennem en enhed, der er nede, er værre end ingen standardrute, fordi kernen stadig foretrækker den. Læg mærke til metrikken ved hver post, for den rækkefølge forklarer præferencen hurtigere end interfacenavnene.

Læs derefter resolveren pr. link, ikke pr. fil

Navneopløsning bærer sin egen tilstand og sin egen forældelse. En resolver, der lister DNS-servere pr. link, beholder serverne for et tunnellink, der er nede men stadig registreret, og hvert opslag venter så på en server, der ikke vil svare. Symptomet er et netværk, der føles dødt, mens rutetabellen ser perfekt ud.

Undersøg tilstanden pr. link i stedet for filen, for på mange distributioner er den fil et symbolsk link ind i resolveren, og at redigere den gør enten intet eller bliver hurtigt overskrevet. Se, hvilket link der ejer hvilke servere og hvilket søgedomæne, og spørg så, om tunnellinket overhovedet stadig bør være registreret. Hvis ikke, deaktiver den forbindelse, der ejer det, i stedet for at redigere genereret tilstand i hånden. Et navn, der opløses, mens ruteopslaget sender pakker andre steder hen, er en tredje og selvstændig fejl.

resolvectl status
resolvectl query app.internal.example

Hvis adresser opløses og forbindelser fejler, er resolveren i orden og ruten ikke. Hvis adresser slet ikke opløses, er dette det rigtige sted at begynde.

Hvordan en forældet rute overlever ændringen

Klienten ejer ikke netværket alene. På en NetworkManager-vært aktiveres en VPN-profil oven på en basisforbindelse, og forbindelsesindstillingerne lader den basis navngive den VPN, der skal følge den. Når basis skiftes, fordi en anden profil bliver foretrukket, følger tunnelen med over på den nye basis eller står uden nogen.

En VPN-profil rejser sig ikke selv, så parringen betyder langt mere end profilens egen autoconnect-indstilling.

Læs den aktive liste og noter, hvilken basis der er oppe, før du rører tunnelen. Hvis basis står på listen og tunnelen ikke, mangler ruten snarere end at være forældet, og rettelsen er aktivering. Hvis aktiveringen af tunnelen klager over, at der ikke findes nogen kildeforbindelse, er den basis, den var parret med, væk, så få den først op eller reparer parringen i stedet for at prøve tunnelen igen. At prøve en profil igen, hvis forælder er væk, giver den samme fejl hver gang, hvilket er et nyttigt signal og ikke en plage.

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

Skeln forældet tilstand fra en manglende forælder

Tre tilstande forklarer næsten hver rapport, og hver kræver sin egen reparation. En standardrute gennem en enhed, der stadig findes, men ikke længere bærer tunnelen, er forældet tilstand, ryddet enten ved at slette posten eller ved at genstarte den ansvarlige profil. En tunnelenhed, hvis klientproces er forsvundet, er en oprydningsfejl, så afbrydelsesvejen fortjener opmærksomheden frem for rutetabellen. Slet ingen tunnelenhed betyder, at forælderen eller parringen mangler, og at rutetabellen aldrig var involveret.

En genstart skjuler, hvilken af de tre du havde, og det er netop derfor, den føles som en rettelse.

Spørg efter reparationen kernen om en offentlig og en intern adresse, og slå derefter et internt navn op. Når adressen virker og navnet ikke, har du fundet et domæneomfangsproblem i resolveren og ikke et routingproblem. Noter, hvilken tilstand du fandt, for den næste netværksændring vil genskabe den, du lod være.