Skjuler en VPN-rute-cache endringen din? Sjekk tre ting

Å tømme rute-cachen er den første innskytelsen når en endring ikke trer i kraft, og på moderne Linux er det bortkastet arbeid: den globale IPv4-rute-cachen ble fjernet for år siden, så ip route show cache skriver ut ingenting, og det er ingenting å rydde. Tilstanden som lurer deg, bor ett lag høyere: i en socket, en NAT-mapping, en resolver eller en nettverksbehandler som har brukt den gamle profilen på nytt. Tre spørsmål skiller de tilfellene: kommer den gale veien fra en ny flyt eller en gammel forbindelse, cacher plattformen din ruter i det hele tatt, og er tilstanden i rutingen eller over den. Svar på dem før du nullstiller et grensesnitt.

Sjekk én: kommer den gamle veien fra en ny flyt?

En etablert forbindelse beholder ruten den ble opprettet med. Derfor overlever en SSH-økt over tunnelen en endring i rutetabellen, mens en ny økt straks tar den nye veien, og derfor betyr «endringen gjorde ingenting» ofte «den gamle socketen holder fortsatt på den». Test med en ny prosess, ikke med vinduet du allerede har åpent.

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

Den siste kommandoen skriver ut adressen den nye forbindelsen faktisk nådde, og det er den billigste måten å se den virkelige veien på uten å stole på et statusvindu. Sammenlign den med kildeadressen som namespace eller grensesnittet skulle ha brukt.

Hvis en fersk flyt tar den riktige veien og den gamle ikke kommer seg, slutt å se på rutingen. Ruten var riktig; økten var gammel.

Sjekk to: har plattformen din i det hele tatt en rute-cache?

På Linux er svaret nei, i den betydningen de fleste veiledninger mener. Det finnes ingen global destinasjonscache å kaste, og oppføringen per socket som holder en valgt rute, frigis sammen med socketen. Cache-avsnittet i ip-route-håndboken beskriver historisk atferd, ikke noe du kan tømme på en gjeldende kjerne.

Andre plattformer er annerledes, og det er her kopiering av råd går galt. Windows har en destinasjonscache du kan rydde med netsh interface ip delete destinationcache. BSD og macOS viser oppslag per destinasjon via route -n get, og cacheene deres utløper etter sin egen plan. En kommando som virker på en av disse, gjør absolutt ingenting på Linux, og derfor ser den samme rettingen ut til å mislykkes for halvparten av dem som prøver den.

En NAT- eller conntrack-tabell er ikke en rute-cache, selv om den gir samme symptom. En flyt som ble oversatt før endringen din, beholder oversettelsen sin, og conntrack -L vil vise den lenge etter at rutingpolitikken har flyttet seg videre. Det er utdatert tilstand, men rydding av ruter rører den ikke.

Sjekk tre: er tilstanden i rutingen eller over den?

Les det gjeldende oppslaget før du leser noe annet: ip route get for destinasjonen, deretter samme kommando med from og kildeadressen, deretter ip rule show. Hvis disse tre stemmer med det du hadde tenkt, er ikke rutingen laget som skal rettes, og den utdaterte observasjonen kom fra et annet sted.

Tre vanlige mistenkte sitter over rutingen. En nettverksbehandler kan installere en rute på nytt fra en lagret profil sekunder etter at du sletter den, så endringen din ser ut til å komme tilbake; sjekk nmcli connection show --active og enhetens tilstand før du redigerer tabellen igjen. En resolver-cache returnerer en gammel adresse, noe som ser ut som en rutingfeil helt til du spør på samme navn med et verktøy som omgår cachen. En applikasjons tilkoblingspool holder en fungerende socket til den gamle destinasjonen og spør aldri kjernen om en ny avgjørelse.

Hva de tre svarene lar deg konkludere

Legg svarene sammen, og reparasjonen sier som regel seg selv. En ny flyt som tar den gale veien på en plattform uten rute-cache betyr at politikken virkelig er feil, så les reglene og tabellen som tunnelen installerte. En ny flyt som tar den riktige veien mens den gamle økten står fast, betyr at problemet er applikasjonen eller socketen. Riktige ruter med en ødelagt observasjon i begge tilfeller betyr at tilstanden er over rutingen.

Motstå den generiske oppfriskingen. Å starte nettverksstakken på nytt eller slette hver rute på en maskin der standardruten er tunnelen, kan kutte nettopp den forbindelsen du bruker for å rette det, og det ødelegger beviset som ville ha sagt hvilket lag som sviktet.

Hvis du først må rydde noe, rydd det minste som passer til diagnosen: én prosess' sockets, én conntrack-oppføring, resolverens cache. Gjenta deretter den samme fersk-flyt-testen og skriv ned hva som endret seg.

Hold de tre tilstandene atskilt i notatene dine

Lagret konfigurasjon, gjeldende oppslag og observert flyt er tre forskjellige fakta, og å slå dem sammen til «cachen» er det som gjør feilen vanskelig å gjenskape. Skriv ned profilen eller enheten som eier ruten, utdataene fra ip route get, og kilden og destinasjonen til den faktiske forbindelsen.

Noter plattformen og klientversjonen ved siden av, fordi en retting som rydder en Windows-destinasjonscache, ikke er en retting som gjelder for en Linux-vert, og en prosedyre som kopieres mellom de to, lærer feil lekse. Når du overlater problemet til noen andre, lar de tre linjene dem gjenskape den feilende tilstanden i stedet for å gjette.