De ce rutele cu cost egal fac defecțiunile VPN greu de observat
Când mai multe tuneluri împart același cost, fiecare flux poate lua altul. Un ping reușit nu spune nimic despre calea pe care o folosește de fapt aplicația dumneavoastră.
Un utilizator raportează că aplicația internă funcționează de pe o mașină și eșuează de pe alta, în timp ce ping-ul rulat de pe gateway reușește în ambele cazuri. Cu mai multe tuneluri cu cost egal, aceasta nu este o contradicție. Fiecare flux este plasat pe propriul salt următor, așa că verificarea dumneavoastră și sesiunea utilizatorului pot folosi pur și simplu căi diferite. Parcursul de mai jos reproduce această alegere înainte de a schimba ceva.
Un ping, mai multe căi posibile
Când o rută are mai mult de un salt următor cu același cost, routerul trebuie să aleagă unul pentru fiecare pachet. Majoritatea implementărilor aplică un hash câmpurilor din pachet, de obicei adresele sursă și destinație împreună cu protocolul și porturile, astfel încât răspunsurile să rămână pe aceeași cale. Aplicații diferite, sau chiar conexiuni diferite ale aceleiași aplicații, produc hash-uri diferite.
De aceea un diagnostic de pe gateway dovedește atât de puțin. Verificarea proprie a gateway-ului are propriile adrese și porturi și, prin urmare, propriul hash. Poate ajunge pe tunelul sănătos în timp ce utilizatorul continuă să ajungă pe cel defect.
Cum alege platforma un salt următor
Reproduceți alegerea în loc să o ghiciți. Întrebați nucleul ce rută ar folosi pentru aceeași sursă și destinație ca sesiunea care eșuează. Acea căutare include câmpuri pe care o căutare simplă după destinație le ignoră. Rulați-o și de pe un client care funcționează și comparați cele două răspunsuri:
ip route get 10.20.5.7 from 10.20.0.14Versiunile mai noi de iproute2 acceptă și protocolul și portul de destinație, ceea ce contează atunci când hash-ul le include. Comparați acea ieșire cu aceeași căutare de pe un client care funcționează, iar diferența este dovada care vă lipsea.
| 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 |
Urmați fluxul care eșuează, nu tabela de rutare
Tabela de rutare listează ambele tuneluri și, prin definiție, pare corectă. Întrebarea este ce face fiecare tunel cu pachetul după ce este ales. Verificați că ambele transportă aceleași prefixe protejate, aceeași permisiune de redirecționare și o cale de întoarcere care ajunge la același client.
Fiți atenți la dispozitivele cu stare din mijloc. Dacă o cerere iese printr-un tunel și răspunsul se întoarce prin celălalt, un firewall sau un NAT care nu a văzut niciodată fluxul original o va elimina. Ambele tuneluri redirecționează traficul corect, iar conexiunea tot eșuează.
Verificați și MTU-ul pe fiecare cale. O cale cu o încapsulare suplimentară micșorează dimensiunea utilizabilă, iar un transfer care reușește pe un tunel se blochează pe celălalt exact la dimensiunea la care cel mai mic se rupe.
Comparați o singură cale deodată
Acolo unde proiectul permite mentenanță, scoateți un tunel din serviciu și repetați sarcina utilizatorului. Dacă defectul dispare, problema aparține căii pe care ați eliminat-o, iar pasul următor este să comparați configurația ei cu cea a vecinului, nu să reexaminați tabela de rutare.
Comparați aplicația reală, nu ping-uri repetate. Notați dacă defectul urmează un anumit salt următor, o dimensiune de pachet sau o tranziție după reconectare, pentru că aceste trei tipare indică reparații diferite.
În final, notați de ce căile sunt considerate echivalente și cum ar trebui un defect să scoată una dintre ele din serviciu. Multipath-ul este sigur doar când căile sunt cu adevărat interschimbabile, iar aceasta este o afirmație de proiectare care merită verificată, nu presupusă.