Zašto rute s jednakom cijenom čine kvarove VPN-a teško vidljivim
Kada više tunela dijeli istu cijenu, svaki tok može izabrati drugi. Uspješan ping ne govori ništa o putu koji vaša aplikacija stvarno koristi.
Korisnik prijavljuje da interna aplikacija radi s jedne mašine, a ne uspijeva s druge, dok ping koji pokrenete s pristupnika uspijeva u oba slučaja. Uz više tunela jednake cijene to nije proturječje. Svaki tok se postavlja na vlastiti sljedeći skok, pa vaša provjera i korisnička sesija jednostavno mogu koristiti različite putove. Pregled u nastavku reprodukuje taj izbor prije bilo kakve promjene.
Jedan ping, više mogućih putova
Kada ruta ima više od jednog sljedećeg skoka uz istu cijenu, usmjerivač mora izabrati jedan po paketu. Većina implementacija hešira polja iz paketa, obično izvorišnu i odredišnu adresu zajedno s protokolom i portovima, kako bi odgovori ostali na istom putu. Različite aplikacije, pa i različite veze jedne aplikacije, daju različite heševe.
Zato dijagnostika s pristupnika dokazuje tako malo. Pristupnikova vlastita provjera ima svoje adrese i portove, a time i svoj heš. Može završiti na zdravom tunelu dok korisnik stalno završava na pokvarenom.
Kako platforma bira sljedeći skok
Reprodukujte izbor umjesto da nagađate. Pitajte jezgro koju bi rutu koristilo za isto izvorište i odredište kao neuspjela sesija. To pretraživanje uključuje polja koja obično pretraživanje odredišta ignorira. Pokrenite ga i s radnog klijenta i uporedite dva odgovora:
ip route get 10.20.5.7 from 10.20.0.14Novija izdanja iproute2 prihvataju i protokol i odredišni port, što je važno kada ih heš uključuje. Uporedite taj izlaz s istim pretraživanjem s radnog klijenta i razlika je dokaz koji vam je nedostajao.
| 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 |
Pratite neuspjeli tok, a ne tablicu ruta
Tablica ruta navodi oba tunela i po definiciji izgleda ispravno. Pitanje je šta svaki tunel radi s paketom nakon što bude izabran. Provjerite da oba nose iste zaštićene prefikse, istu dozvolu prosljeđivanja i povratni put koji stiže do istog klijenta.
Obratite pažnju na uređaje sa stanjem u sredini. Ako zahtjev izađe kroz jedan tunel, a odgovor se vrati kroz drugi, vatrozid ili NAT koji nikada nije vidio izvorni tok odbacit će ga. Oba tunela ispravno prosljeđuju promet, a veza ipak pada.
Provjerite i MTU po putu. Put s dodatnom inkapsulacijom smanjuje iskoristivu veličinu, a prijenos koji uspije na jednom tunelu zapne na drugom tačno na veličini gdje se manji lomi.
Uporedite jedan put po jedan
Gdje dizajn dopušta održavanje, izbacite jedan tunel iz upotrebe i ponovite korisnikov zadatak. Ako kvar nestane, problem pripada putu koji ste uklonili, a sljedeći korak je uporediti njegovu konfiguraciju sa susjednom, a ne preispitivati tablicu usmjeravanja.
Uporedite stvarnu aplikaciju, a ne ponovljene pingove. Zabilježite prati li kvar određeni sljedeći skok, veličinu paketa ili prijelaz nakon ponovnog povezivanja, jer ta tri obrasca upućuju na različite popravke.
Na kraju zapišite zašto se putovi smatraju ekvivalentnim i kako bi kvar trebao izbaciti jedan iz upotrebe. Višeputnost je sigurna samo kada su putovi doista zamjenjivi, a to je projektna tvrdnja koju vrijedi provjeriti, a ne pretpostaviti.