Zašto rute s jednakim troškom čine kvarove VPN-a teško vidljivima
Kada više tunela dijeli isti trošak, 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 jednog računala, a ne uspijeva s drugoga, dok ping koji pokrenete s pristupnika uspijeva u oba slučaja. Uz više tunela jednakog troška 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 reproducira taj izbor prije bilo kakve promjene.
Jedan ping, više mogućih putova
Kada ruta ima više od jednog sljedećeg skoka uz isti trošak, 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
Reproducirajte izbor umjesto da nagađate. Pitajte jezgru 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 usporedite dva odgovora:
ip route get 10.20.5.7 from 10.20.0.14Novija izdanja iproute2 prihvaćaju i protokol i odredišni port, što je važno kada ih heš uključuje. Usporedite 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 što 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 pozornost 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 točno na veličini gdje se manji lomi.
Usporedite 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 usporediti njegovu konfiguraciju sa susjednom, a ne preispitivati tablicu usmjeravanja.
Usporedite 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 ekvivalentnima 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.