Server või klient: milline OpenVPN üksus kahekordse rolliga Pi-l

Ühel Pi-l töötab kaks OpenVPN protsessi, mis ühtaegu võtavad vastu rändavaid kasutajaid ja jõuavad ülemise teenusepakkujani, ning peale riistvara ei jaga nad peaaegu midagi. Üks kuulab sissetulevaid tunneleid, teine helistab välja. Kumbki loeb oma kataloogi ja kummallagi on oma tõrkerežiim. Vale üksuse taaskäivitamine on kõige tavalisem viis, kuidas kliendi parandus hoopis kuulaja paigast lööb.

Sovitage üksuse nimi kataloogiga, mille see laadib

Upstream 2.6 pakub kahte mallüksust, [email protected] ja [email protected]. Serveri mall algab kataloogis /etc/openvpn/server ja laadib sealt %i.conf. Kliendi mall algab kataloogis /etc/openvpn/client. Nimega roaming eksemplar võib eksisteerida mõlemas kohas korraga, nii serveri kui kliendina, kahe sõltumatu konfiguratsiooniga ja ilma muu seoseta nende vahel kui string.

Küsige systemd-lt, mitte failisüsteemilt, sest pakendajad lisavad täiendavaid faile, mis võivad muuta töökataloogi või argumente, mille binaarfail saab.

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

Esimene käsk loetleb iga loodud üksuse, ka need, mis ebaõnnestusid ja jäid laadituks. Teine prindib üksusefaili koos mis tahes alistusega. Kolmas on kiireim viis näha kahte fakti, mis küsimuse otsustavad: kataloog, milles protsess algab, ja konfiguratsioonitee, mis talle anti.

Otsustage paketi suuna, mitte liidese nime järgi

Serveri eksemplaril on kuulav socket ja see võtab vastu ühendusi. Selle krüpteeritud transport on Pi-l kohalik sisend ja kohalik väljund, samas kui kasutajate jaoks edastatav liiklus järgib edastusteed ja vastab teisele reeglistikule. Kliendi eksemplaril ei ole selles mõttes kuulajat: see helistab partnerile, seega on selle krüpteeritud transport kohalik väljund alumise kihi poole.

See erinevus ütleb teile, kuhu reegel kuulub. Edastusahela sees liidesega sobiv reegel lubab ainult liiklust, mille marsruutimine on juba valinud; see ei vali kunagi marsruuti. Kui rändava kasutaja paketid väljuvad vale tee kaudu, on kontrollitav ahel forward, mitte output.

Vaadake socket'e enne teoretiseerimist. udp/1194 külge seotud server näitab kuulavat socket'it. Klient näitab seost teenusepakkuja aadressiga ja mitte midagi kuulavat.

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

Ühe eksemplari vaikemarsruut võib teise vastused kinni püüda

Ülemise kliendi lükatud redirect-gateway paigaldab vaikemarsruudi, mis konkureerib kõige muuga masinas, sealhulgas vastustega, mille server rändavatele kasutajatele saadab. OpenVPN teeb erandi omaenda partneri aadressile, et tunnel jääks kättesaadavaks, kuid see erand ei ütle midagi hotellivõrgus istuva telefoni kohta.

Sümptom on tavaliselt asümmeetriline. Käepigistus lõpeb, klient teatab ühendusest ja liiklus sureb pärast esimest vastusepaketti. Allikapõhine poliitikamarsruutimine või serveri eksemplarile --mark abil pandud paketimärk hoiab kaks voogu lahus; kumbki ei ole iseenesest täielik reeglistik ja mõlemad vajavad kehtivaid marsruute tabelis, mille nad valivad.

Testige kohalikku otsust, mitte tunneli olekut, sest kernel valib allika ja liidese enne, kui OpenVPN paketti näeb.

ip route get 203.0.113.44
ip rule show

Taaskäivitage üks roll ja tõestage, et teine jäi ellu

Järjekord on oluline, kui mõlemad rollid sõltuvad samast alumisest kihist. Taaskäivitage klient esimesena, kui ülemine marsruut peab olemas olema enne, kui kasutajaliiklust saab edastada, ja taaskäivitage server esimesena, kui muudate ainult selle kuulajat või selle pooli. Igal juhul kinnitage pärast mõlemad üksused, sest ebaõnnestunud taaskäivitus võib jätta teise rolli vananenud olekuga tööle.

Kirjutage peatumistingimus enne muudatust üles: kas ülemise tunneli kaotamine blokeerib rändavad kasutajad või langeb tagasi Pi enda üleslingile? Ka DNS ja IPv6 vajavad selget vastust, sest lükatud resolver elab sageli kauem kui marsruut, mis selle kasulikuks tegi.

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

Nõustuge muudatusega ainult siis, kui kolm asja kehtivad korraga: uus sissetulev ühendus lõpeb, edastatud rakendus jõuab oma sihtkohta kavandatud väljapääsu kaudu ja mõlemad protsessid teatavad endiselt oma oodatud partnerit. Kui üks kolmest ebaõnnestub, muutsite vale eksemplari või vale marsruuti ja järgmine samm on üksus uuesti läbi lugeda, mitte midagi muud taaskäivitada.