Kial samkostaj itineroj malfaciligas vidi VPN-miskondutojn
Kiam pluraj tunoj dividas la saman koston, ĉiu fluo povas preni alian. Sukcesa ping diras nenion pri la vojo, kiun via aplikaĵo fakte uzas.
Uzanto raportas, ke la interna aplikaĵo funkcias de unu maŝino kaj malsukcesas de alia, dum la ping, kiun vi rulas de la kluzo, sukcesas en ambaŭ kazoj. Kun pluraj tunoj de egala kosto, tio ne estas kontraŭdiro. Ĉiu fluo estas metita sur sian propran sekvan saltpunkton, do via kontrolo kaj la seanco de la uzanto eble simple uzas malsamajn vojojn. La sekva trairo reproduktas tiun elekton antaŭ ol io ajn ŝanĝiĝos.
Unu ping, pluraj eblaj vojoj
Kiam itinero havas pli ol unu sekvan saltpunkton je la sama kosto, la enkursigilo devas elekti unu por ĉiu pakaĵo. Plej multaj efektivigoj hakas kampojn de la pakaĵo, kutime la fontajn kaj celajn adresojn kune kun la protokolo kaj la pordoj, por ke respondoj restu sur la sama vojo. Malsamaj aplikaĵoj, eĉ malsamaj konektoj de unu aplikaĵo, produktas malsamajn haketojn.
Tial diagnozo de la kluzo pruvas tiel malmulte. La propra kontrolo de la kluzo havas proprajn adresojn kaj pordojn, kaj do propran haketon. Ĝi povas surteriĝi sur la sana tuno dum la uzanto daŭre surteriĝas sur la rompita.
Kiel la platformo elektas sekvan saltpunkton
Reproduktu la elekton anstataŭ diveni ĝin. Demandu la kernon, kiun itinero ĝi uzus por la sama fonto kaj celo kiel la malsukcesanta seanco. Tiu serĉo inkluzivas kampojn, kiujn ordinara celoserĉo ignoras. Rulu ĝin ankaŭ de funkcianta kliento kaj komparu la du respondojn:
ip route get 10.20.5.7 from 10.20.0.14Pli novaj eldonoj de iproute2 ankaŭ akceptas la protokolon kaj la celan pordon, kio gravas kiam la haketo inkluzivas ilin. Komparu tiun eligon kun la sama serĉo de funkcianta kliento, kaj la diferenco estas la pruvo, kiun vi mankis.
| 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 |
Sekvu la malsukcesantan fluon, ne la itinertabelon
La itinertabelo listigas ambaŭ tunojn kaj laŭdifine aspektas ĝusta. La demando estas, kion ĉiu tuno faras kun la pakaĵo post kiam ĝi estas elektita. Kontrolu, ke ambaŭ portas la samajn protektitajn prefiksojn, la saman antaŭenigan permeson kaj reiran vojon, kiu atingas la saman klienton.
Atentu ŝtatajn aparatojn meze. Se peto eliras tra unu tuno kaj la respondo revenas tra la alia, fajroŝirmilo aŭ NAT, kiu neniam vidis la originan fluon, forĵetos ĝin. La du tunoj ambaŭ antaŭenigas trafikon ĝuste, kaj la konekto ankoraŭ malsukcesas.
Kontrolu ankaŭ la MTU por ĉiu vojo. Vojo kun plia enkapsuligo malgrandigas la uzeblan grandecon, kaj transdono, kiu sukcesas tra unu tuno, haltas sur la alia precize je la grando, kie la pli malgranda rompiĝas.
Komparu unu vojon samtempe
Kie la dezajno permesas prizorgon, eligu unu tunon el servo kaj ripetu la taskon de la uzanto. Se la miskonduto malaperas, la problemo apartenas al la forigita vojo, kaj la sekva paŝo estas kompari ĝian agordon kun la najbara anstataŭ reekzameni la enkursigan tabelon.
Komparu la realan aplikaĵon, ne ripetitajn pingojn. Notu, ĉu la miskonduto sekvas apartan sekvan saltpunkton, pakaĵan grandecon aŭ transiron post rekonekto, ĉar tiuj tri ŝablonoj montras al malsamaj riparoj.
Fine, skribu, kial la vojoj estas konsiderataj ekvivalentaj kaj kiel miskonduto laŭsupoze forigos unu el ili el servo. Multvojo estas sekura nur kiam la vojoj vere estas interŝanĝeblaj, kaj tio estas dezajna aserto inda je kontrolo anstataŭ je supozo.