Verbergt een VPN-routcache je wijziging? Controleer drie dingen

De routcache legen is het eerste instinct als een wijziging niet doorwerkt, en op modern Linux is het verspilde moeite: de globale IPv4-routcache is jaren geleden verwijderd, dus ip route show cache drukt niets af en er is niets op te ruimen. De toestand die je misleidt, woont een laag hoger: in een socket, een NAT-toewijzing, een resolver of een netwerkbeheerder die het oude profiel opnieuw heeft toegepast. Drie vragen scheiden die gevallen: komt het verkeerde pad uit een nieuwe flow of een oude verbinding, cachet je platform überhaupt routes, en zit de toestand in de routering of erboven. Beantwoord ze voordat je een interface reset.

Controle één: komt het oude pad uit een nieuwe flow?

Een bestaande verbinding houdt de route waarmee hij is gemaakt. Daarom overleeft een SSH-sessie over de tunnel een wijziging van de routetabel, terwijl een nieuwe sessie meteen het nieuwe pad neemt, en daarom betekent ‘de wijziging deed niets’ vaak ‘de oude socket houdt hem nog vast’. Test met een nieuw proces, niet met het venster dat je al open hebt.

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

De laatste opdracht drukt het adres af dat de nieuwe verbinding werkelijk heeft bereikt, en dat is de goedkoopste manier om het echte pad te zien zonder een statusvenster te vertrouwen. Vergelijk het met het bronadres dat de namespace of de interface had moeten gebruiken.

Als een nieuwe flow het juiste pad neemt en de oude niet herstelt, stop dan met naar de routering te kijken. De route was juist; de sessie was oud.

Controle twee: houdt je platform überhaupt een routcache bij?

Op Linux is het antwoord nee, in de zin die de meeste handleidingen bedoelen. Er is geen globale bestemmingcache om weg te gooien, en de vermelding per socket die een gekozen route houdt, wordt met de socket vrijgegeven. De cachesectie van de ip-route-handleiding beschrijft historisch gedrag, niet iets wat je op een huidige kernel kunt legen.

Andere platforms verschillen, en hier gaat het kopiëren van advies mis. Windows houdt een bestemmingcache bij die je met netsh interface ip delete destinationcache kunt wissen. BSD en macOS tonen opzoekingen per bestemming via route -n get, en hun caches verlopen volgens hun eigen schema. Een opdracht die op een van deze werkt, doet op Linux helemaal niets, en daarom lijkt dezelfde oplossing te mislukken bij de helft van de mensen die hem proberen.

Een NAT- of conntrack-tabel is geen routcache, al levert hij hetzelfde symptoom op. Een flow die vóór je wijziging is vertaald, houdt zijn vertaling, en conntrack -L toont hem nog lang nadat het routeringsbeleid verder is gegaan. Dat is verouderde toestand, maar het wissen van routes raakt hem niet.

Controle drie: zit de toestand in de routering, of erboven?

Lees de huidige opzoeking voordat je iets anders leest: ip route get voor de bestemming, dan dezelfde opdracht met from en het bronadres, dan ip rule show. Als die drie overeenkomen met wat je bedoelde, is de routering niet de laag om te repareren, en kwam de verouderde waarneming ergens anders vandaan.

Drie gebruikelijke verdachten zitten boven de routering. Een netwerkbeheerder kan een route uit een opgeslagen profiel opnieuw installeren seconden nadat je hem verwijdert, dus lijkt je wijziging terug te komen; controleer nmcli connection show --active en de status van de unit voordat je de tabel opnieuw bewerkt. Een resolvercache geeft een oud adres terug, wat op een routeringsfout lijkt tot je dezelfde naam opvraagt met een hulpmiddel dat de cache omzeilt. De verbindingenpool van een toepassing houdt een werkende socket naar de oude bestemming en vraagt de kernel nooit om een nieuwe beslissing.

Wat de drie antwoorden je laten concluderen

Zet de antwoorden bij elkaar en de reparatie zegt zichzelf meestal. Een nieuwe flow die het verkeerde pad neemt op een platform zonder routcache betekent dat het beleid echt onjuist is, dus lees de regels en de tabel die de tunnel heeft geïnstalleerd. Een nieuwe flow die het juiste pad neemt terwijl de oude sessie vastloopt, betekent dat de toepassing of de socket het probleem is. Juiste routes met een kapotte waarneming in beide gevallen betekent dat de toestand boven de routering zit.

Weersta de generieke verversing. De netwerkstack herstarten of elke route wissen op een machine waarvan de standaardroute de tunnel is, kan precies de verbinding afsnijden die je gebruikt om het te repareren, en het vernietigt het bewijs dat je had verteld welke laag heeft gefaald.

Als je toch iets moet wissen, wis dan het kleinste dat bij de diagnose past: de sockets van één proces, één conntrack-vermelding, de resolvercache. Herhaal daarna dezelfde verse-flow-test en schrijf op wat er is veranderd.

Houd de drie toestanden gescheiden in je notities

Opgeslagen configuratie, huidige opzoeking en waargenomen flow zijn drie verschillende feiten, en ze samenpersen tot ‘de cache’ is wat de fout moeilijk reproduceerbaar maakt. Noteer het profiel of de unit die de route bezit, de uitvoer van ip route get, en de bron en bestemming van de werkelijke verbinding.

Noteer daarnaast het platform en de clientversie, want een oplossing die een Windows-bestemmingcache wist, is geen oplossing die op een Linux-host van toepassing is, en een procedure die tussen beide wordt gekopieerd, leert de verkeerde les. Als je het probleem aan iemand anders overdraagt, kunnen die drie regels de faaltoestand reproduceren in plaats van te gokken.