Kas VPN-i marsruudivahemälu varjab sinu muudatust? Kontrolli kolme asja

Marsruudivahemälu tühjendamine on esimene instinkt, kui muudatus ei jõustu, ja kaasaegses Linuxis on see raisatud vaev: globaalne IPv4 marsruudivahemälu eemaldati aastaid tagasi, seega ip route show cache ei trüki midagi ja midagi pole kustutada. Seisund, mis sind petab, elab ühe kihi kõrgemal: soklis, NAT-vastenduses, resolveris või võrguhalduris, mis rakendas vana profiili uuesti. Kolm küsimust eristavad neid juhtumeid: kas vale tee tuleb uuest voolust või vanast ühendusest, kas sinu platvorm üldse vahemälustab marsruute, ja kas seisund on marsruutimises või sellest kõrgemal. Vasta neile enne liidese lähtestamist.

Esimene kontroll: kas vana tee tuleb uuest voolust?

Loodud ühendus hoiab marsruuti, millega see loodi. Seetõttu elab SSH-seanss tunnelis üle marsruutimistabeli muudatuse, samal ajal kui uus seanss võtab kohe uue tee, ja seetõttu tähendab «muudatus ei teinud midagi» sageli «vana sokkel hoiab seda veel». Testi uue protsessiga, mitte aknaga, mis sul juba lahti on.

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

Viimane käsk trükib aadressi, kuhu uus ühendus tegelikult jõudis, mis on odavaim viis näha tegelikku teed usaldamata olekuakent. Võrdle seda lähteaadressiga, mida nimeruum või liides oleks pidanud kasutama.

Kui värske vool läheb õiget teed ja vana ei taastu, lõpeta marsruutimise vaatamine. Marsruut oli õige; seanss oli vana.

Teine kontroll: kas sinu platvorm üldse hoiab marsruudivahemälu?

Linuxis on vastus ei, selles tähenduses, mida enamik juhendeid mõtleb. Pole globaalset sihtkoha vahemälu, mida ära visata, ja valitud marsruuti hoidv sokli-kirje vabastatakse koos sokliga. ip-route käsiraamatu vahemälu osa kirjeldab ajaloolist käitumist, mitte midagi, mida saad praeguses tuumas tühjendada.

Teised platvormid erinevad ja just siin läheb nõuannete kopeerimine valesti. Windows hoiab sihtkoha vahemälu, mille saad puhastada käsuga netsh interface ip delete destinationcache. BSD ja macOS pakuvad sihtkohapõhiseid otsinguid route -n get kaudu ja nende vahemälud aeguvad oma graafiku järgi. Käsk, mis töötab ühel neist, ei tee Linuxis üldse midagi, seetõttu näib sama parandus ebaõnnestuvat poolel inimestest, kes seda proovivad.

NAT- või conntrack-tabel ei ole marsruudivahemälu, kuigi see tekitab sama sümptomi. Vool, mis tõlgiti enne sinu muudatust, hoiab oma tõlget, ja conntrack -L näitab seda kaua pärast seda, kui marsruutimispoliitika on edasi liikunud. See on vananenud seisund, kuid marsruutide kustutamine ei puuduta seda.

Kolmas kontroll: kas seisund on marsruutimises või sellest kõrgemal?

Loe praegust otsingut enne millegi muu lugemist: ip route get sihtkoha jaoks, seejärel sama käsk koos from ja lähteaadressiga, seejärel ip rule show. Kui need kolm ühtivad sellega, mida kavatsesid, pole marsruutimine parandatav kiht ja vananenud tähelepanek tuli mujalt.

Kolm tavalist kahtlusalust istuvad marsruutimisest kõrgemal. Võrguhaldur võib salvestatud profiilist marsruudi uuesti paigaldada sekundeid pärast selle kustutamist, nii et sinu muudatus näib tagasi pöörduvat; kontrolli nmcli connection show --active ja üksuse olekut enne tabeli uuesti muutmist. Resolveri vahemälu tagastab vana aadressi, mis näeb välja nagu marsruutimise tõrge, kuni küsid sama nime vahemälu mööda mineva tööriistaga. Rakenduse ühenduste bassein hoiab töötavat soklit vana sihtkohani ega küsi tuumalt kunagi uut otsust.

Mida kolm vastust lubavad järeldada

Pane vastused kokku ja parandus ütleb enamasti ise enda välja. Värske vool, mis läheb valele teele platvormil, kus marsruudivahemälu pole, tähendab, et poliitika on tõesti vale, seega loe reegleid ja tabelit, mille tunnel paigaldas. Värske vool, mis läheb õigele teele, samal ajal kui vana seanss takerdub, tähendab, et probleem on rakenduses või soklis. Õiged marsruudid koos katkise tähelepanekuga mõlemal juhul tähendavad, et seisund on marsruutimisest kõrgemal.

Pane vastu üldisele värskendusele. Võrgupinu taaskäivitamine või kõigi marsruutide kustutamine masinas, mille vaikemarsruut on tunnel, võib lõigata läbi just selle ühenduse, mida kasutad parandamiseks, ja hävitab tõendid, mis oleks öelnud, milline kiht ebaõnnestus.

Kui peadki midagi puhastama, puhasta väikseim asi, mis diagnoosiga sobib: ühe protsessi soklid, üks conntrack-kirje, resolveri vahemälu. Seejärel korda sama värske voolu testi ja kirjuta üles, mis muutus.

Hoia kolme seisundit oma märkmetes lahus

Salvestatud konfiguratsioon, praegune otsing ja vaadeldud vool on kolm erinevat fakti, ja nende kokkusurumine «vahemäluks» on see, mis teeb rikke raskesti korratavaks. Kirjuta üles profiil või üksus, millele marsruut kuulub, ip route get väljund ning tegeliku ühenduse lähtekoht ja sihtkoht.

Märgi kõrvale platvorm ja kliendi versioon, sest parandus, mis puhastab Windowsi sihtkoha vahemälu, ei sobi Linuxi hostile, ja nende kahe vahel kopeeritud protseduur õpetab vale õppetunni. Kui annad probleemi kellelegi teisele, lasevad need kolm rida tal rikke seisundit korrata, selle asemel et oletada.