Port forwarding na ’n WireGuard-peer agter NAT: DNAT plus SNAT

’n Blaaier versoek https://203.0.113.10:8443, die proxy aanvaar die verbinding, en die diens op die WireGuard-peer antwoord nooit. Die DNAT-reël doen sy werk; dit is die antwoord wat misluk. Volg die pakket deur albei vertalings en die ontbrekende reël word duidelik. Die oplossing is een extra NAT-stelling in die regte hook, nie ’n nuwe tonnel nie.

Volg een versoek van begin tot einde

Die versoek kom op die proxy se openbare koppelvlak aan met die kliënt se openbare adres as bron en die proxy-adres as bestemming. In nat PREROUTING herskryf die DNAT-reël die bestemming na die peer se tonneladres, 10.90.0.2. Die roetebesluit stuur die pakket dan deur wg0 uit, en die aanstuurpad is voltooi.

Op die peer dra die pakket nou die oorspronklike openbare bronadres, want niks het dit herskryf nie. Die diens aanvaar die verbinding en stuur sy antwoord na sy eie verstek-gateway, wat die huisroeteerder voor die peer is. Daardie roeteerder het geen toestand vir ’n stroom wat hy nooit gesien het nie en laat die pakket óf val óf vertaal dit na sy eie openbare adres, wat die kliënt nie sal aanvaar nie.

Die asimmetrie is die hele probleem: die versoek gaan deur die proxy, en die antwoord probeer reguit gaan. Die proxy se verbindingnasporing help net as die antwoord deur die proxy terugkom, en dit kan nie daarheen terugkeer terwyl die bronadres nog na die oorspronklike kliënt wys nie.

Voeg die terugvertaling by

Herskryf die bron van die aangestuurde stroom na die tonneladres van die proxy voordat dit na die peer vertrek. Die diens antwoord dan na 10.90.0.1, die proxy ontvang dit, en verbindingnasporing keer albei vertalings om voordat die pakket na die kliënt teruggaan.

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

Die POSTROUTING-reël is doelbewus smal: dit pas by die vertaalde bestemming en die tonnelkoppelvlak, so dit herskryf nie onverwante verkeer wat toevallig deur wg0 vertrek nie. ’n Breë masquerade-reël sou ook die kliëntadres wegsteek, maar dit sou dit vir elke stroom doen en die NAT-tabel moeiliker maak om te kontroleer.

Plaas die reëls waar die tonnel bestaan

Reëls wat na die tonneladres of -koppelvlak verwys, moet loop nadat wg-quick dit opgestel het. Die koppelvlak word voor PreUp geskep, maar adresse, MTU, DNS en roetes word daarna toegepas, en PostUp loop sodra dit alles in plek is. Sit die byvoegings in PostUp en die verwyderings in 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

Die verwyderings moet die byvoegings token vir token pas, insluitend die multiport- en koppelvlak-passings. ’n Verwydering wat met een passing verskil, verwyder niks, en die volgende herverbinding voeg ’n tweede kopie van die reël by. Na ’n paar herverbindings bevat die tabel duplikate wat moeilik aan ’n konfigurasiereël toe te skryf is.

Kontroleer die resultaat met iptables -t nat -S ná ’n herverbinding. As dieselfde reël twee keer verskyn, pas die PreDown-reël nie en misluk die opruiming stilweg.

Aansturing, filtering en die ander NAT

Aktiveer IPv4-aansturing permanent en laat dan die aangestuurde stroom in die filtertabel toe. DNAT gebeur voor die FORWARD-ketting, so die filterreël pas by die vertaalde bestemming eerder as die openbare adres. As UFW die firewall bestuur, druk die toelating as ’n roetereël uit; ’n gewone host-reël dek nie aangestuurde verkeer nie.

Twee ander NAT-lae kan steeds die pad breek selfs wanneer die proxy-reëls korrek is. Op ’n huisverbinding behoort die openbare adres aan die roeteerder, en om die poort in sy firewall oop te maak is nie dieselfde as om ’n poortaanstuur-inskrywing te skep wat daardie poort na die proxy stuur nie. ’n Poort wat van buite oop lyk terwyl niks antwoord, mis dikwels juis daardie koppeling.

Op ’n NAT-VPS karteer die verskaffer ’n openbare poort na ’n private adres. Die kartering moet ooreenstem met die poort wat jy adverteer, en ’n wanverhouding lyk identies aan ’n gebreekte tonnel. Bevestig die verskaffer se kartering voordat jy die WireGuard-konfigurasie verander.

Verifieer die terugpad en aanvaar die koste

Verbind vanaf ’n netwerk wat nie die proxy se LAN is nie, en ondersoek dan die vertalingspaar terwyl die verbinding oop is:

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

Die conntrack-inskrywing behoort die oorspronklike tuple, die vertaalde tuple en die antwoordrigting te wys. As die antwoord ontbreek, stuur die peer nie deur die tonnel nie, wat gewoonlik beteken die SNAT-reël het nie toegepas nie of die peer se eie firewall het die stroom laat val.

Herbegin een keer om te bewys dat PostUp die reëls weer toepas, en stop dan die tonnel en bevestig dat PreDown hulle verwyder het. Dooie reëls wat ’n ontkoppeling oorleef, is die rede waarom ’n latere verandering onvoorspelbaar optree.

Aanvaar uiteindelik wat die SNAT kos. Die diens sien elke versoek as afkomstig van die proxy, so toegangslogboeke, per-kliënt tariefbeperkings en adres-toelatingslyste onderskei nie meer gebruikers nie. Die hairpin-geval het sy eie bronvertaling nodig vir kliënte op die proxy se LAN. As die peer werklike kliëntadresse nodig het, is die alternatief ’n terugroete na die kliëntnetwerk, wat meer werk is maar die inligting bewaar.