Að tæma leiðarskyndiminnið er fyrsta eðlishvötin þegar breyting tekur ekki gildi, og á nútíma Linux er það sóun: alheims IPv4 leiðarskyndiminnið var fjarlægt fyrir árum, svo ip route show cache prentar ekkert og ekkert er að hreinsa. Ástandið sem blekkir þig lifir einu lagi ofar: í socket, NAT-kortlagningu, uppflettingarþjóni eða netstjóra sem endurnýtti gamla prófílinn. Þrjár spurningar aðskilja þessi tilvik: kemur ranga leiðin úr nýju flæði eða gömlu sambandi, skyndiminnar kerfið þitt leiðir yfirhöfuð, og er ástandið í leiðsögninni eða ofan við hana. Svaraðu þeim áður en þú endurstillir tengi.

Athugun eitt: kemur gamla leiðin úr nýju flæði?

Komið samband heldur leiðinni sem það var búið til með. Þess vegna lifir SSH seta um göngin breytingu á leiðatöflunni meðan ný seta tekur strax nýju leiðina, og þess vegna þýðir «breytingin gerði ekkert» oft «gamla socketið heldur henni enn». Prófaðu með nýju ferli, ekki með glugganum sem þú ert þegar með opinn.

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

Síðasta skipunin prentar heimið sem nýja sambandið náði í raun, og það er ódýrasta leiðin til að sjá raunverulegu leiðina án þess að treysta stöðuglugga. Berðu það saman við upprunatöluheimilið sem nafnrýmið eða tengið átti að nota.

Ef nýtt flæði fer réttu leiðina og það gamla nær sér ekki, hættu að horfa á leiðsögnina. Leiðin var rétt; setan var gömul.

Athugun tvö: heldur kerfið þitt yfirhöfuð leiðarskyndiminni?

Á Linux er svarið nei, í þeim skilningi sem flestar leiðbeiningar meina. Ekkert alheims áfangastaðaskyndiminni er til að henda, og færslan á hverju socketi sem heldur valinni leið losnar með socketinu. Skyndiminnishlutinn í ip-route handbókinni lýsir sögulegri hegðun, ekki einhverju sem þú getur tæmt á núverandi kjarna.

Aðrir vettvangar eru ólíkir, og það er hér sem afritun ráða fer úrskeiðis. Windows heldur áfangastaðaskyndiminni sem þú getur hreinsað með netsh interface ip delete destinationcache. BSD og macOS sýna uppflettingar á hvern áfangastað gegnum route -n get, og skyndiminnin þeirra renna út samkvæmt eigin áætlun. Skipun sem virkar á einum þeirra gerir ekkert á Linux, sem útskýrir hvers vegna sama lagfæringin virðist mistakast hjá helmingnum sem prófar hana.

NAT- eða conntrack-tafla er ekki leiðarskyndiminni, þótt hún framkalli sömu einkenni. Flæði sem var þýtt fyrir breytinguna þína heldur þýðingu sinni, og conntrack -L mun sýna það löngu eftir að leiðsagnarstefnan hefur færst áfram. Það er úrelt ástand, en hreinsun leiða snertir það ekki.

Athugun þrjú: er ástandið í leiðsögninni eða ofan við hana?

Lestu núverandi uppflettingu áður en þú lest eitthvað annað: ip route get fyrir áfangastaðinn, svo sama skipun með from og upprunatöluheimilinu, svo ip rule show. Ef þessi þrjú stemma við það sem þú ætlaðir, er leiðsögnin ekki lagið sem á að laga, og úrelta athugunin kom annars staðar frá.

Þrír algengir grunaðir sitja ofan við leiðsögnina. Netstjóri getur enduruppsett leið úr vistuðum prófíl nokkrum sekúndum eftir að þú eyðir henni, svo breytingin þín virðist ganga til baka; athugaðu nmcli connection show --active og stöðu einingarinnar áður en þú breytir töflunni aftur. Skyndiminni uppflettingarþjóns skilar gömlu heimilisfangi, sem lítur út eins og leiðsagnarbilun þar til þú spyr um sama heiti með tóli sem sneiðir framhjá skyndiminninu. Sambandapottur forrits heldur virku socketi að gamla áfangastaðnum og biður kjarnann aldrei um nýja ákvörðun.

Hvað þrjú svör leyfa þér að álykta

Settu svörin saman og lagfæringin segir venjulega sjálf frá sér. Nýtt flæði sem fer röngu leiðina á vettvangi án leiðarskyndiminnis þýðir að stefnan er raunverulega röng, svo lestu reglurnar og töfluna sem göngin settu upp. Nýtt flæði sem fer réttu leiðina meðan gamla setan stendur kyrr þýðir að vandamálið er forritið eða socketið. Réttar leiðir með brostna athugun í báðum tilvikum þýða að ástandið er ofan við leiðsögnina.

Standist almennu endurnýjunina. Endurræsing netstaflans eða eyðing hverrar leiðar á vél þar sem sjálfgefin leið er göngin getur klippt einmitt sambandið sem þú notar til að laga það, og það eyðileggur sönnunargögnin sem hefðu sagt hvaða lag brást.

Ef þú verður einhverju að hreinsa, hreinsaðu minnsta hlutinn sem passar við greininguna: socket einnar ferlis, eina conntrack-færslu, skyndiminni uppflettingarþjóns. Endurtaktu svo sama nýja-flæðis-prófið og skrifaðu niður hvað breyttist.

Haltu þremur ástandunum aðskildum í athugasemdunum þínum

Vistuð stilling, núverandi uppfletting og athugað flæði eru þrjár mismunandi staðreyndir, og að bræða þær í «skyndiminnið» er það sem gerir gallann erfitt að endurskapa. Skrifaðu niður prófílinn eða eininguna sem á leiðina, úttak ip route get, og uppruna og áfangastað raunverulega sambandsins.

Skráðu vettvanginn og útgáfu biðlarans við hliðina, því lagfæring sem hreinsar Windows áfangastaðaskyndiminni er ekki lagfæring sem gildir fyrir Linux hýsil, og ferli sem er afritað milli þeirra kennir ranga lexíu. Þegar þú afhendir vandamálið einhverjum öðrum, leyfa þessar þrjár línur honum að endurskapa bilaða ástandið í stað þess að giska.

Tengdir greinar