Směrovací tabulka versus skutečné vyhledání: kam jde provoz VPN

Výpis směrovací tabulky je nejméně užitečná diagnostika při řešení problémů s VPN a nejčastěji vkládaná. Čtyřicet řádků prefixů vám řekne, co stroj mohl udělat, ne co udělal pro neúspěšný požadavek. Mechanismus, který skutečně chcete, je vyhledání: pro tento zdroj a tento cíl, které pravidlo odpovídalo, která tabulka byla konzultována a které rozhraní a další skok vyšly. Začněte u jednoho cíle a jednoho zdroje, pak čtěte tabulku s tou otázkou v ruce a stejný výstup se stane důkazem místo šumu.

Tabulka je sada kandidátů, ne rozhodnutí

Každý záznam popisuje prefix a co udělat s provozem, který mu odpovídá: poslat ho do rozhraní, předat dalšímu skoku nebo zahodit. Nic v tom seznamu není seřazeno podle záměru a záznam, který člověku připadá nejkonkrétnější, není vždy ten, který jádro vybere, protože výběr sleduje nejdelší shodu prefixu a mezi stejnými prefixy metriku.

Prvním krokem je tedy zeptat se jádra, místo čtení seznamu. Příkaz pro vyhledání odpovídá pro cíl, a s argumentem zdroje odpovídá pro přesnou dvojici, kterou by použilo přesměrované nebo vázané spojení:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Každá adresa výše je dokumentační příklad. Jde o tvar odpovědi: rozhraní, zvolená zdrojová adresa, brána a tabulka, ze které záznam přišel. Pokud tento výstup neodpovídá rozhraní, které jste očekávali, lokalizovali jste problém jediným příkazem a žádné čtení plné tabulky by vám neřeklo, který kandidát vyhrál.

Vyhledání prochází nejprve pravidla, pak tabulky

V Linuxu je rozhodnutí dvoufázové. Pravidla zásad se vyhodnocují v pořadí priority a první pravidlo, které odpovídá, pojmenuje tabulku ke konzultaci; ta pak provede shodu nejdelšího prefixu. Pravidlo může odpovídat podle zdroje, cíle, značky firewallu, rozhraní nebo kombinace, a proto může být výpis hlavní tabulky naprosto přesný a zcela irelevantní pro paket, který zkoumáte.

ip rule show
ip route show table all | head -40
ip route show table 100

Pokud pravidlo posílá provoz z vašeho poolu VPN do tabulky 100, pak je důležitá tabulka 100, a hlavní tabulka je návnada. To je také mechanismus směrování založeného na zdroji na routeru: stejný cíl může mít dvě různé odpovědi podle toho, odkud paket přišel, a pouze vyhledání s argumentem zdroje ukáže, která platí.

IPv6 má svá vlastní pravidla a tabulky. Návrh, který provozuje obě rodiny, potřebuje obě vyhledání, a fungující odpověď IPv4 nic neříká o cestě v6, kterou může duální klient preferovat.

Co klient VPN instaluje

Klienti obvykle nenahrazují výchozí trasu, protože by tím porušili vlastní vnější cestu tunelu. Instalují něco konkrétnějšího, co vyhraje délkou prefixu: dvojice polo-výchozích tras pokrývajících 0.0.0.0/1 a 128.0.0.0/1 je klasický trik, protože obě jsou delší prefixy než 0.0.0.0/0 a společně pokrývají celý prostor. Jiní instalují konkrétní privátní prefixy plus pravidlo zásad a někteří přidají značku, aby byl zachycen jen vybraný provoz.

Proto "VPN mi nezměnila výchozí trasu" není důkazem selhání. Zkontrolujte, co přidala, a zda dotyčný cíl spadá do těch prefixů:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Dvě polo-trasy se ve výpisu snadno přehlédnou, protože nevypadají jako výchozí. Konfigurace split-tunnel, která zapomněla zahrnout prefix, vytváří přesně ten symptom, který hledáte: aplikace, která měla použít tunel, místo toho přeloží a připojí se lokálně. Porovnejte nainstalované prefixy s cíli, které uživatel skutečně potřebuje, ne s adresami, které jste náhodou testovali. Seznam split-tunnel, který pokrývá souborový server, ale ne jeho resolver, vytvoří spojení, které se přeloží na veřejnou adresu a pak selže při autentizaci, což vypadá jako problém s heslem a je to problém trasy.

Vnější trasa musí také přežít

Tunel je sám provoz. Pakety nesoucí zapouzdřený obsah jdou na adresu protějšku přes fyzické rozhraní a tato cesta nesmí být směrována zpět do tunelu. Když je, dostanete charakteristickou poruchu, kdy se tunel naváže a pak přestane propouštět provoz, protože transport tunelu je nyní uvnitř tunelu.

Zkontrolujte adresu protějšku stejně, jako jste zkontrolovali vnitřní cíl, a potvrďte, že se překládá na fyzické rozhraní, nikoli na tunel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekurzivní trasa, pravidlo zásad, které zachytí protějšek, nebo výchozí trasa nahrazená klientem plného tunelu jsou tři obvyklé příčiny. Všechny tři jsou vidět ve vnějším vyhledání a žádná z nich není vidět ve výpisu hlavní tabulky pořízeném dodatečně.

Co vám výstup směrování nemůže říct

Správné vyhledání znamená, že by jádro poslalo paket někam rozumně. Neznamená to, že ho firewall povoluje, zásada IPsec pokrývá, pravidlo NAT překládá nebo že vzdálená strana má zpětnou trasu. Každé z toho je pozdější fáze, a poznámky strongSwan k předávání popisují řetězec, kterým paket musí projít na obou koncích.

Nezohledňuje ani vazbu na úrovni aplikace. Proces se může navázat na rozhraní, nastavit značku nebo použít vlastní resolver a připojit se jménem, které se překládá jinak, než jste testovali. Když je vyhledání správné a spojení stále selhává, další otázkou je, který proces ho vytváří a zda tento proces vidí stejnou tabulku jako vy.

Udržujte tedy diagnostiku uspořádanou: pojmenujte cíl a zdroj, spusťte vyhledání, čtěte jen tabulku a pravidlo, které vyhledání pojmenovalo, a pak otestujte další fázi. Tento sled udrží vyšetřování směrování v minutách a zanechá záznam, který může někdo jiný následovat, což vložená tabulka nikdy neudělá.