O singură placă de rețea sau două? Stabilirea dispunerii interfețelor unui server VPN

Un singur adaptor fizic este suficient pentru multe servere VPN, și nici nu este o soluție universală. Conexiunea criptată ajunge pe acel adaptor, procesul VPN o decriptează, iar apoi traficul intern iese printr-o interfață virtuală înainte de a ajunge la un serviciu local sau la un LAN rutat. Dacă funcționează depinde de trei condiții: unde se află destinația, dacă LAN-ul are o cale de întoarcere către pool-ul de clienți și dacă o singură legătură fizică partajată vă oferă izolarea pe care o afirmați. Răspundeți la acestea trei și numărul de adaptoare decurge de la sine.

Cele trei condiții care decid

Prima condiție este destinația. Un serviciu de pe gazda VPN însăși este accesibil doar prin interfața tunelului, în timp ce o gazdă din LAN necesită forwarding și o cale de întoarcere. A doua condiție este acea cale de întoarcere, fiindcă dispozitivul din LAN trebuie să știe cum să ajungă la pool-ul de clienți, fie printr-o rută, fie prin traducere pe server.

A treia condiție este separarea. Un adaptor înseamnă că fiecare pachet, criptat sau nu, împarte o legătură și de obicei o singură catenă de politici, așa că o afirmație de izolare care depinde de hardware separat nu este satisfăcută de o singură interfață. Este un fapt despre cale, nu despre modul în care este configurat sistemul de operare. Puteți filtra în continuare traficul tunelului, dar nu puteți revendica o graniță pe care nu o aveți.

Niciuna dintre ele nu privește numărul de porturi de pe carcasă. Privesc rutarea, proprietatea adreselor și cât de mult depinde proiectul de separarea fizică.

Două adaptoare rămân o alegere legitimă când zone fizice, uplink-uri separate, debit sau o cale de recuperare în afara benzii o justifică. Sunt cerințe concrete și merită enunțate înainte ca cineva să comande hardware.

Când serviciul rulează pe gazda VPN

Cazul cel mai simplu nu are nevoie de niciun forwarding. Daemonul primește pachetele clientului pe interfața tunelului și le predă unui socket local, iar răspunsul se întoarce pe aceeași interfață. Pentru gazdă, adresa din pool-ul de clienți este o adresă locală reală.

Totuși două lucruri trebuie să fie corecte: serviciul trebuie să asculte pe o adresă accesibilă din tunel, iar firewall-ul gazdei trebuie să accepte traficul care sosește pe interfața tunelului. Ambele se văd în comenzile de mai jos.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Legarea unui serviciu doar la adresa publică, sau filtrarea din greșeală a interfeței tunelului, produce o conexiune care ajunge la gazdă și apoi moare. Pare o defecțiune VPN și este de obicei o decizie despre socket sau firewall.

Când destinația se află în LAN

Aici un proiect cu un singur adaptor își câștigă reputația de complicat. Serverul trebuie să trimită mai departe pachetele clientului către LAN, iar dispozitivul din LAN trebuie să trimită răspunsurile înapoi în pool-ul de clienți. Fie duceți acel pool ca rută în LAN, fie traduceți adresa sursă pe server, astfel încât răspunsurile să revină la serverul însuși.

Ambele răspunsuri sunt legitime și eșuează diferit. O rută de întoarcere păstrează adresa originală a clientului vizibilă pentru destinație, ceea ce este bun pentru jurnale și rău pentru regulile de firewall care presupun adrese de LAN. Traducerea păstrează LAN-ul simplu și ascunde identitatea clientului de destinație.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

O cale asimetrică este simptomul clasic: cererea clientului ajunge, răspunsul iese pe alt router, iar conexiunea expiră fără eroare la ambele capete. Capturați pe ambele părți înainte de a trage vreo concluzie despre tunel.

De ce un alias nu creează o a doua zonă

Adăugarea unei a doua adrese pe același adaptor, sau crearea unei interfețe dummy care imită un al doilea port, schimbă foarte puțin. Pachetele ies în continuare prin aceeași legătură fizică, prin același port de switch și de obicei prin aceeași catenă de firewall, așa că între ele nu apare o graniță nouă. Este comoditate de configurare, nu segmentare. Tratarea ei ca graniță de zonă este felul în care o afirmație de izolare supraviețuiește doar pe hârtie.

O zonă separată necesită o separare reală pe cale, iar aceasta este cerința pe care un al doilea adaptor o îndeplinește. Dacă o regulă depinde de faptul că traficul către VPN nu împarte niciodată un domeniu de broadcast cu traficul către LAN, un singur cablu nu poate oferi această proprietate, oricum ar fi adresată gazda.

Acolo unde un produs documentează o topologie cu mai multe interfețe pentru un anumit mod, urmați documentația acelui produs în loc să inventați o soluție ocolitoare. Producătorii schimbă și topologiile acceptate între versiuni, ceea ce este încă un motiv să citiți ghidul actual și nu o captură de ecran a unui vechi asistent.

Verificați dispunerea față de traficul pe care îl permiteți

Enumerați clasele de trafic pe care serverul trebuie să le transporte: client către gazdă, client către LAN, gazdă către LAN și conexiunea externă criptată. Fiecare clasă are o sursă, o destinație și o interfață, iar dispunerea trebuie să le satisfacă pe toate patru simultan. Un proiect care rezolvă trei dintre ele este de obicei cel care generează tichete.

Apoi confirmați interfețele reale și captura reală, nu diagrama din documentul de proiectare. Comenzile de mai jos afișează ambele vederi.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Dacă captura exterioară arată traficul criptat și captura interioară arată traficul decriptat pe interfața tunelului, în timp ce adaptorul fizic le transportă pe amândouă, o singură placă de rețea își face treaba. Dacă captura interioară este goală, problema este în tunel sau în regulile de forwarding, nu în numărul de adaptoare. Stabiliți topologia din acele două capturi și din tabela de rutare, iar următoarea modificare va avea cu ce să fie comparată.