Döljer en VPN-ruttcache din ändring? Kontrollera tre saker

Att tömma ruttcachen är den första instinkten när en ändring inte slår igenom, och på modern Linux är det bortkastat arbete: den globala IPv4-ruttcachen togs bort för år sedan, så ip route show cache skriver inte ut något och det finns inget att rensa. Tillståndet som lurar dig bor ett lager högre: i en socket, en NAT-mappning, en resolver eller en nätverkshanterare som använt den gamla profilen igen. Tre frågor skiljer de fallen: kommer den felaktiga vägen från ett nytt flöde eller en gammal anslutning, cachar din plattform rutter överhuvudtaget, och ligger tillståndet i routingen eller ovanför den. Svara på dem innan du återställer ett gränssnitt.

Kontroll ett: kommer den gamla vägen från ett nytt flöde?

En etablerad anslutning behåller rutten den skapades med. Därför överlever en SSH-session över tunneln en ändring av rutttabellen, medan en ny session direkt tar den nya vägen, och därför betyder ”ändringen gjorde ingenting” ofta ”den gamla socketen håller fortfarande kvar den”. Testa med en ny process, inte med fönstret du redan har öppet.

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

Det sista kommandot skriver ut den adress som den nya anslutningen faktiskt nådde, och det är det billigaste sättet att se den verkliga vägen utan att lita på ett statusfönster. Jämför den med källadressen som namespace eller gränssnittet skulle ha använt.

Om ett färskt flöde tar den riktiga vägen och det gamla inte återhämtar sig, sluta titta på routingen. Rutten var rätt; sessionen var gammal.

Kontroll två: har din plattform överhuvudtaget en ruttcache?

På Linux är svaret nej, i den betydelse de flesta guider menar. Det finns ingen global destinationscache att kasta, och posten per socket som håller en vald rutt frigörs tillsammans med socketen. Cacheavsnittet i ip-route-handboken beskriver historiskt beteende, inte något du kan tömma på en aktuell kärna.

Andra plattformar skiljer sig, och det är här kopiering av råd går fel. Windows har en destinationscache som du kan rensa med netsh interface ip delete destinationcache. BSD och macOS visar uppslag per destination via route -n get, och deras cachar löper ut enligt deras eget schema. Ett kommando som fungerar på en av dessa gör absolut ingenting på Linux, och därför verkar samma åtgärd misslyckas för hälften av dem som provar den.

En NAT- eller conntrack-tabell är inte en ruttcache, även om den ger samma symtom. Ett flöde som översattes före din ändring behåller sin översättning, och conntrack -L visar den långt efter att routingpolicyn har flyttat vidare. Det är inaktuellt tillstånd, men rensning av rutter rör den inte.

Kontroll tre: ligger tillståndet i routingen eller ovanför den?

Läs det aktuella uppslaget innan du läser något annat: ip route get för destinationen, sedan samma kommando med from och källadressen, sedan ip rule show. Om dessa tre stämmer med det du avsåg är routingen inte lagret att åtgärda, och den inaktuella observationen kom någon annanstans ifrån.

Tre vanliga misstänkta sitter ovanför routingen. En nätverkshanterare kan installera om en rutt från en sparad profil sekunder efter att du tar bort den, så din ändring verkar komma tillbaka; kontrollera nmcli connection show --active och enhetens tillstånd innan du redigerar tabellen igen. En resolvercache returnerar en gammal adress, vilket ser ut som ett routingfel tills du frågar efter samma namn med ett verktyg som kringgår cachen. En applikations anslutningspool håller en fungerande socket till den gamla destinationen och frågar aldrig kärnan om ett nytt beslut.

Vad de tre svaren låter dig dra för slutsats

Lägg ihop svaren och reparationen säger oftast sig själv. Ett nytt flöde som tar den felaktiga vägen på en plattform utan ruttcache betyder att policyn verkligen är fel, så läs reglerna och tabellen som tunneln installerade. Ett nytt flöde som tar den riktiga vägen medan den gamla sessionen fastnar betyder att problemet är applikationen eller socketen. Riktiga rutter med en trasig observation i båda fallen betyder att tillståndet ligger ovanför routingen.

Motstå den generiska uppdateringen. Att starta om nätverksstacken eller ta bort varje rutt på en maskin vars standardrutt är tunneln kan kapa just den anslutning du använder för att åtgärda det, och det förstör beviset som skulle ha sagt vilket lager som misslyckades.

Om du måste rensa något, rensa det minsta som passar diagnosen: en process socketar, en conntrack-post, resolverns cache. Upprepa sedan samma färsk-flöde-test och skriv ned vad som ändrades.

Håll de tre tillstånden åtskilda i dina anteckningar

Sparad konfiguration, aktuellt uppslag och observerat flöde är tre olika fakta, och att slå ihop dem till ”cachen” är det som gör felet svårt att återskapa. Skriv ned profilen eller enheten som äger rutten, utdata från ip route get, och källan och destinationen för den faktiska anslutningen.

Anteckna plattformen och klientversionen bredvid, eftersom en åtgärd som rensar en Windows-destinationscache inte är en åtgärd som gäller för en Linux-värd, och en procedur som kopieras mellan de två lär ut fel läxa. När du lämnar problemet till någon annan låter de tre raderna dem återskapa det felande tillståndet i stället för att gissa.