Servilo aŭ kliento: kiu OpenVPN-unuo sur Pi kun duobla rolo

Du OpenVPN-procezoj funkcias sur Pi, kiu samtempe akceptas migrantajn uzantojn kaj atingas supran provizanton, kaj ili dividas preskaŭ nenion krom la aparataro. Unu aŭskultas alvenantajn tunelojn dum la alia alvokas eksteren. Ĉiu legas sian propran dosierujon, kaj ĉiu havas sian propran fiaskmanieron. Restartigi la malĝustan estas la plej ofta maniero, per kiu klienta riparo anstataŭe renversas la aŭskultanton.

Kongruigu la unuan nomon kun la dosierujo, kiun ĝi ŝargas

Upstream 2.6 liveras du ŝablonajn unuojn, [email protected] kaj [email protected]. La servila ŝablono komenciĝas en /etc/openvpn/server kaj ŝargas %i.conf de tie. La klienta ŝablono komenciĝas en /etc/openvpn/client. Instanco nomata roaming povas ekzisti en ambaŭ lokoj samtempe, kiel servilo kaj kiel kliento, kun du senrilataj agordoj kaj nenia ligo inter ili krom la signoĉeno.

Demandu systemd anstataŭ la dosiersistemo, ĉar pakaĵaj kreintoj aldonas pliajn dosierojn, kiuj povas ŝanĝi la laboran dosierujon aŭ la argumentojn, kiujn la duuma dosiero ricevas.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

La unua komando listigas ĉiun instancigitan unuon, inkluzive de tiuj, kiuj fiaskis kaj restis ŝargitaj. La dua presas la unuan dosieron kune kun iu ajn anstataŭigo. La tria estas la plej rapida maniero vidi la du faktojn, kiuj decidas la demandon: la dosierujon, en kiu la procezo komenciĝas, kaj la agordan vojon, kiun oni donis al ĝi.

Decidu laŭ la direkto de pakaĵoj, ne laŭ la nomo de interfaco

Servila instanco posedas aŭskultan ingon kaj akceptas konektojn. Ĝia ĉifrita transporto estas loka enigo kaj loka eligo sur la Pi, dum la trafiko, kiun ĝi plusendas por uzantoj, sekvas la plusendan vojon kaj respondas al alia aro de reguloj. Klienta instanco ne posedas aŭskultanton en tiu senco: ĝi alvokas samtulon, do ĝia ĉifrita transporto estas loka eligo al la suba tavolo.

Tiu diferenco diras al vi, kien apartenas regulo. Regulo, kiu kongruas kun interfaco ene de plusenda ĉeno, nur permesas trafikon, kiun la enkursigado jam elektis; ĝi neniam elektas la vojon. Kiam la pakaĵoj de migranta uzanto eliras per la malĝusta vojo, la ĉeno por inspekti estas forward, ne output.

Rigardu la ingojn antaŭ ol teoriumi. Servilo ligita al udp/1194 montras aŭskultan ingon. La kliento montras asociiĝon al la adreso de la provizanto kaj nenion, kio aŭskultas.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

La defaŭlta vojo de unu instanco povas kapti la respondojn de la alia

redirect-gateway, kiun puŝas la supra kliento, instalas defaŭltan vojon, kiu konkurras kun ĉio alia sur la maŝino, inkluzive de la respondoj, kiujn la servilo sendas al migrantaj uzantoj. OpenVPN faras escepton por sia propra samtula adreso, por ke la tunelo restu atingebla, sed tiu escepto diras nenion pri telefono en hotela reto.

La simptomo estas kutime nesimetria. La manpremo finiĝas, la kliento raportas konekton, kaj la trafiko mortas post la unua responda pakaĵo. Fontbaza politika enkursigado, aŭ pakaĵa marko metita sur la servilan instancon per --mark, tenas la du fluojn aparte; neniu el ili estas kompleta aro de reguloj memstare, kaj ambaŭ bezonas validajn vojojn en la tabelo, kiun ili elektas.

Testu la lokan decidon anstataŭ la staton de la tunelo, ĉar la kerno elektas la fonton kaj la interfacon antaŭ ol OpenVPN vidas la pakaĵon.

ip route get 203.0.113.44
ip rule show

Restartigu unu rolon kaj pruvu, ke la alia postvivis

La ordo gravas, kiam ambaŭ roloj dependas de la sama suba tavolo. Restartigu la klienton unue, se la supra vojo devas ekzisti antaŭ ol la uzanttrafiko povas esti plusendita, kaj restartigu la servilon unue, kiam vi ŝanĝas nur ĝian aŭskultanton aŭ ĝian naĝejon. Ĉiukaze konfirmu ambaŭ unuojn poste, ĉar fiaskinta restartigo povas lasi la alian rolon funkcii kun eksdata stato.

Skribu la haltokondiĉon antaŭ la ŝanĝo: ĉu la perdo de la supra tunelo blokas migrantajn uzantojn, aŭ ĉu ĝi falas reen al la propra uplink de la Pi? Ankaŭ DNS kaj IPv6 bezonas klaran respondon, ĉar puŝita solvilo ofte postvivas la vojon, kiu igis ĝin utila.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Akceptu la ŝanĝon nur kiam tri aferoj validas samtempe: nova enveninta konekto finiĝas, plusendita aplikaĵo atingas sian celon tra la intencita eliro, kaj ambaŭ procezoj ankoraŭ raportas sian atendatan samtulon. Se unu el la tri fiaskas, vi ŝanĝis la malĝustan instancon aŭ la malĝustan vojon, kaj la sekva paŝo estas relegi la unuon anstataŭ restartigi ion alian.