Un server TAP sau mai multe? Clienți OpenVPN pe un pod

Mai mulți clienți TAP nu necesită un proces de server, un port UDP și un dispozitiv TAP pe gazdă pentru fiecare. Un server OpenVPN în modul Ethernet poate primi mulți clienți autentificați și îi poate atașa la un singur pod, iar aceasta este metoda documentată de extindere a unui segment de nivel 2. Proiectarea cu un singur proces este cea documentată de manual și este de obicei valoarea implicită corectă.

Adevărata întrebare este dacă acei clienți ar trebui să partajeze acel segment. Numărul de procese nu răspunde la ea, deoarece proprietățile de izolare provin din topologie, nu din câți demoni rulează. Restul acestei comparații este despre cele două topologii și despre ce face fiecare ușor.

Două arhitecturi, nu două setări

O implementare TUN rutată oferă fiecărui client o legătură punct-la-punct în domeniul de rutare al serverului. Difuzările se opresc la server, clienții nu pot vedea cadrele celuilalt, iar traficul între clienți, dacă există, trebuie rutat și filtrat în mod explicit.

O implementare TAP cu punte face clienții membri ai unui singur segment Ethernet. Ei văd difuzările, se pot rezolva reciproc cu ARP și depind de politica podului și a paravanului de incendiu în loc de rutare pentru a rămâne separați. Acest lucru este util atunci când clienții trebuie să apară ca și cum ar fi conectați la același comutator.

Prin urmare, comparația este despre ce trebuie să atingă clienții, nu despre performanță. Alegeți mai întâi nivelul, apoi decideți câte procese îl deservesc.

Ce face ajutorul server-bridge

Ajutorul server-bridge configurează modul Ethernet cu mai mulți clienți. Forma sa cu pool de adrese preia gateway-ul, masca de rețea și un interval dedicat în interiorul subrețelei cu punte, de exemplu un gateway la 192.168.50.1 cu un pool de la 192.168.50.160 la 192.168.50.199.

Rezervați acel interval în afara oricărei alte alocări DHCP sau statice. Ajutorul alocă adrese din el, dar nu se coordonează cu un alt alocator din același segment, iar două pool-uri suprapuse produc adrese duplicate care arată ca eșecuri aleatorii de conectivitate. Scrieți intervalul rezervat în planul de adrese al sitului, astfel încât următoarea persoană să nu îl reutilizeze. Un comentariu în configurația serverului este un substitut slab pentru acea înregistrare.

Există o formă cu proxy DHCP pentru implementările în care un server extern distribuie adrese. Are propriile condiții prealabile, iar amestecarea celor două forme produce exact conflictul despre care avertizează documentația. Alegeți un singur alocator pentru subrețeaua cu punte.

Izolarea nu vine din numărul de procese

Opt procese OpenVPN atașate la același pod fără restricții partajează în continuare un singur domeniu de difuzare. Clienții pot trimite ARP unul altuia prin pod, iar numărul de ascultători nu a schimbat nimic în acest sens.

Dacă cerința este ca grupurile de clienți să nu se vadă la nivelul 2, proiectarea are nevoie de poduri separate sau conexiuni VLAN, împreună cu regulile de acces aferente. Este o decizie de proiectare a rețelei și este aceeași indiferent dacă este implicat un proces de server sau opt. Filtrarea podului poate restricționa o parte din trafic, dar nu creează domenii de difuzare separate. Tratați-o ca un complement al segmentării, nu ca un substitut.

Dacă cerința este doar ca clienții să ajungă la anumite servicii IP, o proiectare TUN rutată este de obicei mai simplă decât puntea plus filtrare. Fiecare client primește propria legătură, iar politica trăiește în regulile de rutare și de paravan de incendiu, nu în interiorul podului.

Când mai multe procese sunt totuși corecte

Procesele separate pot fi justificate de nevoi operaționale: backend-uri de autentificare diferite, autorități de certificare diferite, cicluri de actualizare separate sau seturi de opțiuni incompatibile. Acestea sunt motive reale și sunt independente de numărul de clienți.

Dacă folosiți mai multe, dați fiecăruia propriul ascultător și proprietatea dispozitivului, și coordonați intervalele de adrese. Două servere care ambele cred că dețin același pool pe același pod vor distribui în cele din urmă aceeași adresă.

Apoi verificați proiectarea cu mai mulți clienți simultan. Verificați că adresele sunt unice, că traficul dorit între clienți funcționează și că o pereche care nu trebuie să comunice nu poate. Un ping reușit al unui singur client nu testează nimic din proiectarea multi-client.

Citiți podul și modul serverului de pe gazda în execuție înainte de a avea încredere în diagramă. Configurația care contează este cea pe care kernelul și demonul au încărcat-o efectiv, și este și cea pe care un recenzent o poate verifica.