Se pot atinge clienții de pe două servere OpenVPN unii pe alții?

Ridicarea unui al doilea OpenVPN server îți oferă un al doilea loc în care clienții se pot conecta, și nimic mai mult. Nu pune acei clienți în rețeaua primului server, iar opțiunea numită client-to-client schimbă doar forwardingul din interiorul unui singur proces de server. Cele două pool-uri devin o singură rețea atunci când rutați între ele, intenționat, cu un proprietar pentru fiecare direcție. Tot ce urmează presupune modul TUN în spațiul utilizatorului cu acel forwarding intern oprit, astfel încât kernelul să ia decizia.

Mitul: o listă de conturi, o rețea

Autentificarea și accesibilitatea sunt confundate pentru că ambele stau în configurația serverului. Un utilizator care se poate autentifica pe oricare dintre cele două gateway-uri arată, din exterior, ca un utilizator pe un singur sistem cu două uși. În interior, fiecare server distribuie adrese din propriul pool și instalează rute doar pentru clienții pe care îi termină. Așa că un client de pe gateway-ul A care trimite un pachet către un client de pe gateway-ul B cere o destinație de care propriul server nu a auzit niciodată. Pachetul merge pe ruta implicită a lui A, părăsește tunelul și ajunge la un firewall care nu a fost niciodată rugat să îl permită.

Adăugarea unui al doilea server nu adaugă deci redundanță, descoperire sau un domeniu de broadcast partajat. Adaugă o rețea rutată care are nevoie de un plan, iar planul începe cu adresarea.

Dați fiecărui gateway propriul pool și adresă de tranzit

Două intervale care nu se pot suprapune cu nimic altceva, plus o mică legătură de tranzit între hosturi, este întregul plan de adresare. Țineți tranzitul pe un segment privat pe care îl controlați și notați numerele înainte ca vreun server să dea un lease.

Rezistați tentației de a da ambelor servere același pool ca să rămână profilele identice. O rută de kernel nu poate spune care dintre două hosturi deține acum o adresă arbitrară într-un interval partajat, așa că tabela de rutare ar indica un gateway și clientul ar putea fi conectat la celălalt. Numele interfețelor sunt convenții locale, nu stare partajată. Ambele hosturi de aici numesc dispozitivul de tunel tun0 și legătura de tranzit transit0, ceea ce este în regulă pentru că niciun pachet nu poartă aceste nume.

Instalați ruta pe ambele părți

Fiecare gateway are nevoie de o rută către pool-ul celuilalt prin adresa de tranzit, iar forwardingul trebuie pornit pentru ca vreunul să acționeze ca hop. Confirmați mai întâi tabela curentă, apoi adăugați intrarea și faceți-o persistentă prin managerul de rețea al hostului, nu printr-un hook de reconectare.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Oglindiți asta pe celălalt host cu pool-urile inversate. A adăuga în mod repetat aceeași rută dintr-un script fără legătură este felul în care un host ajunge cu mai multe copii și cu o schimbare misterioasă data viitoare când cineva citește tabela. Dacă legătura de tranzit este ea însăși un tunel, ruta indică topologia acelui tunel și hopul trebuie să supraviețuiască reconectării. O adresă de tranzit care dispare timp de treizeci de secunde ia cu ea calea dintre pool-uri, ceea ce este o proprietate de design care merită afirmată în loc să fie descoperită.

Împingeți ruta clientului fără a preface proprietatea

Clienții au nevoie de o rută către pool-ul îndepărtat, altfel propriul sistem de operare trimite pachetul la gateway-ul implicit și tunelul nu îl vede niciodată. Configurația serverului este locul natural pentru a o livra.

push "route 10.64.20.0 255.255.255.0"

Puneți linia oglindă în configurația celuilalt server, apoi reconectați un client de test și citiți-i tabela. Un client care ignoră rutele împinse are nevoie de propria configurație aprobată, iar o rută care nu sosește niciodată nu este control de acces. Nu dați unui client un iroute pentru întregul pool al celuilalt gateway. Directiva există pentru o subrețea aflată în spatele unui client conectat, iar folosirea ei pentru a acoperi o rută lipsă între gateway-uri produce un server care crede că deține adrese pe care nu le poate atinge.

Dovediți o cerere și refuzați alta

Alegeți o operație reală, de exemplu HTTPS de la un client la 10.64.10.21 către un serviciu la 10.64.20.37, și permiteți exact aceasta pe ambele hosturi. Fiecare firewall admite cererea pe latura de intrare și răspunsul urmărit pe latura de retur; politica serviciului destinație trebuie încă să o accepte.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Cu rute reciproce, NAT-ul de sursă este inutil și aici activ dăunător: traducerea sursei ascunde ce client a făcut cererea și anulează politica bazată pe sursă pe latura destinației. Verificați că o regulă masquerade existentă pentru ieșirea în internet nu prinde și această cale. Apoi testați refuzul. Un serviciu care trebuie să rămână local pool-ului B trebuie să rămână inaccesibil din pool-ul A, iar perechile de clienți pe același gateway trebuie și ele testate, deoarece politica de forwarding pe care tocmai ați schimbat-o li se aplică și lor.

Încă o corecție a modelului mental: legătura de tranzit transportă pachete interne decriptate, deci este o graniță de încredere, nu o garanție privată. Dacă traversează o rețea pe care nu o controlați, protejați acel hop cu un tunel criptat aprobat și rutați prin topologia lui reală. TLS cap la cap autentifică în continuare aplicația pe cont propriu, motiv pentru care serviciul intern ar trebui să-l folosească în continuare.