Skjuler en VPN-rute-cache din ændring? Tjek tre ting

At tømme rute-cachen er den første indskydelse, når en ændring ikke slår igennem, og på moderne Linux er det spildt arbejde: den globale IPv4-rute-cache blev fjernet for år tilbage, så ip route show cache udskriver intet, og der er intet at rydde. Den tilstand, der narrer dig, bor et lag længere oppe: i en socket, en NAT-mapping, en resolver eller en netværksmanager, der har anvendt den gamle profil igen. Tre spørgsmål skiller de tilfælde: kommer den forkerte vej fra en ny flow eller en gammel forbindelse, cacher din platform overhovedet ruter, og er tilstanden i routing eller over den. Besvar dem, før du nulstiller en grænseflade.

Tjek et: kommer den gamle vej fra en ny flow?

En etableret forbindelse beholder den rute, den blev oprettet med. Derfor overlever en SSH-session over tunnelen en ændring af rutetabellen, mens en ny session straks tager den nye vej, og derfor betyder »ændringen gjorde ingenting« ofte »den gamle socket holder stadig fast i den«. Test med en ny proces, ikke med det vindue, du allerede har åbent.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

Den sidste kommando udskriver den adresse, den nye forbindelse faktisk nåede, hvilket er den billigste måde at se den reelle vej på uden at stole på et statusvindue. Sammenlign den med den kildeadresse, som namespace eller grænsefladen skulle have brugt.

Hvis en frisk flow tager den rigtige vej, og den gamle ikke kommer sig, så stop med at kigge på routing. Ruten var rigtig; sessionen var gammel.

Tjek to: har din platform overhovedet en rute-cache?

På Linux er svaret nej, i den betydning de fleste guides mener. Der er ingen global destinationscache at smide væk, og den per-socket-post, der holder en valgt rute, frigives sammen med socketten. Cacheafsnittet i ip-route-manualen beskriver historisk adfærd, ikke noget, du kan tømme på en aktuel kerne.

Andre platforme er anderledes, og det er her, kopiering af råd går galt. Windows har en destinationscache, som du kan rydde med netsh interface ip delete destinationcache. BSD og macOS viser opslag per destination via route -n get, og deres caches udløber efter deres egen tidsplan. En kommando, der virker på en af dem, gør absolut intet på Linux, og derfor ser den samme løsning ud til at fejle for halvdelen af dem, der prøver den.

En NAT- eller conntrack-tabel er ikke en rute-cache, selvom den giver det samme symptom. En flow, der blev oversat før din ændring, beholder sin oversættelse, og conntrack -L vil vise den længe efter, at routingpolitikken er flyttet videre. Det er forældet tilstand, men rydning af ruter rører den ikke.

Tjek tre: er tilstanden i routing eller over den?

Læs det aktuelle opslag, før du læser noget andet: ip route get for destinationen, derefter samme kommando med from og kildeadressen, derefter ip rule show. Hvis de tre stemmer med det, du havde tænkt dig, er routing ikke det lag, der skal rettes, og den forældede observation kom fra et andet sted.

Tre almindelige mistænkte sidder over routing. En netværksmanager kan geninstallere en rute fra en gemt profil sekunder efter, at du sletter den, så din ændring ser ud til at vende tilbage; tjek nmcli connection show --active og unit-tilstanden, før du redigerer tabellen igen. En resolvercache returnerer en gammel adresse, hvilket ligner en routingfejl, indtil du spørger på det samme navn med et cachebrydende værktøj. En applikations forbindelsespulje holder en fungerende socket til den gamle destination og spørger aldrig kernen om en ny beslutning.

Hvad de tre svar lader dig konkludere

Læg svarene sammen, og reparationen siger som regel sig selv. En ny flow, der tager den forkerte vej på en platform uden rute-cache, betyder, at politikken virkelig er forkert, så læs reglerne og den tabel, tunnelen installerede. En ny flow, der tager den rigtige vej, mens den gamle session går i stå, betyder, at applikationen eller socketten er problemet. Korrekte ruter med en brudt observation i begge tilfælde betyder, at tilstanden er over routing.

Modstå den generiske opfriskning. At genstarte netværksstakken eller slette hver rute på en maskine, hvis standardrute er tunnelen, kan afbryde netop den forbindelse, du bruger til at rette det, og det ødelægger det bevis, der ville have sagt, hvilket lag der svigtede.

Hvis du endelig skal rydde noget, så ryd det mindste, der passer til diagnosen: én proces' sockets, én conntrack-post, resolverens cache. Gentag derefter den samme friske-flow-test, og skriv ned, hvad der ændrede sig.

Hold de tre tilstande adskilt i dine noter

Gemt konfiguration, aktuelt opslag og observeret flow er tre forskellige fakta, og at presse dem sammen til »cachen« er det, der gør fejlen svær at genskabe. Skriv den profil eller unit ned, der ejer ruten, outputtet af ip route get og kilden og destinationen for den faktiske forbindelse.

Noter platformen og klientversionen ved siden af, fordi en løsning, der rydder en Windows-destinationscache, ikke er en løsning, der gælder for en Linux-vært, og en procedure, der kopieres mellem de to, lærer den forkerte lektie. Når du giver problemet videre til en anden, lader de tre linjer dem genskabe den fejlende tilstand i stedet for at gætte.