OpenVPN še vedno potiska stare poti? Preverite, kaj je naložil

Dodate pot, znova zaženete storitev, se znova povežete in tabela odjemalca je videti natanko tako kot prej. Resnični sta lahko dve različni stvari: strežnik ni naložil vaše spremembe ali odjemalec ni namestil tega, kar je prejel. Skupna jima je le simptom, zato je prvi korak ugotoviti, kateri od obeh primerov imate.

Primerjava spodaj gre od procesa navzven, ker je proces edini organ, ki ve, katera datoteka velja.

Datoteka, ki ste jo uredili, in datoteka, ki jo bere proces

Začnite pri unit in ukazni vrstici, ki jo je ustvaril. Na gostitelju s systemd systemctl cat openvpn@server izpiše vrstico ExecStart, instančni unit pa navadno izpelje pot do konfiguracije iz imena instance, zato daemon, zagnan kot openvpn@office, bere drugo datoteko kot tisti, zagnan kot openvpn@server. Primerjajte to z argv delujočega procesa. Orodje za upravljanje konfiguracije doda še en način, da izgubite spremembo: pravilno datoteko lahko zapiše na mesto, ki ga unit nikoli ne omeni, in takrat je uspešna namestitev videti kot nič.

Časovni žigi to hitro razrešijo: če je datoteka novejša od začetnega časa procesa, je proces ni mogel prebrati. Vdelana programska oprema usmerjevalnika doda tretji primer, ker mnogi modeli hranijo nastavitve v flash pomnilniku in ob zagonu znova sestavijo konfiguracijo, kar naredi urejanje datoteke na disku povsem napačno plast.

Kaj potiska strežnik in kaj namesti odjemalec

Potisnjena pot mora prestati dva filtra. Na strežniku mora biti v naloženi konfiguraciji, ne v zakomentiranem bloku ali v datoteki, specifični za odjemalca, katere ime se ne ujema. Na odjemalcu mora biti pull omogočen in noben pull-filter ne sme zavreči te možnosti. Povežite se z verbosity 4 in preberite potisnjene možnosti, ki jih poroča odjemalec: če je pot na tem seznamu, je strežnik opravil svoje delo in odjemalec se odloča, da je ne bo namestil.

Datoteke, specifične za odjemalca, so pogost vir zmede. Datoteka, poimenovana po common name potrdila, potiska možnosti le temu odjemalcu, in razlika enega znaka tiho ustavi potiskanje, brez napake na nobeni strani. Strežnik zapiše common name, ki ga je videl ob povezavi, zato to vrednost primerjajte z imenom datoteke, ne s tem, kar mislite, da je ime odjemalca.

Potisnjena predpona in povratna pot sta različni težavi

Odjemalec, ki namerno ignorira redirect-gateway, da obdrži svojo lokalno pot v internet, ustvari drugo, nepovezano vrzel. Sonde strežnika dosežejo naslov tunela, odgovori pa nikoli ne pridejo, ker se odgovor, naslovljen na IP tunela strežnika, usmerja prek običajne privzete prehodne točke odjemalca. Tu ni kriva potisnjena pot podomrežja; manjka pot, ki promet za omrežje tunela strežnika pošlje nazaj skozi tunelsko napravo.

Dodajanje te poti na odjemalcu popravi odgovore na sonde, ki jih začne strežnik. Ne nadomešča potisnjene poti podomrežja, in obratno velja tudi, ker obe opisujeta nasprotni smeri gibanja.

Primerjajte tabeli na obeh koncih

Po vsaki spremembi se znova povežite in preberite tabelo odjemalca za potisnjeno predpono in za tunelsko napravo. Nato preizkusite v obe smeri: od odjemalca do gostitelja v potisnjenem podomrežju in od tega gostitelja nazaj do odjemalca. Pot, ki obstaja, a ne prenaša prometa, pomeni eno od treh: druga stran ne posreduje, požarni zid zavrže tok ali odgovor nima poti nazaj.

Držite skupaj tri identifikatorje: pot do konfiguracije, ime unit ali instance in identiteto odjemalca, s katerim ste testirali.

Ti trije spremenijo naslednji dogodek v petminutno preverjanje namesto nove preiskave in prav njih potrebuje sodelavec, ko tunel postane problem nekoga drugega.

Težava s potjo, ki preživi ponovni zagon, pogosto sploh ni težava usmerjanja; napaka je višje od tabele, ki jo nenehno berete.