Tablica usmjeravanja nasuprot stvarnom pretraživanju: kuda ide VPN saobraćaj

Ispis tablice usmjeravanja najmanje je korisna dijagnostika u rješavanju problema s VPN-om i najčešće zalijepljena. Četrdeset redova prefiksa govori vam šta je mašina mogla učiniti, a ne šta je učinila za zahtjev koji nije uspio. Mehanizam koji zapravo želite jeste pretraživanje: s obzirom na ovaj izvor i ovo odredište, koje pravilo se poklopilo, koja tablica je konsultovana i koje su sučelje i sljedeći skok izašli. Pođite od jednog odredišta i jednog izvora, pa čitajte tablicu s tim pitanjem u ruci i isti izlaz postaje dokaz umjesto šuma.

Tablica je skup kandidata, a ne odluka

Svaki unos opisuje prefiks i šta učiniti sa saobraćajem koji se poklapa s njim: pošalji ga na sučelje, predaj ga sljedećem skoku ili ga odbaci. Ništa na tom spisku nije poredano po namjeri, a unos koji se čovjeku čini najspecifičnijim nije uvijek onaj koji kernel odabere, jer odabir slijedi najduže poklapanje prefiksa, a među jednakim prefiksima metriku.

Zato je prvi potez pitati kernel, a ne čitati spisak. Naredba za pretraživanje odgovara za odredište, a s argumentom izvora odgovara za tačan par koji bi koristila proslijeđena ili vezana veza:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Svaka adresa iznad je dokumentacijski primjer. Poanta je oblik odgovora: sučelje, odabrana izvorna adresa, pristupnik i tablica iz koje je unos došao. Ako se taj izlaz ne poklapa sa sučeljem koje ste očekivali, lokalizirali ste problem jednom naredbom i nikakvo čitanje pune tablice ne bi vam reklo koji je kandidat pobijedio.

Pretraživanje prolazi pravila, pa tablice

Na Linuxu je odluka u dvije faze. Pravila politike procjenjuju se po redu prioriteta, a prvo pravilo koje se poklopi imenuje tablicu koju treba konsultovati; ta tablica zatim radi poklapanje najdužeg prefiksa. Pravilo može da se poklapa po izvoru, odredištu, oznaci firewall-a, sučelju ili kombinaciji, zbog čega ispis glavne tablice može biti potpuno tačan i potpuno nevažan za paket koji istražujete.

ip rule show
ip route show table all | head -40
ip route show table 100

Ako pravilo šalje saobraćaj iz vašeg VPN pula u tablicu 100, onda je tablica 100 ta koja je bitna, i glavna tablica je mamac. To je i mehanizam iza usmjeravanja zasnovanog na izvoru na ruteru: isto odredište može imati dva različita odgovora zavisno od toga odakle paket dolazi, i samo pretraživanje s argumentom izvora otkriva koji se primjenjuje.

IPv6 ima svoja pravila i tablice. Dizajn koji pokreće obje porodice treba oba pretraživanja, a ispravan IPv4 odgovor ne govori ništa o v6 putu koji dual-stack klijent može preferirati.

Šta VPN klijent instalira

Klijenti obično ne zamjenjuju zadanu rutu, jer bi to slomilo vlastiti vanjski put tunela. Instaliraju nešto specifičnije što pobjeđuje po dužini prefiksa: par polu-zadanih ruta koje pokrivaju 0.0.0.0/1 i 128.0.0.0/1 klasičan je trik, jer su obje duži prefiksi od 0.0.0.0/0 i zajedno pokrivaju cijeli prostor. Drugi instaliraju određene privatne prefikse plus pravilo politike, a neki dodaju oznaku tako da se hvata samo odabrani saobraćaj.

Zato "VPN mi nije promijenio zadanu rutu" nije dokaz kvara. Provjerite šta je ipak dodao i da li dotično odredište pada unutar tih prefiksa:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Dvije polu-rute lako se propuste u ispisu jer ne izgledaju kao zadana ruta. Split-tunnel konfiguracija koja je zaboravila uključiti prefiks proizvodi tačno simptom koji jurite: aplikacija koja bi trebalo da koristi tunel umjesto toga razrješava i povezuje se lokalno. Uporedite instalirane prefikse s odredištima koja korisniku stvarno trebaju, a ne s adresama koje ste slučajno testirali. Split-tunnel lista koja pokriva datotečni server ali ne i njegov razrješivač proizvodi vezu koja se razrješava na javnu adresu i zatim ne uspijeva autentifikaciju, što izgleda kao problem s lozinkom a jeste problem s rutom.

Vanjski put mora takođe preživjeti

Tunel je i sam saobraćaj. Paketi koji nose inkapsulirani teret idu na adresu partnera preko fizičkog sučelja i taj put ne smije biti usmjeren natrag u tunel. Kada jeste, dobijate prepoznatljiv kvar u kojem se tunel uspostavi i zatim prestane propuštati saobraćaj, jer je transport za tunel sada unutar tunela.

Provjerite adresu partnera kao što ste provjerili unutrašnje odredište i potvrdite da se razrješava na fizičko sučelje, a ne na tunel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekurzivna ruta, pravilo politike koje hvata partnera ili zadana ruta koju je zamijenio klijent punog tunela tri su uobičajena uzroka. Sva tri su vidljiva u vanjskom pretraživanju i nijedan nije vidljiv u ispisu glavne tablice uzetom nakon činjenice.

Šta vam izlaz usmjeravanja ne može reći

Ispravno pretraživanje znači da bi kernel poslao paket negdje razumno. To ne znači da ga firewall dozvoljava, da ga IPsec politika pokriva, da ga NAT pravilo prevodi ili da udaljena strana ima povratnu rutu. Svako od toga je kasnija faza, i strongSwan bilješke o prosljeđivanju opisuju lanac kroz koji paket mora proći na oba kraja.

Također ne uzima u obzir vezivanje na razini aplikacije. Proces se može vezati za sučelje, postaviti oznaku ili koristiti vlastiti razrješivač i povezati se pod imenom koje se razrješava drukčije od onoga što ste testirali. Kada je pretraživanje ispravno a veza i dalje ne uspijeva, sljedeće pitanje je koji proces je ostvaruje i vidi li taj proces istu tablicu koju vidite vi.

Zato držite dijagnozu poredanom: imenujte odredište i izvor, pokrenite pretraživanje, čitajte samo tablicu i pravilo koje je pretraživanje imenovalo, pa testirajte sljedeću fazu. Taj slijed drži istragu usmjeravanja u minutama i ostavlja zapis koji neko drugi može slijediti, što zalijepljena tablica nikada ne čini.