Zakaj poti z enako ceno otežujejo opazovanje napak VPN
Ko si več tunelov deli enako ceno, lahko vsak tok izbere drugega. Uspešen ping ne pove ničesar o poti, ki jo vaša aplikacija dejansko uporablja.
Uporabnik poroča, da notranja aplikacija deluje z enega računalnika in ne uspe z drugega, medtem ko ping, ki ga zaženete iz prehoda, uspe v obeh primerih. Pri več tunelih z enako ceno to ni protislovje. Vsak tok se postavi na svoj naslednji skok, zato lahko vaše preverjanje in uporabnikova seja preprosto uporabljata različne poti. Spodnji pregled ta izbor reproducira, preden se karkoli spremeni.
En ping, več možnih poti
Ko ima pot več kot en naslednji skok z enako ceno, mora usmerjevalnik izbrati enega na paket. Večina izvedb zgoščuje polja iz paketa, običajno izvorni in ciljni naslov skupaj s protokolom in vrati, da odgovori ostanejo na isti poti. Različne aplikacije, celo različne povezave ene aplikacije, ustvarijo različne zgostitve.
Zato diagnostika s prehoda dokaže tako malo. Lastno preverjanje prehoda ima svoje naslove in vrata ter s tem svojo zgostitev. Lahko pristane na zdravem tunelu, medtem ko uporabnik še naprej pristaja na pokvarjenem.
Kako platforma izbere naslednji skok
Izbor reproducirajte, namesto da bi ga ugibali. Vprašajte jedro, katero pot bi uporabilo za isti izvor in cilj kot seja, ki ne uspe. To iskanje vključuje polja, ki jih navadno iskanje po cilju prezre. Zaženite ga tudi z delujočega odjemalca in primerjajte oba odgovora:
ip route get 10.20.5.7 from 10.20.0.14Novejše izdaje iproute2 sprejmejo tudi protokol in ciljna vrata, kar je pomembno, ko jih zgostitev vključuje. Primerjajte ta izhod z istim iskanjem z delujočega odjemalca in razlika je dokaz, ki vam je manjkal.
| 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 |
Sledite toku, ki ne uspe, ne tabeli usmerjanja
Tabela usmerjanja navaja oba tunela in je po definiciji videti pravilna. Vprašanje je, kaj vsak tunel naredi s paketom, ko je izbran. Preverite, da oba nosita enake zaščitene predpone, enako dovoljenje za posredovanje in povratno pot, ki doseže istega odjemalca.
Bodite pozorni na naprave s stanjem v sredini. Če zahteva odide skozi en tunel in se odgovor vrne skozi drugega, bo požarni zid ali NAT, ki ni nikoli videl izvirnega toka, zahtevo zavrgel. Oba tunela pravilno posredujeta promet, povezava pa vseeno ne uspe.
Preverite tudi MTU na vsaki poti. Pot z dodatno inkapsulacijo zmanjša uporabno velikost, in prenos, ki uspe na enem tunelu, se na drugem ustavi natanko pri velikosti, kjer se manjši zlomi.
Primerjajte eno pot naenkrat
Kjer zasnova dopušča vzdrževanje, vzemite en tunel iz obratovanja in ponovite uporabnikovo nalogo. Če napaka izgine, težava pripada odstranjeni poti, in naslednji korak je primerjati njeno konfiguracijo s sosednjo, ne pa znova pregledovati tabele usmerjanja.
Primerjajte resnično aplikacijo, ne ponovljenih pingov. Zabeležite, ali napaka sledi določenemu naslednjemu skoku, velikosti paketa ali prehodu po ponovni povezavi, ker ti trije vzorci kažejo na različna popravila.
Na koncu zapišite, zakaj veljajo poti za enakovredne in kako naj napaka eno od njih umakne iz obratovanja. Večpotnost je varna le, ko so poti res zamenljive, in to je načrtovalska trditev, ki jo je vredno preveriti, ne pa predpostaviti.