Server sau client: ce unitate OpenVPN pe un Pi cu rol dublu

Pe un Pi rulează două procese OpenVPN care acceptă simultan utilizatori nomazi și ajung la un furnizor din amonte, și nu împart aproape nimic în afara hardware-ului. Unul ascultă tunelurile de intrare, celălalt apelează spre exterior. Fiecare își citește propriul director, și fiecare are propriul mod de eșec. Repornirea celui greșit este cea mai obișnuită cale prin care o corecție a clientului ajunge să zguduie ascultătorul.

Potriviți numele unității cu directorul pe care îl încarcă

Upstream 2.6 furnizează două unități șablon, [email protected] și [email protected]. Șablonul de server pornește în /etc/openvpn/server și încarcă %i.conf de acolo. Șablonul de client pornește în /etc/openvpn/client. O instanță numită roaming poate exista în ambele locuri simultan, ca server și ca client, cu două configurații fără legătură și nicio conexiune între ele în afara șirului.

Întrebați systemd în locul sistemului de fișiere, pentru că împachetătorii adaugă fișiere suplimentare care pot schimba directorul de lucru sau argumentele pe care le primește binarul.

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

Prima comandă listează fiecare unitate instanțiată, inclusiv cele care au eșuat și au rămas încărcate. A doua tipărește fișierul unității împreună cu orice suprascriere. A treia este cea mai rapidă cale de a vedea cele două fapte care decid întrebarea: directorul în care pornește procesul, și calea de configurare care i-a fost dată.

Decideți după direcția pachetelor, nu după numele interfeței

O instanță de server deține un socket de ascultare și acceptă conexiuni. Transportul ei cifrat este intrare locală și ieșire locală pe Pi, în timp ce traficul pe care îl redirecționează pentru utilizatori urmează calea de redirecționare și răspunde unui alt set de reguli. O instanță de client nu are ascultător în acest sens: apelează un partener, deci transportul ei cifrat este ieșire locală către stratul inferior.

Această diferență vă spune unde aparține o regulă. O regulă care corespunde unei interfețe dintr-un lanț de redirecționare permite doar traficul pe care rutarea l-a selectat deja; nu selectează niciodată ruta. Când pachetele unui utilizator nomad ies pe calea greșită, lanțul de inspectat este forward, nu output.

Uitați-vă la socketuri înainte de a teoretiza. Un server legat la udp/1194 arată un socket de ascultare. Clientul arată o asociere cu adresa furnizorului și nimic care să asculte.

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

Ruta implicită a unei instanțe poate captura răspunsurile celeilalte

Un redirect-gateway împins de clientul din amonte instalează o rută implicită ce concurează cu tot restul de pe mașină, inclusiv cu răspunsurile pe care serverul le trimite utilizatorilor nomazi. OpenVPN face o excepție pentru propria adresă de partener ca tunelul să rămână accesibil, dar acea excepție nu spune nimic despre un telefon aflat într-o rețea de hotel.

Simptomul este de obicei asimetric. Handshake-ul se completează, clientul raportează conectat, iar traficul moare după primul pachet de răspuns. Rutarea de politici bazată pe sursă, sau un marcaj de pachet pus pe instanța de server cu --mark, ține cele două fluxuri separate; niciuna nu este un set complet de reguli de la sine, și ambele au nevoie de rute valide în tabela pe care o aleg.

Testați decizia locală în locul stării tunelului, pentru că nucleul alege sursa și interfața înainte ca OpenVPN să vadă pachetul.

ip route get 203.0.113.44
ip rule show

Reporniți un rol și demonstrați că celălalt a supraviețuit

Ordinea contează când ambele roluri depind de același strat inferior. Reporniți clientul primul dacă ruta din amonte trebuie să existe înainte ca traficul utilizatorilor să poată fi redirecționat, și reporniți serverul primul când schimbați doar ascultătorul sau pool-ul acestuia. În orice caz, confirmați ambele unități după aceea, pentru că o repornire eșuată poate lăsa celălalt rol să ruleze cu stare învechită.

Scrieți condiția de oprire înainte de schimbare: pierderea tunelului din amonte blochează utilizatorii nomazi sau se retrage pe uplink-ul propriu al Pi? DNS și IPv6 au nevoie și ele de un răspuns explicit, pentru că un resolver împins supraviețuiește adesea rutei care l-a făcut util.

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

Acceptați schimbarea doar când trei lucruri sunt valabile simultan: o nouă conexiune de intrare se completează, o aplicație redirecționată ajunge la destinație prin ieșirea prevăzută, și ambele procese raportează încă partenerul așteptat. Dacă unul dintre cele trei eșuează, ați schimbat instanța greșită sau ruta greșită, iar pasul următor este să recitiți unitatea în loc să reporniți orice altceva.