Prečo trasy s rovnakou cenou sťažujú odhalenie porúch VPN
Keď viacero tunelov zdieľa rovnakú cenu, každý tok môže ísť iným. Úspešný ping nič nehovorí o ceste, ktorú vaša aplikácia skutočne používa.
Používateľ hlási, že interná aplikácia funguje z jedného počítača a z iného zlyháva, zatiaľ čo ping spustený z brány uspeje v oboch prípadoch. Pri viacerých tuneloch s rovnakou cenou to nie je rozpor. Každý tok sa umiestni na vlastný ďalší skok, takže vaša sonda a používateľova relácia môžu jednoducho používať rôzne cesty. Nasledujúci rozbor tento výber reprodukuje ešte pred akoukoľvek zmenou.
Jeden ping, viacero možných ciest
Keď má trasa viac ako jeden ďalší skok s rovnakou cenou, smerovač musí pre každý paket vybrať jeden. Väčšina implementácií hašuje polia z paketu, zvyčajne zdrojovú a cieľovú adresu spolu s protokolom a portmi, aby odpovede zostali na tej istej ceste. Rôzne aplikácie, ba aj rôzne spojenia jednej aplikácie, vytvárajú rôzne haše.
Preto diagnostika z brány dokazuje tak málo. Vlastná sonda brány má vlastné adresy a porty, a teda vlastný haš. Môže skončiť na zdravom tuneli, zatiaľ čo používateľ ďalej končí na pokazenom.
Ako platforma vyberá ďalší skok
Výber reprodukujte, namiesto toho, aby ste ho hádali. Spýtajte sa jadra, ktorú trasu by použilo pre rovnaký zdroj a cieľ ako zlyhávajúca relácia. Toto hľadanie zahŕňa polia, ktoré bežné hľadanie podľa cieľa ignoruje. Spustite ho aj z fungujúceho klienta a porovnajte obe odpovede:
ip route get 10.20.5.7 from 10.20.0.14Novšie vydania iproute2 prijímajú aj protokol a cieľový port, čo je dôležité, keď ich haš zahŕňa. Porovnajte tento výstup s rovnakým hľadaním z fungujúceho klienta a rozdiel je dôkaz, ktorý vám chýbal.
| 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 zlyhávajúci tok, nie tabuľku trás
Tabuľka trás uvádza oba tunely a podľa definície vyzerá správne. Otázkou je, čo každý tunel robí s paketom po výbere. Overte, že oba nesú rovnaké chránené prefixy, rovnaké povolenie preposielania a spiatočnú cestu, ktorá dosiahne toho istého klienta.
Všímajte si stavové zariadenia v strede. Ak požiadavka odchádza jedným tunelom a odpoveď sa vracia druhým, firewall alebo NAT, ktorý pôvodný tok nikdy nevidel, ju zahodí. Oba tunely preposielajú prevádzku správne a spojenie napriek tomu zlyháva.
Skontrolujte aj MTU po jednotlivých cestách. Cesta s dodatočnou enkapsuláciou zmenšuje použiteľnú veľkosť a prenos, ktorý jedným tunelom prejde, sa na druhom zasekne presne na veľkosti, kde sa menší láme.
Porovnávajte jednu cestu po druhej
Tam, kde to návrh dovoľuje, vyraďte jeden tunel z prevádzky a zopakujte používateľovu úlohu. Ak porucha zmizne, problém patrí ceste, ktorú ste odobrali, a ďalším krokom je porovnať jej konfiguráciu so susednou, nie znova skúmať smerovaciu tabuľku.
Porovnávajte skutočnú aplikáciu, nie opakované pingy. Zaznamenajte, či porucha sleduje určitý ďalší skok, veľkosť paketu alebo prechod po opätovnom pripojení, pretože tieto tri vzorce ukazujú na rôzne opravy.
Na záver zapíšte, prečo sa cesty považujú za rovnocenné a ako má porucha jednu z nich vyradiť z prevádzky. Viaccestnosť je bezpečná len vtedy, keď sú cesty skutočne zameniteľné, a to je návrhové tvrdenie, ktoré stojí za overenie, nie za predpoklad.