Un Pi, două instanțe OpenVPN: ce citește fiecare unitate

Numără procesele OpenVPN înainte de a atinge un profil. Un Pi care acceptă utilizatori în roaming și, în același timp, apelează un serviciu din amonte rulează doi demoni, iar fiecare citește un fișier de configurare ales de numele instanței pe care l-ai tastat. Șabloanele pachetului oferă apoi fiecărui demon propriul director de lucru, propriul fișier de stare la rulare și propriul dispozitiv de tunel. Dacă greșești această separare, petreci o seară modificând o setare corectă într-un fișier pe care procesul aflat în execuție nu îl deschide niciodată.

Fiecare nume de instanță își alege propriul fișier

În fișierele de unitate livrate cu OpenVPN 2.6, argumentele de pornire conțin un substituent de instanță completat cu textul de după semnul @. Șablonul de server rulează din directorul de configurare al serverului și își rezolvă argumentul față de %i.conf de acolo, iar șablonul de client face același lucru din directorul clientului. Așadar [email protected] citește admits.conf în directorul serverului, iar [email protected] citește uplink.conf în directorul clientului, și niciunul dintre aceste nume nu are vreun sens în celălalt director.

Confirmă maparea pe mașină în loc să presupui că pachetul a păstrat valorile implicite din amonte. Un drop-in al distribuției poate înlocui complet directorul de lucru sau argumentul de configurare.

systemctl cat [email protected]
systemctl cat [email protected]

Citește linia WorkingDirectory și argumentul de configurare din acea ieșire, pentru că doar unitatea activată decide ce fișier se încarcă. Un drop-in care adaugă --config la ExecStart câștigă în fața șablonului chiar și când calea șablonului pare corectă. Cere căile fragmentelor și ale drop-in-urilor când vrei să știi dacă există o suprascriere locală. Dacă ambele roluri se rezolvă la un singur fișier, ai un singur proces care încearcă să fie și server, și client, iar opțiunea de mai târziu din acel fișier câștigă în tăcere.

Transportul local și încărcătura redirecționată ajung în hook-uri diferite

Conexiunea criptată a serverului cu fiecare utilizator în roaming este generată chiar pe Pi, așa că răspunsurile sale exterioare ies prin hook-ul de ieșire local. Conexiunea clientului cu partenerul său din amonte este și ea o ieșire generată local, chiar dacă ajunge la o rețea îndepărtată. Încărcătura redirecționată este a treia categorie, iar nucleul o potrivește abia după ce a ales deja un dispozitiv de ieșire pentru pachet.

O regulă care potrivește o interfață de ieșire într-un lanț forward poate permite sau elimina un pachet pe care rutarea l-a atribuit deja acelei interfețe, dar nu alege niciodată interfața. Când o gazdă încheie un tunel și începe altul, politica ce trimite încărcătura utilizatorilor în tunelul din amonte și politica ce protejează răspunsurile criptate ale Pi-ului sunt două decizii separate. Ele ajung din întâmplare pe aceeași placă de rețea fizică, de aceea sunt confundate.

Această distincție explică o defecțiune parțială frecventă. Utilizatorii se conectează, handshake-ul se încheie, iar traficul lor tot pleacă pe calea greșită, pentru că handshake-ul era local, iar încărcătura era forward și doar una dintre cele două a fost vreodată testată.

O rută importată poate înghiți răspunsurile către utilizatorii tăi

Setarea de securitate a profilului de client decide ce poate împinge partea din amonte în tabela de rutare a Pi-ului, iar o redirecționare largă este opțiunea care transformă o gazdă cu rol dublu funcțională într-una stricată. Dacă ruta împinsă acoperă adresele publice ale utilizatorilor în roaming, răspunsurile pe care serverul le generează către ei pot urma noua rută în tunelul din amonte în loc să iasă prin stratul de bază. Oamenii verifică des că tunelul către furnizor încă funcționează și se opresc acolo, pentru că acel trafic este transportul propriu al tunelului și continuă să curgă în timp ce tot restul se comportă greșit.

Politica bazată pe sursă sau pe mark este modul în care cele două fluxuri rămân separate. Opțiunea mark din Linux a OpenVPN marchează pachetele criptate ale demonului cu un mark de firewall, pe care o regulă de rutare îl poate trimite apoi într-o tabelă dedicată. Adresele sursă funcționează la fel de bine când răspunsurile exterioare ale serverului ies mereu dintr-o singură adresă de bază. Ambele abordări au nevoie de rute valide în tabela pe care o selectează și de o excepție pentru endpoint-ul furnizorului, altfel tunelul însuși nu mai urcă.

Întreabă nucleul ce cale ar lua de fapt un răspuns înainte de a scrie orice regulă. Adresele de mai jos sunt substituenți pentru o adresă de bază a Pi-ului și adresa publică a unui utilizator în roaming.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Verifică separarea, apoi oprește un rol pe rând

Testează trei fluxuri separat, pentru că un handshake funcțional nu dovedește nimic despre celelalte două. Acceptă o conexiune nouă de intrare, trimite o aplicație permisă prin ieșirea din amonte și confirmă că ambele procese ajung în continuare la partenerii lor.

Apoi oprește rolul de client și observă ce păstrează rolul de server. Este cea mai ieftină cale de a găsi o regulă de rută sau de mark care era destinată unei instanțe și a fost aplicată la ambele.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

Ce vrei să vezi este ascultătorul încă legat, dispozitivul de tunel încă prezent și jurnalul lipsit de erori noi în timp ce rolul de client este oprit. Dacă oprirea clientului taie și răspunsurile serverului către utilizatorii existenți, cele două roluri împart ceva care ar fi trebuit limitat la unul dintre ele. Notează ce instanță, ce fișier de configurare și ce proprietar de flux a atins fiecare modificare, pentru că altfel următoarea persoană care depanează această gazdă va repeta aceeași descoperire de la zero.