Ĉu OpenVPN daŭre puŝas malnovajn vojojn? Kontrolu, kion ĝi ŝargis

Vi aldonas vojon, restartas la servon, rekonektiĝas, kaj la tabelo de la kliento aspektas ĝuste kiel antaŭe. Du malsamaj aferoj povas esti veraj: la servilo neniam ŝargis vian ŝanĝon, aŭ la kliento neniam instalas tion, kion ĝi ricevis. Ili havas nenion komunan krom la simptomo, do la unua paŝo estas trovi, kiun el la du vi havas.

La komparo sube iras de la procezo eksteren, ĉar la procezo estas la sola aŭtoritato pri tio, kiu dosiero validas.

La dosiero, kiun vi redaktis, kaj la dosiero, kiun la procezo legas

Komencu per la unit kaj la komandlinio, kiun ĝi produktis. En systemd-gastiganto, systemctl cat openvpn@server printas la linion ExecStart, kaj instanca unit kutime derivas sian konfiguran vojon de la instanca nomo, do demono startigita kiel openvpn@office legas alian dosieron ol tiu startigita kiel openvpn@server. Komparu tion kun la argv de la kuranta procezo. Ilo por administri konfiguraĵojn aldonas plian manieron perdi la ŝanĝon: ĝi povas skribi ĝustan dosieron en lokon, kiun la unit neniam mencias, kaj tiam sukcesa deplojo aspektas kiel nenio.

Tempomarkoj rapide decidas: se la dosiero estas pli nova ol la starta tempo de la procezo, la procezo ne povis legi ĝin. La firmvaro de la enkursigilo aldonas trian kazon, ĉar multaj modeloj tenas siajn agordojn en flash kaj rekonstruas la konfiguraĵon dum senŝargiĝo, kio faras redaktadon de dosiero sur la disko tute malĝusta tavolo.

Kion la servilo puŝas kaj kion la kliento instalas

Puŝita vojo devas travivi du filtrilojn. Ĉe la servilo ĝi devas stari en la ŝargita konfiguraĵo, ne en komentita bloko aŭ en dosiero specifa por kliento, kies nomo ne kongruas. Ĉe la kliento pull devas esti ŝaltita, kaj neniu pull-filter rajtas forĵeti la opcion. Konektiĝu kun verbosity 4 kaj legu la puŝitajn opciojn, kiujn la kliento raportas: se la vojo aperas en tiu listo, la servilo faris sian taskon kaj la kliento elektas ne instali ĝin.

Dosieroj specifaj por kliento estas ofta fonto de konfuzo. Dosiero nomita laŭ la common name de la atestilo puŝas opciojn nur al tiu kliento, kaj diferenco de unu signo silentigas la puŝadon, sen eraro ĉe iu ajn flanko. La servilo registras la common name, kiun ĝi vidis ĉe konektiĝo, do komparu tiun valoron kun la dosiernomo, ne kun tio, kion vi opinias la nomo de la kliento.

La puŝita prefikso kaj la revena vojo estas malsamaj problemoj

Kliento, kiu intence ignoras redirect-gateway por konservi sian lokan interreton vojon, kreas duan, nerilatan mankon. La sondoj de la servilo atingas la tunelan adreson kaj la respondoj neniam alvenas, ĉar respondo adresita al la tunela IP de la servilo estas enkursigita per la ordinara implicita kluzo de la kliento. La puŝita subreta vojo ne kulpas ĉi tie; mankas vojo, kiu sendas trafikon por la tunela reto de la servilo reen tra la tunela aparato.

Aldoni tiun vojon ĉe la kliento riparas respondojn al sondoj komencitaj de la servilo. Ĝi ne anstataŭas la puŝitan subretan vojon, kaj la malo ankaŭ validas, ĉar la du priskribas kontraŭajn direktojn de vojaĝo.

Komparu la tabelojn ĉe ambaŭ finoj

Post iu ajn ŝanĝo, rekonektiĝu kaj legu la tabelon de la kliento por la puŝita prefikso kaj por la tunela aparato. Poste testu en ambaŭ direktojn: de la kliento al gastiganto en la puŝita subreto, kaj de tiu gastiganto reen al la kliento. Vojo, kiu ekzistas sed portas nenian trafikon, signifas unu el tri aferoj: la kontraŭa flanko ne plusendas, fajroŝirmilo faligas la fluon, aŭ la respondo ne havas vojon reen.

Tenu tri identigilojn kune: la konfiguran vojon, la nomon de unit aŭ instanco, kaj la klientan identecon, per kiu vi testis.

Tiuj tri ŝanĝas la sekvan okazon en kvinminutan kontrolon anstataŭ ripetan esploradon, kaj ili estas tio, kion kolego bezonas, kiam la tunelo fariĝas la problemo de iu alia.

Vojproblemo, kiu postvivas restartigon, ofte tute ne estas enkursiga problemo; la misfunkcio sidas supre de la tabelo, kiun vi daŭre legas.