Skrýva vyrovnávacia pamäť trás VPN vašu zmenu? Skontrolujte tri veci

Vyprázdnenie vyrovnávacej pamäte trás je prvý inštinkt, keď sa zmena neprejaví, a na modernom Linuxe je to márna práca: globálna vyrovnávacia pamäť trás IPv4 bola odstránená pred rokmi, takže ip route show cache nič nevypíše a niet čo mazať. Stav, ktorý vás klame, žije o vrstvu vyššie: v sockete, mapovaní NAT, resolveri alebo správcovi siete, ktorý znova použil starý profil. Tri otázky tieto prípady oddeľujú: prichádza nesprávna cesta z nového toku alebo zo starého spojenia, ukladá vaša platforma trasy vôbec do vyrovnávacej pamäte, a je stav v smerovaní alebo nad ním. Odpovedzte na ne, skôr než resetujete rozhranie.

Prvá kontrola: prichádza stará cesta z nového toku?

Nadviazané spojenie si drží trasu, s ktorou bolo vytvorené. Preto SSH relácia cez tunel prežije zmenu smerovacej tabuľky, zatiaľ čo nová relácia okamžite prevezme novú cestu, a preto „zmena nič neurobila“ často znamená „starý socket ju stále drží“. Testujte novým procesom, nie oknom, ktoré už máte otvorené.

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

Posledný príkaz vypíše adresu, na ktorú sa nové spojenie skutočne dostalo, a to je najlacnejší spôsob, ako vidieť skutočnú cestu bez dôvery v okno stavu. Porovnajte ju so zdrojovou adresou, ktorú mal použiť namespace alebo rozhranie.

Ak nový tok ide správnou cestou a starý sa neobnoví, prestaňte sa pozerať na smerovanie. Trasa bola správna; relácia bola stará.

Druhá kontrola: uchováva vaša platforma vôbec vyrovnávaciu pamäť trás?

Na Linuxe je odpoveď nie, v zmysle, ktorý majú na mysli väčšina návodov. Neexistuje globálna vyrovnávacia pamäť cieľov, ktorú by bolo možné zahodiť, a záznam na úrovni socketu, ktorý drží vybranú trasu, sa uvoľní spolu so socketom. Sekcia o vyrovnávacej pamäti v manuáli ip-route opisuje historické správanie, nie niečo, čo môžete vyprázdniť na aktuálnom jadre.

Iné platformy sa líšia a práve tu sa kopírovanie rád pokazí. Windows uchováva vyrovnávaciu pamäť cieľov, ktorú môžete vyčistiť pomocou netsh interface ip delete destinationcache. BSD a macOS sprístupňujú vyhľadávanie podľa cieľa cez route -n get a ich vyrovnávacie pamäte vypršia podľa vlastného plánu. Príkaz, ktorý funguje na jednej z nich, na Linuxe neurobí vôbec nič, a preto tá istá oprava vyzerá ako neúspešná u polovice ľudí, ktorí ju skúšajú.

Tabuľka NAT alebo conntrack nie je vyrovnávacia pamäť trás, hoci vytvára rovnaký príznak. Tok, ktorý bol preložený pred vašou zmenou, si drží svoj preklad, a conntrack -L ho ukáže dlho po tom, čo sa smerovacia politika posunula ďalej. To je zastaraný stav, ale mazanie trás sa ho nedotkne.

Tretia kontrola: je stav v smerovaní, alebo nad ním?

Prečítajte si aktuálne vyhľadanie, skôr než čokoľvek iné: ip route get pre cieľ, potom ten istý príkaz s from a zdrojovou adresou, potom ip rule show. Ak tieto tri súhlasia s tým, čo ste zamýšľali, smerovanie nie je vrstva na opravu a zastarané pozorovanie prišlo odinakiaľ.

Traja obvyklí podozriví sedia nad smerovaním. Správca siete môže znova nainštalovať trasu z uloženého profilu sekundy po tom, čo ju vymažete, takže sa vaša zmena zdá vracať; skontrolujte nmcli connection show --active a stav unit pred ďalšou úpravou tabuľky. Vyrovnávacia pamäť resolvera vracia starú adresu, čo vyzerá ako zlyhanie smerovania, kým sa na to isté meno neopýtate nástrojom, ktorý obchádza vyrovnávaciu pamäť. Pul spojení aplikácie drží funkčný socket k starému cieľu a nikdy nepožiada jadro o nové rozhodnutie.

Čo vám tri odpovede umožňujú uzavrieť

Dajte odpovede dokopy a oprava sa zvyčajne sama vysloví. Nový tok, ktorý ide nesprávnou cestou na platforme bez vyrovnávacej pamäte trás, znamená, že politika je skutočne nesprávna, takže si prečítajte pravidlá a tabuľku, ktorú tunel nainštaloval. Nový tok, ktorý ide správnou cestou, zatiaľ čo stará relácia uviazne, znamená, že problém je v aplikácii alebo sockete. Správne trasy s narušeným pozorovaním v oboch prípadoch znamenajú, že stav je nad smerovaním.

Odolajte všeobecnému obnoveniu. Reštart sieťového zásobníka alebo vymazanie každej trasy na stroji, ktorého predvolenou trasou je tunel, môže prerušiť práve to spojenie, ktoré používate na opravu, a ničí dôkazy, ktoré by povedali, ktorá vrstva zlyhala.

Ak predsa len musíte niečo vyčistiť, vyčistite najmenšiu vec, ktorá zodpovedá diagnóze: sockety jedného procesu, jeden záznam conntrack, vyrovnávaciu pamäť resolvera. Potom zopakujte ten istý test nového toku a zapíšte, čo sa zmenilo.

Držte tri stavy v poznámkach oddelené

Uložená konfigurácia, aktuálne vyhľadanie a pozorovaný tok sú tri rôzne fakty, a ich zlievanie do „vyrovnávacej pamäte“ je to, čo robí poruchu ťažko reprodukovateľnou. Zapíšte profil alebo unit, ktorému trasa patrí, výstup ip route get a zdroj a cieľ skutočného spojenia.

Vedľa zapíšte platformu a verziu klienta, pretože oprava, ktorá čistí vyrovnávaciu pamäť cieľov Windows, nie je oprava použiteľná na hostiteľa Linux a postup skopírovaný medzi oboma učí nesprávnu lekciu. Keď problém odovzdáte niekomu inému, tieto tri riadky mu umožnia reprodukovať zlyhávajúci stav namiesto hádania.