VPN ibilbide-cacheak zure aldaketa ezkutatzen al du? Egiaztatu hiru gauza

Ibilbide-cachea hustutzea da aldaketak eraginik ez duenean lehen bulkada, eta Linux modernoan alferrikako ahalegina da: IPv4 ibilbide-cache globala duela urte kendu zen, beraz ip route show cache ez du ezer inprimatzen eta ez dago ezer garbitzeko. Engainatzen zaituen egoera maila bat gorago bizi da: socket batean, NAT mapatze batean, resolver batean edo profil zaharra berriro aplikatu duen sare-kudeatzaile batean. Hiru galderak bereizten dituzte kasu horiek: bide okerra fluxu berri batetik edo konexio zahar batetik datorren, zure plataformak ibilbideak cachean gordetzen dituen ala ez, eta egoera bideratzean edo haren gainean dagoen. Erantzun itzazu interfaze bat berrezarri aurretik.

Lehen egiaztapena: bide zaharra fluxu berri batetik dator?

Ezarritako konexioak sortu zen ibilbidea mantentzen du. Horregatik tunelaren gaineko SSH saio batek bideratze-taularen aldaketa gainditzen du, saio berri batek berehala bide berria hartzen duen bitartean, eta horregatik «aldaketak ez zuen ezer egin» askotan «socket zaharrak oraindik eusten dio» esan nahi du. Probatu prozesu berri batekin, jada irekita duzun leihoarekin ez.

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

Azken komandoak konexio berriak benetan lortu duen helbidea inprimatzen du, eta hori da benetako bidea ikusteko modurik merkeena, egoera-leihoari fidatu gabe. Konparatu izen-espazioak edo interfazeak erabili behar zuen iturburu-helbidearekin.

Fluxu berri batek bide zuzena hartzen badu eta zaharrak errekuperatzen ez badu, utzi bideratzeari begiratzeari. Ibilbidea zuzena zen; saioa zaharra zen.

Bigarren egiaztapena: zure plataformak ibilbide-cachea gordetzen du?

Linuxen erantzuna ez da, gida gehienek esan nahi duten zentzuan. Ez dago botatzeko helmugako cache globalik, eta aukeratutako ibilbidea gordetzen duen socket-mailako sarrera socketarekin batera askatzen da. ip-route eskuliburuaren cache atalak historiko den portaera deskribatzen du, ez uneko nukleo batean hustu dezakezun zerbait.

Beste plataforma batzuk desberdinak dira, eta hemen huts egiten du aholkuak kopiatzeak. Windowsek helmugako cachea gordetzen du, netsh interface ip delete destinationcache erabiliz garbi dezakezuna. BSDk eta macOSek helmugako bilaketak erakusten dituzte route -n get bidez, eta haien cacheak beren egutegiaren arabera iraungitzen dira. Haietako batean funtzionatzen duen komando batek ezer ez du egiten Linuxen, eta horregatik konponbide berak porrot egiten duela dirudi probatzen duten erdiek.

NAT edo conntrack taula bat ez da ibilbide-cachea, sintoma bera sortzen badu ere. Zure aldaketaren aurretik itzulitako fluxu batek bere itzulpena mantentzen du, eta conntrack -L-k erakutsiko du bideratze-politika aurrera joan ondoren ere. Hori egoera zaharkitua da, baina ibilbideak garbitzeak ez dio ukituko.

Hirugarren egiaztapena: egoera bideratzean edo haren gainean dago?

Irakurri uneko bilaketa beste ezer irakurri aurretik: ip route get helmugarako, gero komando bera from eta iturburu-helbidearekin, gero ip rule show. Hiru horiek zure asmoarekin bat badatoz, bideratzea ez da konpondu beharreko geruza, eta behaketa zaharkitua beste nonbaitetik etorri da.

Hiru susmagarri ohiko bideratzearen gainean esertzen dira. Sare-kudeatzaile batek gordetako profil batetik ibilbide bat berriro instala dezake ezabatu eta segundo batzuetara, beraz zure aldaketa itzultzen ari dela dirudi; egiaztatu nmcli connection show --active eta unitatearen egoera taula berriro editatu aurretik. Resolver baten cacheak helbide zaharra itzultzen du, eta hori bideratze-hutsegitea dirudi cachea hausten duen tresna batekin izen bera kontsultatu arte. Aplikazio baten konexio-poolak helmuga zaharrarekin socket funtzionala mantentzen du eta ez dio nukleoari inoiz erabaki berririk eskatzen.

Zer ondorioztatzen uzten dizuten hiru erantzunek

Bildu erantzunak eta konponketak normalean bere burua adierazten du. Ibilbide-cachearik gabeko plataforma batean bide okerra hartzen duen fluxu berri batek politika benetan okerra dela esan nahi du, beraz irakurri tunelak instalatutako arauak eta taula. Saio zaharra trabatzen den bitartean bide zuzena hartzen duen fluxu berri batek aplikazioa edo socketa dela esan nahi du. Bi kasuetan ibilbide zuzenak behaketa hautsia izateak egoera bideratzearen gainean dagoela esan nahi du.

Egin aurre berritze orokorrari. Sare-pila berrabiarazteak edo lehenetsitako ibilbidea tunela duen makinan ibilbide guztiak ezabatzeak hain zuzen konpontzeko erabiltzen ari zaren konexioa moz dezake, eta zein geruzak huts egin zuen esango zukeen froga suntsitzen du.

Zerbait garbitu behar baduzu, garbitu diagnostikoarekin bat datorren gauzarik txikiena: prozesu bateko socketak, conntrack sarrera bat, resolverraren cachea. Gero errepikatu fluxu berriko proba bera eta idatzi zer aldatu den.

Eduki hiru egoerak bereizita zure oharretan

Gordetako konfigurazioa, uneko bilaketa eta behatutako fluxua hiru gertaera desberdin dira, eta «cachean» elkartzea da hutsegitea erreproduzitzen zaila egiten duena. Idatzi ibilbidearen jabea den profila edo unitatea, ip route get-ren irteera eta benetako konexioaren iturburua eta helmuga.

Idatzi haien ondoan plataforma eta bezeroaren bertsioa, Windowseko helmuga-cachea garbitzen duen konponbidea ez baita Linux ostalari baterako konponbidea, eta bien artean kopiatutako prozedurak okerreko ikasgaia irakasten du. Arazoa beste bati ematen diozunean, hiru lerro horiei esker hutsegiten duen egoera erreproduzitu ahal izango du, asmatu beharrean.