Redirecționare de port către un peer WireGuard din spatele NAT: DNAT plus SNAT

Un browser cere https://203.0.113.10:8443, proxy-ul acceptă conexiunea, iar serviciul de pe peer-ul WireGuard nu răspunde niciodată. Regula DNAT își face treaba; partea care eșuează este răspunsul. Urmăriți pachetul prin ambele traduceri și regula lipsă devine evidentă. Remedierea este o instrucțiune NAT în plus în hook-ul corect, nu un tunel nou.

Urmăriți o cerere de la început la sfârșit

Cererea ajunge pe interfața publică a proxy-ului, cu adresa publică a clientului ca sursă și adresa proxy-ului ca destinație. În nat PREROUTING regula DNAT rescrie destinația către adresa tunelului peer-ului, 10.90.0.2. Apoi decizia de rutare trimite pachetul prin wg0, iar calea de redirecționare este completă.

Pe peer, pachetul poartă acum adresa publică de sursă originală, pentru că nimic nu a rescris-o. Serviciul acceptă conexiunea și trimite răspunsul la propria poartă implicită, care este routerul de acasă din fața peer-ului. Acel router nu are stare pentru un flux pe care nu l-a văzut niciodată și fie aruncă pachetul, fie îl traduce la propria adresă publică, ceea ce clientul nu va accepta.

Asimetria este toată problema: cererea trece prin proxy, iar răspunsul încearcă să meargă direct. Urmărirea conexiunilor a proxy-ului ajută doar dacă răspunsul se întoarce prin proxy, iar acesta nu poate reveni acolo cât timp adresa de sursă indică încă spre clientul original.

Adăugați traducerea de retur

Rescrieți sursa fluxului redirecționat către adresa tunelului proxy-ului înainte ca acesta să plece spre peer. Apoi serviciul răspunde la 10.90.0.1, proxy-ul îl primește, iar urmărirea conexiunilor inversează ambele traduceri înainte ca pachetul să se întoarcă la client.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Regula POSTROUTING este intenționat îngustă: se potrivește cu destinația tradusă și cu interfața tunelului, așa că nu rescrie trafic nelegat care iese din întâmplare prin wg0. O regulă masquerade largă ar ascunde și adresa clientului, dar ar face-o pentru fiecare flux și ar face tabela NAT mai greu de auditat.

Plasați regulile unde există tunelul

Regulile care fac referire la adresa sau la interfața tunelului trebuie să ruleze după ce wg-quick l-a configurat. Interfața este creată înainte de PreUp, dar adresele, MTU, DNS și rutele se aplică după, iar PostUp rulează când toate acestea sunt la locul lor. Puneți adăugările în PostUp și ștergerile în PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Ștergerile trebuie să corespundă adăugărilor token cu token, inclusiv potrivirile multiport și de interfață. O ștergere care diferă la o potrivire nu elimină nimic, iar reconectarea următoare adaugă o a doua copie a regulii. După câteva reconectări tabela conține duplicate greu de atribuit unei linii de configurare.

Verificați rezultatul cu iptables -t nat -S după o reconectare. Dacă aceeași regulă apare de două ori, linia PreDown nu se potrivește și curățarea eșuează în tăcere.

Redirecționare, filtrare și celălalt NAT

Activați permanent redirecționarea IPv4, apoi permiteți fluxul redirecționat în tabela de filtrare. DNAT are loc înainte de lanțul FORWARD, deci regula de filtrare se potrivește cu destinația tradusă, nu cu adresa publică. Dacă UFW administrează firewall-ul, exprimați permisiunea ca regulă de rută; o regulă simplă de gazdă nu acoperă traficul redirecționat.

Alte două straturi NAT pot rupe în continuare calea chiar dacă regulile proxy-ului sunt corecte. La o conexiune de acasă adresa publică aparține routerului, iar deschiderea portului în firewall-ul acestuia nu este același lucru cu crearea unei intrări de redirecționare de port care trimite acel port la proxy. Un port care pare deschis din exterior în timp ce nimic nu răspunde adesea nu are exact acea mapare.

Pe un VPS cu NAT, furnizorul mapează un port public la o adresă privată. Maparea trebuie să corespundă portului pe care îl anunțați, iar o nepotrivire arată identic cu un tunel rupt. Confirmați maparea furnizorului înainte de a modifica configurația WireGuard.

Verificați calea de retur și acceptați costul

Conectați-vă dintr-o rețea care nu este LAN-ul proxy-ului, apoi inspectați perechea de traduceri cât timp conexiunea este deschisă:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

Intrarea conntrack ar trebui să arate tuplul original, tuplul tradus și direcția răspunsului. Dacă răspunsul lipsește, peer-ul nu trimite prin tunel, ceea ce înseamnă de obicei că regula SNAT nu a fost aplicată sau că firewall-ul propriu al peer-ului a aruncat fluxul.

Reporniți o dată pentru a demonstra că PostUp reaplică regulile, apoi opriți tunelul și confirmați că PreDown le-a eliminat. Regulile moarte care supraviețuiesc unei deconectări sunt motivul pentru care o modificare ulterioară se comportă imprevizibil.

În final, acceptați cât costă SNAT. Serviciul vede fiecare cerere ca venind de la proxy, așa că jurnalele de acces, limitele de rată pe client și listele de adrese permise nu mai disting utilizatorii. Cazul hairpin are nevoie de propria traducere de sursă pentru clienții din LAN-ul proxy-ului. Dacă peer-ul are nevoie de adresele reale ale clienților, alternativa este o rută de retur către rețeaua clientului, ceea ce înseamnă mai multă muncă dar păstrează informația.