Elrejti a VPN útvonal-gyorsítótár a változtatásodat? Ellenőrizz három dolgot

Az útvonal-gyorsítótár ürítése az első ösztön, amikor egy változtatás nem lép életbe, és modern Linuxon ez pazarlás: a globális IPv4 útvonal-gyorsítótárt évekkel ezelőtt eltávolították, ezért a ip route show cache semmit sem ír ki, és nincs mit törölni. Az állapot, ami megtéveszt, egy réteggel feljebb él: egy socketben, egy NAT-leképezésben, egy feloldóban vagy egy hálózatkezelőben, amely újra alkalmazta a régi profilt. Három kérdés választja szét ezeket az eseteket: a rossz útvonal új folyamból vagy régi kapcsolatból jön-e, egyáltalán gyorsítótáraz-e az útvonalakat a platformod, és a routingban vagy afölött van-e az állapot. Válaszolj rájuk, mielőtt visszaállítasz egy interfészt.

Első ellenőrzés: a régi útvonal új folyamból jön?

Egy létrejött kapcsolat megtartja azt az útvonalat, amellyel készült. Ezért él túl egy SSH-munkamenet az alagúton egy routingtábla-változást, miközben egy új munkamenet azonnal az új útvonalat veszi, és ezért jelent gyakran annyit a «a változtatás semmit sem tett», hogy «a régi socket még mindig fogja». Új folyamattal tesztelj, ne a már nyitva lévő ablakkal.

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

Az utolsó parancs kiírja azt a címet, amelyet az új kapcsolat ténylegesen elért, és ez a legolcsóbb módja a valódi útvonal megtekintésének anélkül, hogy egy állapotablakban bíznál. Hasonlítsd össze azzal a forráscímmel, amelyet a névtérnek vagy az interfésznek használnia kellett volna.

Ha egy friss folyam a helyes útvonalat veszi, a régi pedig nem áll helyre, hagyd abba a routing vizsgálatát. Az útvonal helyes volt; a munkamenet régi volt.

Második ellenőrzés: egyáltalán tart-e útvonal-gyorsítótárat a platformod?

Linuxon a válasz nem, abban az értelemben, ahogy a legtöbb útmutató érti. Nincs globális cél-gyorsítótár, amit eldobhatnánk, és a kiválasztott útvonalat tartó socket-szintű bejegyzés a socketkel együtt szabadul fel. Az ip-route kézikönyv gyorsítótár-szakasza történelmi viselkedést ír le, nem olyat, amit egy jelenlegi kernelen üríthetsz.

Más platformok eltérnek, és itt megy félre a tanácsok másolása. A Windows cél-gyorsítótárat tart, amelyet a netsh interface ip delete destinationcache paranccsal törölhetsz. A BSD és a macOS célonkénti kereséseket tesz elérhetővé a route -n get paranccsal, és gyorsítótáraik a saját ütemtervük szerint járnak le. Egy parancs, amely az egyiken működik, Linuxon semmit sem tesz, ezért tűnik úgy, hogy ugyanaz a javítás a kipróbálók felénél sikertelen.

A NAT- vagy conntrack-tábla nem útvonal-gyorsítótár, bár ugyanazt a tünetet okozza. A változtatásod előtt lefordított folyam megtartja a fordítását, és a conntrack -L jóval azután is megmutatja, hogy a routing-szabály továbblépett. Ez elavult állapot, de az útvonalak törlése nem nyúl hozzá.

Harmadik ellenőrzés: a routingban vagy afölött van az állapot?

Olvasd el az aktuális keresést, mielőtt bármi mást olvasnál: ip route get a célhoz, majd ugyanaz a parancs from és a forráscím használatával, majd ip rule show. Ha ez a három egyezik a szándékoddal, a routing nem a javítandó réteg, és az elavult megfigyelés máshonnan jött.

Három szokásos gyanúsított ül a routing fölött. Egy hálózatkezelő másodpercekkel a törlés után újratelepíthet egy útvonalat egy mentett profilból, így a változtatásod visszatérni látszik; ellenőrizd a nmcli connection show --active kimenetét és az unit állapotát, mielőtt újra szerkeszted a táblát. Egy feloldó gyorsítótára régi címet ad vissza, ami routing-hibának látszik, amíg ugyanazt a nevet meg nem kérdezed egy gyorsítótárat megkerülő eszközzel. Egy alkalmazás kapcsolatpoolja működő socketet tart a régi cél felé, és soha nem kér új döntést a kerneltől.

Mit engednek megállapítani a három válaszok

Tedd össze a válaszokat, és a javítás általában kimondja magát. Egy friss folyam, amely a rossz útvonalat veszi egy útvonal-gyorsítótár nélküli platformon, azt jelenti, hogy a szabály valóban hibás, ezért olvasd el az alagút által telepített szabályokat és táblát. Egy friss folyam, amely a helyes útvonalat veszi, miközben a régi munkamenet elakad, azt jelenti, hogy a probléma az alkalmazás vagy a socket. Helyes útvonalak törött megfigyeléssel mindkét esetben azt jelentik, hogy az állapot a routing fölött van.

Ellenállj az általános frissítésnek. A hálózati verem újraindítása vagy minden útvonal törlése egy olyan gépen, amelynek alapértelmezett útvonala az alagút, épp azt a kapcsolatot vághatja el, amelyet a javításhoz használsz, és elpusztítja a bizonyítékot, amely megmondta volna, melyik réteg hibázott.

Ha mégis törölnöd kell valamit, a diagnózishoz illő legkisebb dolgot töröld: egy folyamat socketjeit, egy conntrack-bejegyzést, a feloldó gyorsítótárát. Aztán ismételd meg ugyanazt a friss folyam tesztet, és írd le, mi változott.

Tartsd külön a három állapotot a jegyzeteidben

A mentett konfiguráció, az aktuális keresés és a megfigyelt folyam három különböző tény, és összemosásuk «a gyorsítótárba» az, ami a hibát nehezen reprodukálhatóvá teszi. Írd le az útvonalat birtokló profilt vagy unitot, a ip route get kimenetét, valamint a tényleges kapcsolat forrását és célját.

Írd mellé a platformot és a kliensverziót, mert egy Windows cél-gyorsítótárát törlő javítás nem alkalmazható Linux-gazdagépre, és a kettő között másolt eljárás rossz leckét tanít. Amikor átadod a problémát valaki másnak, ez a három sor lehetővé teszi számára a hibás állapot reprodukálását találgatás helyett.