Ferberget in VPN-rûte-cache jo feroaring? Kontrolearje trije dingen

It leegjen fan de rûte-cache is it earste ynstinkt as in feroaring net trochwurket, en op moderne Linux is it fergriemde muoite: de globale IPv4-rûte-cache waard jierren lyn fuorthelle, dat ip route show cache printsjeet neat en der is neat te wiskjen. De tastân dy’t jo ferrifelet wennet ien laach heger: yn in socket, in NAT-mapping, in resolver of in netwurkbehearder dy’t it âlde profyl opnij tapast hat. Trije fragen skiede dy gefallen: komt it ferkearde paad út in nije flow of in âlde ferbining, cachet jo platfoarm rûtes hielendal, en sit de tastân yn ’e rûteleas of derboppe. Beäntwurdzje se foardat jo in ynterface weromsette.

Kontrôle ien: komt it âlde paad út in nije flow?

In fêstige ferbining hâldt de rûte wêrmei’t er makke waard. Dêrom oerlibbet in SSH-sesje oer de tunnel in feroaring fan ’e rûtetabel, wylst in nije sesje daliks it nije paad nimt, en dêrom betsjut «de feroaring die neat» faak «de âlde socket hâldt it noch». Test mei in nij proses, net mei it finster dat jo al iepen hawwe.

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

It lêste kommando printsjeet it adres dat de nije ferbining eins berikt hat, wat de goedkeapste manier is om it echte paad te sjen sûnder in statusfinster te betrouwen. Fergelykje it mei it boarneadres dat de nammeromte of de ynterface brûke moatten hie.

As in farske flow it juste paad nimt en de âlde net weromkomt, stopje dan mei nei de rûteleas te sjen. De rûte wie goed; de sesje wie âld.

Kontrôle twa: hâldt jo platfoarm hielendal in rûte-cache?

Op Linux is it antwurd nee, yn ’e betsjutting dy’t de measte gidsen bedoele. Der is gjin globale bestimming-cache om fuort te smiten, en de fermelding per socket dy’t in keazen rûte hâldt, wurdt mei de socket frijlitten. De cache-seksje fan ’e ip-route-hantlieding beskriuwt histoarysk gedrach, net eat dat jo op in hjoeddeiske kernel leegje kinne.

Oare platfoarmen ferskille, en dêr giet it kopiearjen fan advys mis. Windows hâldt in bestimming-cache dy’t jo mei netsh interface ip delete destinationcache skjinmeitsje kinne. BSD en macOS litte sykopdrachten per bestimming sjen fia route -n get, en har caches ferrinne neffens har eigen skema. In kommando dat op ien fan dizze wurket, docht op Linux hielendal neat, dêrom liket deselde oplossing te mislearjen foar de helte fan ’e minsken dy’t it probearje.

In NAT- of conntrack-tabel is gjin rûte-cache, al makket er itselde symptoom. In flow dy’t foar jo feroaring oerset waard, hâldt syn oersetting, en conntrack -L sil it sjen litte lang nei’t it rûtebelied fierder gien is. Dat is ferâldere tastân, mar it wiskjen fan rûtes rekket it net.

Kontrôle trije: sit de tastân yn ’e rûteleas of derboppe?

Lês de hjoeddeiske sykopdracht foardat jo eat oars lêze: ip route get foar de bestimming, dan itselde kommando mei from en it boarneadres, dan ip rule show. As dy trije oerienkomme mei wat jo bedoelden, is de rûteleas net de laach om te reparearjen, en kaam de ferâldere waarnimming earne oars wei.

Trije gewoane fertochten sitte boppe de rûteleas. In netwurkbehearder kin in rûte út in bewarre profyl wer ynstallearje sekonden neidat jo it wiskje, dat jo feroaring liket werom te kommen; kontrolearje nmcli connection show --active en de tastân fan ’e ienheid foardat jo de tabel wer bewurkje. In resolver-cache jout in âld adres werom, wat op in rûteflater liket oant jo deselde namme freegje mei in ark dat de cache omrint. In ferbiningspool fan in applikaasje hâldt in wurkjende socket nei de âlde bestimming en freget de kernel nea om in nij beslút.

Wat de trije antwurden jo liede litte

Set de antwurden byinoar en de reparaasje seit himsels meast. In nije flow dy’t it ferkearde paad nimt op in platfoarm sûnder rûte-cache betsjut dat it belied echt ferkeard is, dus lês de regels en de tabel dy’t de tunnel ynstallearre hat. In nije flow dy’t it juste paad nimt wylst de âlde sesje fêstrint betsjut dat de applikaasje of de socket it probleem is. Korrekte rûtes mei in brutsen waarnimming yn beide gefallen betsjut dat de tastân boppe de rûteleas is.

Wjerstean de algemiene ferfersking. It werstarten fan ’e netwurkstapel of it wiskjen fan elke rûte op in masine waans standertrûte de tunnel is, kin krekt de ferbining ôfsnije dy’t jo brûke om it te reparearjen, en it ferneatiget it bewiis dat sein hie hokker laach mislearre.

As jo dochs eat wiskje moatte, wiskje dan it lytste ding dat by de diagnoaze past: de sockets fan ien proses, ien conntrack-ynskriuwing, de resolver-cache. Werhelje dan deselde farske-flow-test en skriuw op wat feroare is.

Hâld de trije tastannen apart yn jo notysjes

Bewarre konfiguraasje, hjoeddeiske sykopdracht en waarnommen flow binne trije ferskillende feiten, en se yn «de cache» ferienigje is wat de fout dreech reprodusearber makket. Skriuw it profyl of de ienheid op dy’t de rûte besit, de útfier fan ip route get, en de boarne en bestimming fan ’e echte ferbining.

Skriuw dêrby it platfoarm en de klantferzje, want in reparaasje dy’t in Windows-bestimming-cache skjinmakket is gjin reparaasje dy’t jildt foar in Linux-host, en in proseduere dy’t tusken de twa kopiearre wurdt, leart de ferkearde les. As jo it probleem oan immen oars jouwe, litte dy trije regels dy de mislearjende tastân reprodusearje ynstee fan te rieden.