Smerovacia tabuľka verzus skutočné vyhľadanie: kam ide prevádzka VPN

Výpis smerovacej tabuľky je najmenej užitočná diagnostika pri riešení problémov s VPN a najčastejšie vkladaná. Štyridsať riadkov prefixov vám povie, čo stroj mohol urobiť, nie čo urobil pre neúspešnú požiadavku. Mechanizmus, ktorý skutočne chcete, je vyhľadanie: pre tento zdroj a tento cieľ, ktoré pravidlo sa zhodovalo, ktorá tabuľka bola konzultovaná a ktoré rozhranie a ďalší skok vyšli. Začnite pri jednom cieli a jednom zdroji, potom čítajte tabuľku s tou otázkou v ruke, a ten istý výstup sa stane dôkazom namiesto šumu.

Tabuľka je množina kandidátov, nie rozhodnutie

Každý záznam opisuje prefix a čo robiť s prevádzkou, ktorá mu zodpovedá: poslať ju do rozhrania, odovzdať ďalšiemu skoku alebo zahodiť. Nič v tomto zozname nie je zoradené podľa zámeru a záznam, ktorý človeku pripadá najkonkrétnejší, nie je vždy ten, ktorý jadro vyberie, pretože výber sleduje najdlhšiu zhodu prefixu a medzi rovnakými prefixmi metriku.

Prvým krokom je teda opýtať sa jadra namiesto čítania zoznamu. Príkaz na vyhľadanie odpovedá pre cieľ a s argumentom zdroja odpovedá pre presnú dvojicu, ktorú by použilo presmerované alebo viazané spojenie:

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 vyššie je dokumentačný príklad. Ide o tvar odpovede: rozhranie, zvolená zdrojová adresa, brána a tabuľka, z ktorej záznam prišiel. Ak tento výstup nezodpovedá rozhraniu, ktoré ste očakávali, lokalizovali ste problém jediným príkazom, a nijaké čítanie plnej tabuľky by vám nepovedalo, ktorý kandidát vyhral.

Vyhľadanie prechádza najprv pravidlá, potom tabuľky

V Linuxe je rozhodnutie dvojfázové. Pravidlá politiky sa vyhodnocujú v poradí priority a prvé pravidlo, ktoré zodpovedá, určí tabuľku na konzultáciu; tá potom vykoná zhodu najdlhšieho prefixu. Pravidlo môže zodpovedať podľa zdroja, cieľa, značky firewallu, rozhrania alebo kombinácie, preto môže byť výpis hlavnej tabuľky úplne presný a úplne irelevantný pre paket, ktorý skúmate.

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

Ak pravidlo posiela prevádzku z vášho poolu VPN do tabuľky 100, potom je dôležitá tabuľka 100, a hlavná tabuľka je návnada. To je aj mechanizmus smerovania založeného na zdroji na routeri: ten istý cieľ môže mať dve rôzne odpovede podľa toho, odkiaľ paket prišiel, a iba vyhľadanie s argumentom zdroja ukáže, ktorá platí.

IPv6 má vlastné pravidlá a tabuľky. Návrh, ktorý prevádzkuje obe rodiny, potrebuje obe vyhľadania, a fungujúca odpoveď IPv4 nehovorí nič o ceste v6, ktorú môže duálny klient uprednostniť.

Čo klient VPN inštaluje

Klienti zvyčajne nenahrádzajú predvolenú trasu, pretože by to narušilo vlastnú vonkajšiu cestu tunela. Inštalujú niečo konkrétnejšie, čo vyhráva dĺžkou prefixu: dvojica polo-predvolených trás pokrývajúcich 0.0.0.0/1 a 128.0.0.0/1 je klasický trik, keďže obe sú dlhšie prefixy ako 0.0.0.0/0 a spolu pokrývajú celý priestor. Iní inštalujú konkrétne súkromné prefixy plus pravidlo politiky, a niektorí pridajú značku, aby sa zachytila iba vybraná prevádzka.

Preto "VPN mi nezmenilo predvolenú trasu" nie je dôkazom zlyhania. Skontrolujte, čo naozaj pridalo, a či daný cieľ spadá do tých prefixov:

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

Dve polo-trasy sa vo výpise ľahko prehliadnu, pretože nevyzerajú ako predvolená trasa. Konfigurácia split-tunnel, ktorá zabudla zahrnúť prefix, vytvára presne ten symptóm, ktorý prenasledujete: aplikácia, ktorá mala použiť tunel, namiesto toho preloží a pripojí sa lokálne. Porovnajte nainštalované prefixy s cieľmi, ktoré používateľ skutočne potrebuje, nie s adresami, ktoré ste náhodou otestovali. Zoznam split-tunnel, ktorý pokrýva súborový server, ale nie jeho resolver, vytvára spojenie, ktoré sa preloží na verejnú adresu a potom zlyhá pri autentifikácii, čo vyzerá ako problém s heslom a je to problém trasy.

Vonkajšia trasa musí tiež prežiť

Tunel je sám prevádzka. Pakety nesúce zapuzdrený obsah idú na adresu partnera cez fyzické rozhranie a táto cesta nesmie byť smerovaná späť do tunela. Keď je, dostanete charakteristickú poruchu, pri ktorej sa tunel vytvorí a potom prestane prepúšťať prevádzku, pretože transport tunela je teraz vnútri tunela.

Skontrolujte adresu partnera tak, ako ste skontrolovali vnútorný cieľ, a potvrďte, že sa prekladá na fyzické rozhranie, nie na tunel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekurzívna trasa, pravidlo politiky, ktoré zachytí partnera, alebo predvolená trasa nahradená klientom plného tunela sú tri obvyklé príčiny. Všetky tri sú viditeľné vo vonkajšom vyhľadaní a žiadna z nich nie je viditeľná vo výpise hlavnej tabuľky vyhotovenom dodatočne.

Čo vám výstup smerovania nemôže povedať

Správne vyhľadanie znamená, že by jadro poslalo paket na rozumné miesto. Neznamená to, že ho firewall povoľuje, politika IPsec ho pokrýva, pravidlo NAT ho prekladá alebo že vzdialená strana má spätnú trasu. Každé z toho je neskoršia fáza, a poznámky strongSwan k preposielaniu opisujú reťazec, ktorým paket musí prejsť na oboch koncoch.

Nezohľadňuje ani väzbu na úrovni aplikácie. Proces sa môže naviazať na rozhranie, nastaviť značku alebo použiť vlastný resolver a pripojiť sa menom, ktoré sa prekladá inak, než ste testovali. Keď je vyhľadanie správne a spojenie stále zlyháva, ďalšou otázkou je, ktorý proces ho vytvára a či tento proces vidí tú istú tabuľku ako vy.

Udržujte teda diagnostiku usporiadanú: pomenujte cieľ a zdroj, spustite vyhľadanie, čítajte iba tabuľku a pravidlo, ktoré vyhľadanie pomenovalo, a potom otestujte ďalšiu fázu. Tento sled udrží vyšetrovanie smerovania v minútach a zanechá záznam, ktorý môže niekto iný nasledovať, čo vložená tabuľka nikdy neurobí.