VPN pe router sau redirecționare de port: care câștigă?

Routerul termină singur VPN-ul, iar o regulă veche de redirecționare trimite în continuare același port UDP către o mașină din LAN. Doar una dintre ele poate fi punctul final real, iar nucleul nu arbitrează între ele. Traducerea destinației rescrie pachetul înainte de a consulta serviciul local, așa că procesul VPN așteaptă trafic care a fost deja trimis altundeva. Sarcina este să decidem cine deține portul, apoi să facem regulile să coincidă.

Un port, doi proprietari revendicați

Un server VPN care rulează în router are nevoie de o permisiune de intrare care duce la propriul socket. O intrare NAT de destinație pentru același port duce cu totul altundeva: la o adresă LAN și la o decizie de redirecționare. Sunt puncte finale diferite, cu jurnale diferite și moduri de eșec diferite. Indiciul obișnuit este că o familie de adrese funcționează, iar cealaltă nu, pentru că intrarea rămasă a fost scrisă pentru o singură familie și nu a fost niciodată revizuită.

Notați pretenția înainte de editare: familie, adresă externă, transport, port și ținta tradusă.

Traducerea rulează înaintea verificării locale

NAT-ul de destinație schimbă ținta pachetului în etapa de prerouting, înainte ca nucleul să aleagă între livrarea locală și redirecționare. Odată ce ținta este un host din LAN, pachetul ia calea de redirecționare. Regulile de intrare pentru socketul propriu al routerului nu sunt niciodată consultate, de aceea jurnalul VPN rămâne gol în timp ce clientul așteaptă.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Acea ordine este întregul mecanism, iar interfețele echipamentelor o ascund în spatele casetelor de selectare fără a o schimba. Proprietarul destinației decide în continuare ce cale ia un pachet.

Dacă hostul din LAN este punctul final dorit, redirecționarea este corectă și routerul nu ar trebui să asculte și pe acel port.

Păstrați o mapare și eliminați-o pe cealaltă

Listați intrările NAT pentru acel port și familie și alegeți supraviețuitorul:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

O intrare TCP cu același număr este irelevantă pentru o defecțiune UDP, iar tratarea lor ca un singur obiect duce la ștergerea regulii greșite. Când socketul local ar trebui să câștige, proprietarul mapării conflictuale elimină sau rescrie exact acea intrare, iar permisiunea de intrare pentru portul propriu al routerului rămâne la locul ei. Redirecționările nelegate, calea de administrare și o copie a setului de reguli ar trebui toate să supraviețuiască schimbării.

Dacă VPN-ul locuiește pe un host separat, redirecționarea este obiectul corect. Un serviciu dintr-un container sau o mașină virtuală poate avea nevoie de un port publicat chiar și atunci când cutia se numește router, așa că urmăriți socketul și spațiul său de nume, nu eticheta de pe carcasă.

Confirmați proprietarul din exterior

Testați fiecare familie separat, pentru că o conexiune IPv6 care se termină pe router nu spune nimic despre o conexiune IPv4 pe care o regulă veche o redirecționează. Citiți jurnalul serviciului care primește pentru a vedea ce punct final a răspuns, și tratați mesajul de succes al clientului ca o dovadă slabă. Este nevoie de un flux nou pentru un test semnificativ. Trimiteți o sondă de pe un host extern cu nc -zvu 203.0.113.7 1194 și citiți jurnalul câștigătorului cu journalctl -u openvpn@server -n 20. Ascultătorul routerului înregistrează singur conexiunea, în timp ce un host din LAN o înregistrează în propriul serviciu.

Urmărirea conexiunilor menține fluxurile existente pe maparea lor originală, așa că o sesiune stabilită poate supraviețui regulii pe care tocmai ai corectat-o.

Odată ce punctul final dorit răspunde cu verificările sale obișnuite de identitate, testați o resursă privată din spatele tunelului. A ajunge la ascultătorul extern este doar primul salt; rutarea internă și autorizarea aplicației sunt rezultate separate.