Regulile care redirecționează toate porturile pot înghiți listenerul WireGuard

Un gateway public rulează deja WireGuard pe UDP 51820, SSH pe 22 și o aplicație care trebuie să fie accesibilă din internet. Regula tentantă redirecționează fiecare port către peer și declară treaba terminată. Pe un gateway WireGuard, acea regulă poate captura transportul tunelului însuși și vă poate închide în afara mașinii care îl termină. Publicarea este o decizie de rutare cu o excepție pentru planul de control, nu o singură linie DNAT.

Intrare publică sau intrare prin tunel: alegeți una

Publicarea unui serviciu creează un nou punct de intrare în internet. Nu este același lucru cu a acorda unui peer calitatea de membru VPN, pentru că vizitatorul nu intră niciodată în tunel, iar gateway-ul devine fața publică a backend-ului. Această distincție decide publicul regulii și certificatul ei.

Interfețele administrative rareori își au locul acolo. O pagină de administrare accesată de clienți VPN autorizați ține suprafața de atac în interiorul tunelului și evită expunerea unui formular de autentificare la scanări arbitrare. Punctele finale publice ale aplicației au nevoie în continuare de propriul certificat TLS, de autentificare și de limitarea ratei; saltul WireGuard criptat nu protejează porțiunea vizitatorului până la gateway.

Dacă serviciul chiar trebuie să fie public, notați numele de gazdă, certificatul care îl acoperă și intervalele de vizitatori care ar trebui să ajungă la el. Aceste trei fapte decid mai târziu forma regulii și politica de filtrare. Orice în afara lor este extindere a domeniului pe un listener public.

Un port înăuntru, un backend în afară

Folosiți un singur port public și un singur serviciu backend. În acest exemplu, eth0 poartă adresa publică 198.51.100.20, adresa de tunel a gateway-ului este 10.200.0.1, iar peer-ul rulează aplicația pe 10.200.0.7. Portul public TCP 9443 este mapat pe TCP 8443 al peer-ului:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

Regula SNAT se potrivește cu backend-ul tradus și cu destinația publică originală, așa că o altă conexiune către același serviciu backend rămâne în afara acestei mapări. Ascunde de asemenea adresa vizitatorului față de peer, iar acesta este compromisul care face dintr-o întoarcere rutată cu păstrarea sursei un proiect separat. Referința pentru extensiile iptables documentează ambele ținte și opțiunile lor de potrivire.

Redirecționarea trebuie totuși activată, iar lanțul de filtrare are nevoie de o permisiune pentru destinația și portul traduse plus răspunsurile stabilite. Lanțul FORWARD vede destinația tradusă după DNAT, așa că o regulă scrisă pe adresa publică nu se potrivește cu pachetul redirecționat. Scrieți permisiunea pe tuplul backend-ului, nu pe cel public.

Peer-ul trebuie să accepte conexiunea serviciului de la adresa de tunel a gateway-ului și să trimită răspunsul înapoi prin tunel. AllowedIPs al său trebuie să autorizeze sursa pe care o primește efectiv, care sub traducerea sursei este adresa de tunel a gateway-ului, iar o intrare largă 0.0.0.0/0 pe fiecare peer nu este necesară pentru acest proiect. Ceea ce aruncă traficul de întoarcere este un peer a cărui listă omite acea adresă, sau un proiect cu păstrarea sursei care redirecționează în schimb adresa vizitatorului, așa că verificați sursa pe care peer-ul o vede cu adevărat, nu pe cea din regula dumneavoastră.

Țineți listenerele gateway-ului în afara regulii

Înlocuiți potrivirea pe port cu o regulă care acoperă orice destinație TCP și UDP, iar socketul WireGuard al gateway-ului cade în interiorul ei. Traducerea destinației are loc înainte ca mașina să decidă că un pachet este local, așa că UDP 51820 poate ajunge la peer în loc de procesul care ține fiecare conexiune a peer-ilor. Regula se încarcă fără eroare și tunelul moare, o defecțiune greu de citit din partea peer-ului.

SSH, agenții de monitorizare și orice alt serviciu găzduit pe gateway au aceeași expunere. O regulă care redirecționează tot nu distinge planul de control de aplicația publicată, iar prima repornire după schimbare este momentul în care blocarea devine evidentă. Regula care prinde tot nu avertizează despre serviciul pe care îl preia în tăcere. Aflați când următoarea conexiune eșuează.

Dacă redirecționarea largă este într-adevăr necesară, rezervați porturile de control înaintea regulii care prinde tot sau folosiți o adresă publică separată pentru publicare. A doua opțiune este mai curată pentru că adresa de control își păstrează propria politică, dar furnizorul trebuie să livreze acea adresă; adăugarea unei înregistrări DNS nu alocă una.

Redirecționarea largă TCP și UDP nu înseamnă nici toate protocoalele. ICMP, IPv6, feedbackul path-MTU și transportul VPN exterior au nevoie de propria politică, iar o regulă care acoperă TCP și UDP lasă acele cazuri lanțului implicit.

Alegeți modelul înainte de a scrie regulile

Patru forme acoperă majoritatea publicărilor dintr-un gateway, iar alegerea depinde de câte servicii rulați și de cât risc în planul de control tolerați. Tabelul de mai jos le ordonează de la cea mai îngustă la cea mai largă.

Începeți cu modelul îngust chiar dacă vă așteptați la mai multe servicii mai târziu. Este cel mai ușor de auditat, iar convertirea unui set de reguli înguste într-o regulă care prinde tot, deja revizuită, este mai simplă decât să descoperiți ce listener a capturat o regulă largă. Indiferent de model, țineți regulile la proprietarul firewall-ului. Aplicarea liniilor iptables lângă o configurație UFW sau nftables care gestionează aceleași lanțuri produce o politică ce se schimbă în funcție de ordinea de pornire.

Dovediți atât publicarea, cât și calea de control

Testați de la un client extern autorizat folosind numele de gazdă aprobat și un certificat valid pentru el. Confirmați ce backend a răspuns, apoi verificați că porturile publice nelegate rămân refuzate. O verificare a certificatului dezactivată nu este un test HTTPS trecut, iar o conexiune care ajunge la backend-ul greșit este mai rea decât una eșuată.

După aceea verificați gateway-ul însuși: conectați un peer WireGuard, deschideți o sesiune SSH și confirmați că monitorizarea încă raportează. Serviciul publicat poate funcționa în timp ce planul de control este stricat, așa că ambele verificări aparțin aceleiași ferestre de schimbare. Reporniți o dată pentru a dovedi că regulile sunt reaplicate în ordinea așteptată, apoi retrageți publicarea și confirmați că retragerea corespunde într-adevăr adăugării. Un set mare de adăugiri la pornire cu o curățare incompletă este felul în care un test temporar devine o deschidere permanentă.