OpenVPN gurnute rute nisu instalirane: tajming, prava ili pravila

Server tvrdi da je gurnuo rutu, klijent tvrdi da je povezan, a odredište je i dalje nedostupno. Tri uzroka proizvode upravo tu sliku. Dodavanje rute je izvršeno prije nego što je uređaj postojao, klijentu su nedostajala prava da promijeni tablicu ili su pravila rekla klijentu da zanemari gurnute opcije.

Spolja izgledaju identično i traže različite popravke. Pročitajte klijentski dnevnik na mjestu gdje se donosi odluka o ruti.

Dokažite da ruta nedostaje, a ne da je samo pokvarena

Počnite dokazom da ruta nedostaje, a ne da je pokvarena. Na Linuxu ip route show dev tun0 navodi šta je klijent instalirao na tunelskom uređaju. Na Windowsu route print ili Get-NetRoute pokazuje istu stvar u obliku tablice.

Ruta koja postoji, ali ne prosljeđuje saobraćaj, drugi je problem. To preusmjerava istragu na pravila prosljeđivanja i vatrozida, a ne na instalaciju rute.

Tajming: dodavanje je izvršeno prije nego što je uređaj postojao

Klijent analizira serverov PUSH_REPLY nakon što je kontrolni kanal uspostavljen i nakon što je konfigurisao interfejs. Tek tada dira tablicu rutiranja, koristeći mehanizam koji platforma pruža. Linux ide kroz netlink; Windows koristi API kojem treba povišeni token. Skripta ili klijent koji dodaje rute čim pročita konfiguraciju može se izvršiti prije nego što TUN/TAP uređaj postoji, a jezgro odbija dodavanje.

Ista trka objašnjava zašto ruta otkucana rukom radi, a automatska ne: dok je otkucate, interfejs je već podignut.

route-delay postoji za ovaj slučaj, a route-up imenuje skriptu koja se izvršava nakon konfigurisanja interfejsa i ruta. Rute koje zavise od adrese tunela stavite u taj hak, a ne u ranu fazu.

Prava: ko smije mijenjati tablicu

Promjena Windows tablice rutiranja traži povišeni token. GUI koji je pokrenuo standardni korisnik može postaviti adresu adaptera kroz servis i ipak ne moći dodati rutu. Dnevnik tada prikazuje grešku tipa odbijenog pristupa, a ne nedostajuće guranje.

Pokretanje GUI-ja kao administrator ili korištenje klijenta zasnovanog na servisu mijenja taj ishod. Zakazani zadatak koji pokreće klijent bez potrebnog tokena ne mijenja ga.

Provjerite pod kojim računom klijent zapravo radi prije bilo kakve promjene. Verzija i način rada servisa odlučuju koji su uzroci uopće mogući, pa zabilježite oboje uz izlaz rute.

Pravila: gurnute rute se mogu namjerno odbaciti

route-nopull tjera klijent da zanemari rute koje server gura, uključujući gurnutu zadanu rutu, dok se adresa tunela i dalje prihvata. Gurnute DNS i DHCP opcije odbacuje ista direktiva. Takav klijent nije neispravan; on očekuje izričite redove ruta u vlastitoj konfiguraciji.

route-noexec je drugačija kontrola: potpuno zaustavlja klijent u izvršavanju promjena ruta. Topologija koju klijent ne može mapirati može dati sličan rezultat, a ruta se bilježi kao odbijena, a ne dodana. Pročitajte red dnevnika koji prijavljuje odluku umjesto da pogađate koji od tri uzroka vrijedi. Zatim provjerite efektivni profil, jer uvoznik ili alat za upravljanje može dodati opcije koje korisnik nikada nije uređivao.

Profil koji u tekstualnom uređivaču izgleda čisto ipak može nositi dodanu direktivu u vrijeme izvršavanja.

Uporedite listu guranja s tablicom

Nakon povezivanja stavite serverovu listu guranja pored klijentske tablice. Na Linuxu je to ip route show dev tun0; na Windowsu route print ili Get-NetRoute. Ako ruta nedostaje, prvo popravite instalaciju. Ako postoji, a saobraćaj ne prolazi, prijeđite na pravila prosljeđivanja i vatrozida.

Zabilježite verziju klijenta, račun pod kojim radi i to da li se zasniva na servisu. Te tri činjenice kažu sljedećoj osobi koji su uzroci isključeni.