Skjuler ein VPN-rute-cache endringa di? Sjekk tre ting

Å tømme rute-cachen er den første innskytelsen når ei endring ikkje trer i kraft, og på moderne Linux er det bortkasta arbeid: den globale IPv4-rute-cachen vart fjerna for år sidan, så ip route show cache skriv ut ingenting, og det er ingenting å rydde. Tilstanden som lurer deg, bur eitt lag høgare: i ein socket, ein NAT-mapping, ein resolver eller ein nettverkshandsamar som har brukt den gamle profilen på nytt. Tre spørsmål skil dei tilfella: kjem den gale vegen frå ein ny flyt eller ei gammal sambinding, cachar plattforma di ruter i det heile, og er tilstanden i rutinga eller over ho. Svar på dei før du nullstiller eit grensesnitt.

Sjekk éin: kjem den gamle vegen frå ein ny flyt?

Ei etablert sambinding held på ruta ho vart oppretta med. Difor overlever ein SSH-økt over tunnelen ei endring i rutetabellen, medan ei ny økt straks tek den nye vegen, og difor tyder «endringa gjorde ingenting» ofte «den gamle socketen held framleis på henne». Test med ein ny prosess, ikkje med vindauget du allereie har ope.

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 skriv ut adressa den nye sambindinga faktisk nådde, og det er den billegaste måten å sjå den verkelege vegen på utan å stole på eit statusvindauge. Samanlikn henne med kjeldeadressa som namespace eller grensesnittet skulle ha brukt.

Viss ein fersk flyt tek den rette vegen og den gamle ikkje kjem seg, slutt å sjå på rutinga. Ruta var rett; økta var gammal.

Sjekk to: har plattforma di i det heile ein rute-cache?

På Linux er svaret nei, i den tydinga dei fleste rettleiarane meiner. Det finst ingen global destinasjonscache å kaste, og oppføringa per socket som held ei vald rute, vert frigjeven saman med socketen. Cache-avsnittet i ip-route-handboka skildrar historisk åtferd, ikkje noko du kan tømme på ein gjeldande kjerne.

Andre plattformer er annleis, og det er her kopiering av råd går gale. Windows har ein destinasjonscache du kan rydde med netsh interface ip delete destinationcache. BSD og macOS viser oppslag per destinasjon via route -n get, og cacheane deira går ut etter sin eigen plan. Ein kommando som verkar på ein av desse, gjer absolutt ingenting på Linux, og difor ser den same rettinga ut til å mislukkast for halvparten av dei som prøver henne.

Ein NAT- eller conntrack-tabell er ikkje ein rute-cache, sjølv om han gir same symptom. Ein flyt som vart omsett før endringa di, held på omsetjinga si, og conntrack -L vil vise han lenge etter at rutingpolitikken har flytta seg vidare. Det er utdatert tilstand, men rydding av ruter rører han ikkje.

Sjekk tre: er tilstanden i rutinga eller over henne?

Les det gjeldande oppslaget før du les noko anna: ip route get for destinasjonen, deretter same kommando med from og kjeldeadressa, deretter ip rule show. Viss desse tre stemmer med det du hadde tenkt, er ikkje rutinga laget som skal rettast, og den utdaterte observasjonen kom frå ein annan stad.

Tre vanlege mistenkte sit over rutinga. Ein nettverkshandsamar kan installere ei rute på nytt frå ein lagra profil sekund etter at du slettar henne, så endringa di ser ut til å kome tilbake; sjekk nmcli connection show --active og tilstanden til eininga før du redigerer tabellen igjen. Ein resolver-cache returnerer ei gammal adresse, noko som ser ut som ein rutingfeil heilt til du spør på same namn med eit verktøy som går utanom cachen. Tilkoplingspoolen til ein applikasjon held ein fungerande socket til den gamle destinasjonen og spør aldri kjernen om ei ny avgjerd.

Kva dei tre svara lèt deg konkludere

Legg svara saman, og reparasjonen seier som regel seg sjølv. Ein ny flyt som tek den gale vegen på ei plattform utan rute-cache tyder på at politikken verkeleg er feil, så les reglane og tabellen som tunnelen installerte. Ein ny flyt som tek den rette vegen medan den gamle økta står fast, tyder på at problemet er applikasjonen eller socketen. Rette ruter med ein øydelagd observasjon i begge tilfelle tyder på at tilstanden er over rutinga.

Motstå den generiske oppfriskinga. Å starte nettverksstakken på nytt eller slette kvar rute på ein maskin der standardruta er tunnelen, kan kutte nettopp den sambindinga du brukar for å rette det, og det øydelegg beviset som ville ha sagt kva lag som svikta.

Viss du først må rydde noko, rydd det minste som passar til diagnosen: soklane til éin prosess, éi conntrack-oppføring, resolver-cachen. Gjenta deretter den same fersk-flyt-testen og skriv ned kva som endra seg.

Hald dei tre tilstandane åtskilde i notata dine

Lagra konfigurasjon, gjeldande oppslag og observert flyt er tre ulike fakta, og å slå dei saman til «cachen» er det som gjer feilen vanskeleg å gjenskape. Skriv ned profilen eller eininga som eig ruta, utdataa frå ip route get, og kjelda og destinasjonen til den faktiske sambindinga.

Noter plattforma og klientversjonen ved sida av, fordi ei retting som ryddar ein Windows-destinasjonscache, er ikkje ei retting som gjeld for ein Linux-vert, og ein prosedyre som vert kopiert mellom dei to, lærer feil lekse. Når du overlèt problemet til nokon andre, lèt dei tre linjene dei gjenskape den feilande tilstanden i staden for å gjette.