A e fsheh një cache rrugësh VPN ndryshimin tuaj? Kontrolloni tri gjëra

Zbrazja e cache-s së rrugëve është instinkti i parë kur një ndryshim nuk hyn në fuqi, dhe në Linux modern është përpjekje e humbur: cache-i global i rrugëve IPv4 u hoq vite më parë, prandaj ip route show cache nuk shtyp asgjë dhe nuk ka asgjë për të pastruar. Gjendja që ju mashtron jeton një shtresë më lart: në një socket, një hartëzim NAT, një zgjidhës ose një menaxher rrjeti që ka rizbatuar profilin e vjetër. Tri pyetje i ndajnë ato raste: a vjen rruga e gabuar nga një rrjedhë e re apo nga një lidhje e vjetër, a e ruan platforma juaj fare cache-in e rrugëve, dhe a është gjendja në rrugëzim apo mbi të. Përgjigjuni atyre përpara se të rinisni një ndërfaqe.

Kontrolli një: a vjen rruga e vjetër nga një rrjedhë e re?

Një lidhje e vendosur mban rrugën me të cilën u krijua. Prandaj një sesion SSH përmes tunelit i mbijeton një ndryshimi të tabelës së rrugëzimit, ndërsa një sesion i re merr menjëherë rrugën e re, dhe prandaj «ndryshimi nuk bëri asgjë» shpesh do të thotë «socket-i i vjetër ende po e mban». Testoni me një proces të re, jo me dritaren që e keni tashmë të hapur.

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

Komanda e fundit shtyp adresën që lidhja e re arriti në të vërtetë, dhe ky është mënyra më e lirë për të parë rrugën reale pa i besuar një dritareje statusi. Krahasojeni me adresën burimore që namespace ose ndërfaqja duhej të përdorte.

Nëse një rrjedhë e re merr rrugën e saktë dhe e vjetra nuk shërohet, ndaloni së shikuari rrugëzimin. Rruga ishte e saktë; sesioni ishte i vjetër.

Kontrolli dy: a mban platforma juaj fare një cache rrugësh?

Në Linux përgjigjja është jo, në kuptimin që kanë parasysh shumica e udhëzuesve. Nuk ka cache global destinacionesh për të hedhur, dhe zëri për çdo socket që mban një rrugë të zgjedhur lirohet bashkë me socket-in. Seksioni i cache-s në manualin ip-route përshkruan sjellje historike, jo diçka që mund ta zbrazni në një kernel aktual.

Platformat e tjera ndryshojnë, dhe pikërisht këtu kopjimi i këshillave shkon keq. Windows mban një cache destinacionesh që mund ta pastroni me netsh interface ip delete destinationcache. BSD dhe macOS shfaqin kërkime për çdo destinacion përmes route -n get, dhe cache-t e tyre skadojnë sipas orarit të vet. Një komandë që funksionon në njërën prej tyre nuk bën absolutisht asgjë në Linux, prandaj i njëjti rregullim duket se dështon për gjysmën e njerëzve që e provojnë.

Një tabelë NAT ose conntrack nuk është cache rrugësh, ndonëse prodhon të njëjtin simptomë. Një rrjedhë e përkthyer para ndryshimit tuaj e mban përkthimin e saj, dhe conntrack -L do ta shfaqë shumë kohë pasi politika e rrugëzimit të ketë shkuar përpara. Ky është një gjendje e vjetruar, por pastrimi i rrugëve nuk do ta prekë.

Kontrolli tre: a është gjendja në rrugëzim apo mbi të?

Lexoni kërkimin aktual përpara çdo gjëje tjetër: ip route get për destinacionin, pastaj e njëjta komandë me from dhe adresën burimore, pastaj ip rule show. Nëse këto të tre përputhen me atë që kishit ndërmend, rrugëzimi nuk është shtresa për t'u rregulluar, dhe vëzhgimi i vjetruar erdhi nga diku tjetër.

Tre të dyshuar të zakonshëm rrinë mbi rrugëzimin. Një menaxher rrjeti mund të riinstalojë një rrugë nga një profil i ruajtur sekonda pasi ju e fshini, kështu që ndryshimi juaj duket se kthehet; kontrolloni nmcli connection show --active dhe gjendjen e njësisë përpara se të redaktoni përsëri tabelën. Cache-i i një zgjidhësi kthen një adresë të vjetër, që duket si dështim rrugëzimi derisa të pyesni të njëjtin emër me një mjet që anashkalon cache-in. Grupi i lidhjeve i një aplikacioni mban një socket funksional drejt destinacionit të vjetër dhe nuk i kërkon kurrë kernelit një vendim të re.

Çfarë ju lejojnë të përfundoni tri përgjigjet

Vendosni përgjigjet bashkë dhe rregullimi zakonisht shprehet vetë. Një rrjedhë e re që merr rrugën e gabuar në një platformë pa cache rrugësh do të thotë që politika është vërtet e gabuar, ndaj lexoni rregullat dhe tabelën që instali tuneli. Një rrjedhë e re që merr rrugën e saktë ndërsa sesioni i vjetër ngec do të thotë që problemi është aplikacioni ose socket-i. Rrugë të sakta me një vëzhgim të thyer në të dyja rastet do të thotë që gjendja është mbi rrugëzimin.

Kundërshtoni rifreskimin e përgjithshëm. Rinisja e stivës së rrjetit ose fshirja e çdo rruge në një makinë rruga e paracaktuar e së cilës është tuneli mund të presë pikërisht lidhjen që po përdorni për ta rregulluar, dhe shkatërron provën që do të kishte thënë se cila shtresë dështoi.

Nëse vërtet duhet të pastroni diçka, pastroni gjënë më të vogël që përputhet me diagnozën: socket-t e një procesi, një zë conntrack, cache-in e zgjidhësit. Pastaj përsëritni të njëjtin test të rrjedhës së re dhe shkruani çfarë ndryshoi.

Mbani tri gjendjet të ndara në shënimet tuaja

Konfigurimi i ruajtur, kërkimi aktual dhe rrjedha e vëzhguar janë tri fakte të ndryshme, dhe bashkimi i tyre në «cache» është ajo që e bën defektin të vështirë për t'u riprodhuar. Shkruani profilin ose njësinë që zotëron rrugën, daljen e ip route get, dhe burimin dhe destinacionin e lidhjes reale.

Shkruani pranë tyre platformën dhe versionin e klientit, sepse një rregullim që pastron cache-in e destinacioneve të Windows nuk është rregullim i zbatueshëm për një host Linux, dhe një procedurë e kopjuar mes të dyjave mëson mësimin e gabuar. Kur ia dorëzoni problemin dikujt tjetër, ato tri rreshta i lejojnë të riprodhojë gjendjen e dështuar në vend që të hamendësojë.