OpenVPN stalno gura stare rute? Provjerite šta je učitao

Dodate rutu, restartujete servis, ponovo se povežete, a klijentova tabela izgleda isto kao prije. Moguće su dvije različite stvari: server nikad nije učitao vašu izmjenu ili klijent nikad nije instalirao ono što je primio. Zajednički im je samo simptom, pa je prvi korak otkriti koji je od ta dva slučaja kod vas.

Poređenje ispod ide od procesa prema van, jer proces je jedini autoritet o tome koji fajl važi.

Fajl koji ste uredili i fajl koji proces čita

Počnite od unit-a i komandne linije koju je proizveo. Na systemd hostu systemctl cat openvpn@server ispisuje liniju ExecStart, a instance unit obično izvodi putanju konfiguracije iz imena instance, pa daemon pokrenut kao openvpn@office čita drugačiji fajl od onog pokrenutog kao openvpn@server. Uporedite to s argv pokrenutog procesa. Alat za upravljanje konfiguracijom dodaje još jedan način da se izmjena izgubi: može napisati ispravan fajl na mjesto koje unit nikad ne spominje, pa uspješan deploy izgleda kao da nije ništa uradio.

Vremenske oznake to brzo rješavaju: ako je fajl noviji od vremena pokretanja procesa, proces ga nije mogao pročitati. Firmware rutera dodaje treći slučaj, jer mnogi modeli drže postavke u flashu i ponovo grade konfiguraciju tokom podizanja, što uređivanje fajla na disku čini potpuno pogrešnim slojem.

Šta server gura i šta klijent instalira

Gurnuta ruta mora proći dva filtera. Na serveru mora stajati u učitanoj konfiguraciji, a ne u zakomentarisanom bloku ili u fajlu specifičnom za klijenta čije se ime ne poklapa. Na klijentu pull mora biti uključen i nijedan pull-filter ne smije odbacivati tu opciju. Povežite se s verbosity 4 i pročitajte gurnute opcije koje klijent prijavljuje: ako se ruta pojavi na toj listi, server je odradio svoj dio, a klijent bira da je ne instalira.

Fajlovi specifični za klijenta čest su izvor zabune. Fajl nazvan po common name certifikata gura opcije samo tom klijentu, a razlika od jednog znaka tiho zaustavlja guranje, bez greške ni na jednoj strani. Server bilježi common name koji je vidio pri povezivanju, pa uporedite tu vrijednost s imenom fajla, a ne s onim kako mislite da se klijent zove.

Gurnuti prefiks i povratna ruta su različiti problemi

Klijent koji namjerno ignoriše redirect-gateway da bi zadržao svoju lokalnu internet putanju stvara drugu, nepovezanu prazninu. Serverove probe stižu do adrese tunela, a odgovori nikad ne dolaze, jer se odgovor upućen na serverovu tunelsku IP adresu rutira kroz klijentov obični podrazumijevani gateway. Gurnuta ruta za podmrežu ovdje nije kriva; nedostaje ruta koja promet za serverovu tunelsku mrežu šalje natrag kroz tunelski uređaj.

Dodavanje te rute na klijentu popravlja odgovore na probe koje pokreće server. Ona ne zamjenjuje gurnutu rutu za podmrežu, i obrnuto vrijedi isto, jer dvije opisuju suprotne smjerove kretanja.

Uporedite tabele na oba kraja

Nakon svake izmjene ponovo se povežite i pročitajte klijentovu tabelu za gurnuti prefiks i za tunelski uređaj. Zatim testirajte u oba smjera: od klijenta do hosta na gurnutoj podmreži i od tog hosta natrag do klijenta. Ruta koja postoji, ali ne nosi promet, znači jedno od tri: udaljena strana ne prosljeđuje, firewall odbacuje tok ili odgovor nema puta natrag.

Držite tri identifikatora zajedno: putanju konfiguracije, ime unit-a ili instance i identitet klijenta s kojim ste testirali.

Ta tri pretvaraju sljedeći slučaj u petominutnu provjeru umjesto ponovne istrage, i upravo su ono što kolegi treba kad tunel postane tuđi problem.

Problem s rutom koji preživi restart često nije problem rutiranja; kvar je iznad tabele koju stalno čitate.