Verstoppt en VPN-Route-Cache Är Ännerung? Préift dräi Saachen

De Route-Cache ze leeren ass den éischten Instinkt, wann eng Ännerung net wierkt, an op modernem Linux ass et verschwend Aarbecht: de globale IPv4-Route-Cache gouf viru Joren ewechgeholl, dofir dréckt ip route show cache näischt an et gëtt näischt ze läschen. Den Zoustand, deen Iech täuscht, lieft eng Schicht méi héich: an engem Socket, enger NAT-Zuordnung, engem Resolver oder engem Netzwierkmanager, deen den ale Profil erëm ugewannt huet. Dräi Froen trennen déi Fäll: kënnt de falsche Wee aus engem neie Floss oder enger aler Verbindung, cachet Är Plattform iwwerhaapt Routen, an ass den Zoustand am Routing oder driwwer. Äntwert se, ier Dir eng Interface zrécksetzt.

Kontroll eng: kënnt den ale Wee aus engem neie Floss?

Eng etabléiert Verbindung behält d'Route, mat där se erstallt gouf. Dofir iwwerlieft eng SSH-Sessioun iwwer den Tunnel eng Ännerung vun der Routentabelle, während eng nei Sessioun direkt den neie Wee hëlt, an dofir heescht «d'Ännerung huet näischt gemaach» dacks «den ale Socket hält se nach». Test mat engem neie Prozess, net mat dem Fënster, dat Dir schonn op hutt.

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

Déi lescht Kommando dréckt d'Adress aus, déi déi nei Verbindung tatsächlech erreecht huet, an dat ass dee bëllegste Wee, de richtege Wee ze gesinn, ouni engem Statusfënster ze vertrauen. Vergläicht se mat der Quelladress, déi den Namespace oder d'Interface sollt benotzt hunn.

Wann en neie Floss de richtege Wee hëlt an den ale sech net erhëlt, hält op, op d'Routing ze kucken. D'Route war richteg; d'Sessioun war al.

Kontroll zwee: hält Är Plattform iwwerhaapt e Route-Cache?

Op Linux ass d'Äntwert nee, am Sënn, deen déi meescht Guide mengen. Et gëtt keen globale Destinatiounscache fir ewechzegeheien, an den Antrag pro Socket, deen eng gewielte Route hält, gëtt mam Socket fräiginn. D'Cache-Sektioun vun der ip-route-Handbuch beschreift historescht Verhalen, net eppes, wat Dir op engem aktuelle Kernel leere kënnt.

Aner Plattformen ënnerscheede sech, an hei geet d'Kopéiere vun de Rotschléi schif. Windows hält en Destinatiounscache, deen Dir mat netsh interface ip delete destinationcache ka botzen. BSD a macOS weisen Sich pro Destinatioun iwwer route -n get, an hir Cache lafen no hirem eegene Plang of. Eng Kommando, déi op enger vun dësen funktionnéiert, mécht op Linux absolut näischt, dofir schéngt déiselwecht Léisung fir d'Halschent vun de Leit ze feelen, déi se probéieren.

Eng NAT- oder conntrack-Tabelle ass keen Route-Cache, obwuel se déiselwecht Symptomer mécht. En Floss, dee virun Ärer Ännerung iwwersat gouf, behält seng Iwwersetzung, an conntrack -L weist en nach laang, nodeems d'Routingpolitik weidergezunn ass. Dat ass en ale Zoustand, awer d'Routen ze läschen hëlt en net un.

Kontroll dräi: ass den Zoustand am Routing oder driwwer?

Liest déi aktuell Sich, ier Dir eppes anescht liest: ip route get fir d'Destinatioun, duerno déiselwecht Kommando mat from an der Quelladress, duerno ip rule show. Wann déi dräi mat Ärer Absicht iwwereneestëmmen, ass d'Routing net d'Schicht fir ze reparéieren, an déi al Observatioun koum vun anerer Plaz.

Dräi üblech Verdächteger sëtzen iwwer dem Routing. En Netzwierkmanager kann eng Route aus engem gespäicherte Profil Sekonnen nodeems Dir se geläscht hutt, nei installéieren, dofir schéngt Är Ännerung zréckzekommen; préift nmcli connection show --active an den Zoustand vun der Unitéit, ier Dir d'Tabelle nach eng Kéier ännert. En Resolver-Cache gëtt eng al Adress zréck, wat wéi en Routingfehler ausgesäit, bis Dir deen nämmlechen Numm mat engem Tool froogt, dat de Cache ëmgeet. De Verbindungspool vun enger Applikatioun hält en funktionéierende Socket op déi al Destinatioun a freet den Kernel ni no enger neier Entscheedung.

Wat déi dräi Äntwerten Iech schléissen loossen

Setzt d'Äntwerten zesummen, an d'Reparatur seet sech meeschtens selwer. En neie Floss, deen de falsche Wee op enger Plattform ouni Route-Cache hëlt, bedeit, datt d'Politik wierklech falsch ass, also liest d'Reegelen an d'Tabelle, déi den Tunnel installéiert huet. En neie Floss, deen de richtege Wee hëlt, während déi al Sessioun stockt, bedeit, datt d'Applikatioun oder de Socket de Problem ass. Richtig Routen mat enger gebrochener Observatioun a béide Fäll bedeiten, datt den Zoustand iwwer dem Routing ass.

Stitt der allgemenger Erfrëschung entgéint. Den Netzwierkstack nei starten oder all Route op enger Maschinn läschen, där hire Standardwee den Tunnel ass, kann genee déi Verbindung ofschneiden, déi Dir benotzt, fir et ze reparéieren, an et zerstéiert de Beweis, deen Iech gesot hätt, wéi eng Schicht versot huet.

Wann Dir wierklech eppes misst botzen, botzt dat klengst, wat zur Diagnos passt: d'Sockete vun engem Prozess, een conntrack-Antrag, den Resolver-Cache. Widderhëlt duerno dee selwechten neie-Floss-Test a schreift op, wat sech geännert huet.

Halt déi dräi Zouständ an Ären Notizen getrennt

Gespäichert Konfiguratioun, aktuell Sich an observéierte Floss sinn dräi verschidde Fakten, an se zu «dem Cache» ze verschmëlzen ass dat, wat de Fehler schwéier reproduzéierbar mécht. Schreift de Profil oder d'Unitéit op, déi d'Route besëtzt, d'Ausgab vun ip route get, an d'Quell an d'Destinatioun vun der richteger Verbindung.

Schreift der niewendrun d'Plattform an d'Client-Versioun op, well eng Reparatur, déi en Windows-Destinatiounscache botzt, keng Reparatur ass, déi op engem Linux-Host gëllt, an e Prozedur, deen tëscht den zwou kopéiert gëtt, léiert déi falsch Lektioun. Wann Dir de Problem un een aneren iwwergitt, loossen déi dräi Zeilen hien de fehlerhaften Zoustand reproduzéieren, amplaz ze roden.