Strežnik ali odjemalec: katera enota OpenVPN na Pi z dvojno vlogo

Na Pi tečeta dva procesa OpenVPN, ki hkrati sprejemata gostujoče uporabnike in dosegata nadrejenega ponudnika, in razen strojne opreme si ne delita skoraj ničesar. Eden posluša dohodne tunele, drugi kliče navzven. Vsak bere svoj imenik in vsak ima svoj način odpovedi. Znova zagnati napačnega je najpogostejši način, da popravek odjemalca namesto tega prevrne poslušalca.

Uskladite ime enote z imenikom, ki ga nalaga

Upstream 2.6 prinaša dve predlogni enoti, [email protected] in [email protected]. Predloga strežnika se zažene v /etc/openvpn/server in od tam naloži %i.conf. Predloga odjemalca se zažene v /etc/openvpn/client. Instanca z imenom roaming lahko obstaja na obeh mestih hkrati, kot strežnik in kot odjemalec, z dvema nepovezanima konfiguracijama in brez kakršne koli povezave med njima razen niza.

Vprašajte systemd in ne datotečnega sistema, ker paketniki dodajajo dodatne datoteke, ki lahko spremenijo delovni imenik ali argumente, ki jih prejme binarna datoteka.

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

Prvi ukaz našteje vsako ustvarjeno enoto, vključno s tistimi, ki so spodletele in ostale naložene. Drugi izpiše datoteko enote skupaj z vsako prepisavo. Tretji je najhitrejši način, da vidite dve dejstvi, ki odločita vprašanje: imenik, v katerem se proces zažene, in pot do konfiguracije, ki mu je bila dana.

Odločite se po smeri paketov, ne po imenu vmesnika

Instanca strežnika ima poslušajočo vtičnico in sprejema povezave. Njen šifrirani prenos je lokalni vhod in lokalni izhod na Pi, medtem ko promet, ki ga posreduje za uporabnike, sledi poti posredovanja in se ravna po drugem naboru pravil. Instanca odjemalca v tem smislu nima poslušalca: kliče partnerja, zato je njen šifrirani prenos lokalni izhod proti spodnji plasti.

Ta razlika vam pove, kam sodi pravilo. Pravilo, ki se ujema z vmesnikom znotraj verige posredovanja, dovoli le promet, ki ga je usmerjanje že izbralo; nikoli ne izbere poti. Ko paketi gostujočega uporabnika odidejo po napačni poti, je veriga, ki jo je treba pregledati, forward in ne output.

Poglejte vtičnice, preden začnete teoretizirati. Strežnik, vezan na udp/1194, pokaže poslušajočo vtičnico. Odjemalec pokaže povezavo z naslovom ponudnika in ničesar, kar bi poslušalo.

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

Privzeta pot ene instance lahko ujame odgovore druge

redirect-gateway, ki ga potisne nadrejeni odjemalec, namesti privzeto pot, ki tekmuje z vsem drugim na stroju, vključno z odgovori, ki jih strežnik pošilja gostujočim uporabnikom. OpenVPN naredi izjemo za naslov svojega partnerja, da tunel ostane dosegljiv, a ta izjema ne pove ničesar o telefonu v hotelskem omrežju.

Simptom je običajno asimetričen. Roka se uspešno stisne, odjemalec poroča o povezavi, promet pa umre po prvem odgovornem paketu. Usmerjanje pravil, ki temelji na izvoru, ali oznaka paketa, nastavljena na instanci strežnika z --mark, drži oba toka ločena; nobeno samo po sebi ni popoln nabor pravil in oba potrebujeta veljavne poti v tabeli, ki jo izbereta.

Preizkusite lokalno odločitev in ne stanja tunela, ker jedro izbere izvor in vmesnik, preden OpenVPN vidi paket.

ip route get 203.0.113.44
ip rule show

Znova zaženite eno vlogo in dokažite, da je druga preživela

Vrstni red je pomemben, ko sta obe vlogi odvisni od iste spodnje plasti. Najprej znova zaženite odjemalca, če mora nadrejena pot obstajati, preden je mogoče posredovati uporabniški promet, in najprej znova zaženite strežnik, ko spreminjate le njegovega poslušalca ali njegov nabor. V vsakem primeru nato potrdite obe enoti, ker lahko neuspešen ponovni zagon pusti drugo vlogo delovati z zastarelim stanjem.

Pred spremembo zapišite pogoj za ustavitev: ali izguba nadrejenega tunela blokira gostujoče uporabnike ali se vrne na lastno nadrejeno povezavo Pi? Tudi DNS in IPv6 potrebujeta jasen odgovor, ker potisnjeni razreševalnik pogosto preživi pot, ki ga je naredil koristnega.

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

Spremembo sprejmite le, ko hkrati veljajo tri stvari: nova dohodna povezava se dokonča, posredovana aplikacija doseže svoj cilj skozi predvideni izhod in oba procesa še vedno poročata o svojem pričakovanem partnerju. Če ena od treh spodleti, ste spremenili napačno instanco ali napačno pot, naslednji korak pa je, da enoto znova preberete in ne zaženete česa drugega.