Proč trasy se stejnou cenou ztěžují odhalení poruch VPN
Když několik tunelů sdílí stejnou cenu, každý tok může jít jiným. Úspěšný ping nic neříká o cestě, kterou vaše aplikace skutečně používá.
Uživatel hlásí, že interní aplikace funguje z jednoho počítače a z jiného selhává, zatímco ping spuštěný z brány uspěje v obou případech. U několika tunelů se stejnou cenou to není rozpor. Každý tok se umístí na vlastní další skok, takže vaše sonda a uživatelova relace mohou prostě používat různé cesty. Následující rozbor tento výběr reprodukuje ještě před jakoukoli změnou.
Jeden ping, několik možných cest
Když má trasa více než jeden další skok se stejnou cenou, směrovač musí pro každý paket vybrat jeden. Většina implementací hašuje pole z paketu, obvykle zdrojovou a cílovou adresu spolu s protokolem a porty, aby odpovědi zůstaly na stejné cestě. Různé aplikace, ba i různá spojení jedné aplikace, vytvářejí různé haše.
Proto diagnostika z brány dokazuje tak málo. Vlastní sonda brány má vlastní adresy a porty, a tedy i vlastní haš. Může skončit na zdravém tunelu, zatímco uživatel dál končí na porouchaném.
Jak platforma vybírá další skok
Výběr reprodukujte, místo abyste ho hádali. Zeptejte se jádra, kterou trasu by použilo pro stejný zdroj a cíl jako selhávající relace. Toto hledání zahrnuje pole, která běžné hledání podle cíle ignoruje. Spusťte ho i z fungujícího klienta a porovnejte obě odpovědi:
ip route get 10.20.5.7 from 10.20.0.14Novější vydání iproute2 přijímají také protokol a cílový port, což je důležité, když je haš zahrnuje. Porovnejte tento výstup se stejným hledáním z fungujícího klienta a rozdíl je důkaz, který vám chyběl.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Sledujte selhávající tok, ne tabulku tras
Tabulka tras uvádí oba tunely a podle definice vypadá správně. Otázkou je, co každý tunel s paketem po výběru udělá. Ověřte, že oba nesou stejné chráněné prefixy, stejné povolení předávání a zpětnou cestu, která dosáhne stejného klienta.
Všímejte si stavových zařízení uprostřed cesty. Pokud požadavek odchází jedním tunelem a odpověď se vrací druhým, firewall nebo NAT, který původní tok nikdy neviděl, ji zahodí. Oba tunely předávají provoz správně a spojení přesto selhává.
Zkontrolujte také MTU po jednotlivých cestách. Cesta s dodatečnou enkapsulací zmenšuje použitelnou velikost a přenos, který jedním tunelem projde, se na druhém zasekne přesně na velikosti, kde se menší láme.
Porovnávejte jednu cestu po druhé
Tam, kde to návrh dovoluje, vyřaďte jeden tunel z provozu a zopakujte uživatelův úkol. Pokud porucha zmizí, problém patří cestě, kterou jste odebrali, a dalším krokem je porovnat její konfiguraci se sousední, nikoli znovu zkoumat směrovací tabulku.
Porovnávejte skutečnou aplikaci, ne opakované pingy. Zaznamenejte, zda porucha sleduje určitý další skok, velikost paketu nebo přechod po opětovném připojení, protože tyto tři vzorce ukazují na různé opravy.
Nakonec zapište, proč se cesty považují za rovnocenné a jak má porucha jednu z nich vyřadit z provozu. Vícesměrovost je bezpečná jen tehdy, když jsou cesty skutečně zaměnitelné, a to je návrhové tvrzení, které stojí za ověření, ne za předpoklad.