Skrývá mezipaměť tras VPN vaši změnu? Zkontrolujte tři věci

Vyprázdnění mezipaměti tras je první instinkt, když se změna neprojeví, a na moderním Linuxu je to marná práce: globální mezipaměť tras IPv4 byla odstraněna před lety, takže ip route show cache nic nevypíše a není co mazat. Stav, který vás klame, žije o vrstvu výš: v socketu, mapování NAT, resolveru nebo správci sítě, který znovu použil starý profil. Tři otázky tyto případy oddělují: přichází špatná cesta z nového toku, nebo ze starého spojení, ukládá vaše platforma trasy vůbec do mezipaměti, a je stav v routování, nebo nad ním. Odpovězte na ně, než resetujete rozhraní.

První kontrola: přichází stará cesta z nového toku?

Navázané spojení si drží trasu, se kterou bylo vytvořeno. Proto SSH relace přes tunel přežije změnu routovací tabulky, zatímco nová relace okamžitě převezme novou cestu, a proto „změna nic neudělala“ často znamená „starý socket ji pořád drží“. Testujte novým procesem, ne oknem, které už máte otevřené.

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

Poslední příkaz vypíše adresu, na kterou se nové spojení skutečně dostalo, což je nejlevnější způsob, jak vidět skutečnou cestu bez důvěry v okno stavu. Porovnejte ji se zdrojovou adresou, kterou měl namespace nebo rozhraní použít.

Pokud nový tok jde správnou cestou a starý se nezotaví, přestaňte se dívat na routování. Trasa byla správná; relace byla stará.

Druhá kontrola: uchovává vaše platforma vůbec mezipaměť tras?

Na Linuxu je odpověď ne, ve smyslu, který mají většinou návodů na mysli. Neexistuje globální mezipaměť destinací, kterou by šlo zahodit, a záznam na úrovni socketu, který drží zvolenou trasu, se uvolní spolu se socketem. Sekce o mezipaměti v manuálu ip-route popisuje historické chování, ne něco, co můžete na aktuálním jádru vyprázdnit.

Jiné platformy se liší a právě zde se kopírování rad pokazí. Windows uchovává mezipaměť destinací, kterou můžete vyčistit pomocí netsh interface ip delete destinationcache. BSD a macOS zpřístupňují vyhledávání po destinacích přes route -n get a jejich mezipaměti vyprší podle vlastního plánu. Příkaz, který funguje na jedné z nich, na Linuxu neudělá vůbec nic, a proto stejná oprava vypadá jako neúspěšná u poloviny lidí, kteří ji zkouší.

Tabulka NAT nebo conntrack není mezipaměť tras, i když vytváří stejný příznak. Tok, který byl přeložen před vaší změnou, si drží svůj překlad a conntrack -L ho ukáže dlouho poté, co se routovací politika posunula. To je zastaralý stav, ale mazání tras se ho nedotkne.

Třetí kontrola: je stav v routování, nebo nad ním?

Přečtěte si aktuální vyhledání, než přečtete cokoli jiného: ip route get pro destinaci, pak stejný příkaz s from a zdrojovou adresou, pak ip rule show. Pokud tyto tři souhlasí s tím, co jste zamýšleli, routování není vrstva k opravě a zastaralé pozorování přišlo odjinud.

Tři obvyklí podezřelí sedí nad routováním. Správce sítě může znovu nainstalovat trasu z uloženého profilu sekundy poté, co ji smažete, takže se vaše změna zdá vracet; zkontrolujte nmcli connection show --active a stav unit před další úpravou tabulky. Mezipaměť resolveru vrací starou adresu, což vypadá jako selhání routování, dokud se na stejné jméno nezeptáte nástrojem, který mezipaměť obchází. Fond spojení aplikace drží funkční socket ke staré destinaci a nikdy nežádá jádro o nové rozhodnutí.

Co vám tři odpovědi umožní uzavřít

Dejte odpovědi dohromady a oprava se obvykle sama vysloví. Nový tok, který jde špatnou cestou na platformě bez mezipaměti tras, znamená, že politika je skutečně špatná, takže si přečtěte pravidla a tabulku, kterou tunel nainstaloval. Nový tok, který jde správnou cestou, zatímco stará relace uvázne, znamená, že problém je v aplikaci nebo socketu. Správné trasy s porušeným pozorováním v obou případech znamenají, že stav je nad routováním.

Odolejte obecnému obnovení. Restart síťového zásobníku nebo smazání všech tras na stroji, jehož výchozí trasou je tunel, může přerušit právě to spojení, které používáte k opravě, a ničí důkazy, které by řekly, která vrstva selhala.

Pokud přece jen musíte něco vyčistit, vyčistěte nejmenší věc, která odpovídá diagnóze: sockety jednoho procesu, jeden záznam conntrack, mezipaměť resolveru. Pak zopakujte stejný test nového toku a zapište, co se změnilo.

Držte tři stavy ve svých poznámkách oddělené

Uložená konfigurace, aktuální vyhledání a pozorovaný tok jsou tři různé skutečnosti, a jejich slití do „mezipaměti“ je to, co dělá závadu těžko reprodukovatelnou. Zapište profil nebo unit, kterému trasa patří, výstup ip route get a zdroj a destinaci skutečného spojení.

Vedle nich zapište platformu a verzi klienta, protože oprava, která čistí mezipaměť destinací Windows, není oprava použitelná na hostitele Linux a postup zkopírovaný mezi oběma učí špatnou lekci. Když problém předáte někomu jinému, tyto tři řádky mu umožní reprodukovat selhávající stav místo hádání.