Zašto rute s jednakom cenom čine kvarove VPN-a teško vidljivim
Kada više tunela deli istu cenu, svaki tok može izabrati drugi. Uspešan ping ne govori ništa o putu koji vaša aplikacija stvarno koristi.
Korisnik prijavljuje da interna aplikacija radi sa jedne mašine, a ne uspeva sa druge, dok ping koji pokrenete sa pristupnika uspeva u oba slučaja. Uz više tunela jednake cene to nije protivrečnost. Svaki tok se postavlja na sopstveni sledeći skok, pa vaša provera i korisnička sesija jednostavno mogu koristiti različite putove. Pregled u nastavku reprodukuje taj izbor pre bilo kakve promene.
Jedan ping, više mogućih putova
Kada ruta ima više od jednog sledećeg skoka uz istu cenu, usmerivač mora izabrati jedan po paketu. Većina implementacija hešira polja iz paketa, obično izvorišnu i odredišnu adresu zajedno sa 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 sa pristupnika dokazuje tako malo. Sopstvena provera pristupnika 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 sledeći skok
Reprodukujte izbor umesto da nagađate. Pitajte jezgro koju bi rutu koristilo za isto izvorište i odredište kao neuspela sesija. To pretraživanje uključuje polja koja obično pretraživanje odredišta ignoriše. Pokrenite ga i sa 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 sa istim pretraživanjem sa 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 neuspeli tok, a ne tabelu ruta
Tabela ruta navodi oba tunela i po definiciji izgleda ispravno. Pitanje je šta svaki tunel radi sa paketom nakon što bude izabran. Proverite da oba nose iste zaštićene prefikse, istu dozvolu prosleđivanja i povratni put koji stiže do istog klijenta.
Obratite pažnju na uređaje sa stanjem u sredini. Ako zahtev izađe kroz jedan tunel, a odgovor se vrati kroz drugi, zaštitni zid ili NAT koji nikada nije video izvorni tok odbaciće ga. Oba tunela ispravno prosleđuju promet, a veza ipak pada.
Proverite i MTU po putu. Put sa dodatnom inkapsulacijom smanjuje iskoristivu veličinu, a prenos koji uspe na jednom tunelu zapne na drugom tačno na veličini gde se manji lomi.
Uporedite jedan put po jedan
Gde dizajn dopušta održavanje, izbacite jedan tunel iz upotrebe i ponovite korisnikov zadatak. Ako kvar nestane, problem pripada putu koji ste uklonili, a sledeći korak je uporediti njegovu konfiguraciju sa susednom, a ne preispitivati tabelu usmeravanja.
Uporedite stvarnu aplikaciju, a ne ponovljene pingove. Zabeležite prati li kvar određeni sledeći skok, veličinu paketa ili prelaz 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 trebalo izbaciti jedan iz upotrebe. Višeputnost je sigurna samo kada su putovi doista zamenljivi, a to je projektna tvrdnja koju vredi proveriti, a ne pretpostaviti.