Porttrochstjoering nei in WireGuard-peer efter NAT: DNAT plus SNAT

In browser freget https://203.0.113.10:8443 oan, de proxy akseptearret de ferbining, en de tsjinst op ’e WireGuard-peer antwurdet nea. De DNAT-regel docht syn wurk; it antwurd is it diel dat mislearret. Folgje it pakket troch beide oersettings en de ûntbrekkende regel wurdt dúdlik. De oplossing is ien ekstra NAT-stelling yn ’e krekte hook, net in nije tunnel.

Folgje ien fersyk fan begjin oant ein

It fersyk komt oan op ’e iepenbiere ynterface fan ’e proxy, mei it iepenbiere adres fan ’e klant as boarne en it adres fan ’e proxy as bestimming. Yn nat PREROUTING skriuwt de DNAT-regel de bestimming oer nei it tunneladres fan ’e peer, 10.90.0.2. Dêrnei stjoert de routingbeslissing it pakket fia wg0 nei bûten, en it trochstjoerpaad is foltôge.

Op ’e peer draacht it pakket no it oarspronklike iepenbiere boarstadres, om’t neat it oerskreaun hat. De tsjinst akseptearret de ferbining en stjoert syn antwurd nei syn eigen standertgateway, dat is de thúsrouter foar de peer. Dy router hat gjin tastân foar in stream dy’t er nea sjoen hat en hy smyt it pakket fuort of set it oer nei syn eigen iepenbiere adres, wat de klant net akseptearje sil.

De asymmetry is it hiele probleem: it fersyk giet troch de proxy, en it antwurd besiket direkt te gean. De ferbiningsopsporing fan ’e proxy helpt allinnich as it antwurd troch de proxy weromkomt, en it kin dêr net weromkomme salang’t it boarstadres noch nei de oarspronklike klant wiist.

Foegje de werom-oersetting ta

Skriuw de boarne fan ’e trochstjoerde stream oer nei it tunneladres fan ’e proxy foardat er nei de peer giet. Dan antwurdet de tsjinst op 10.90.0.1, de proxy ûntfangt it, en de ferbiningsopsporing keart beide oersettings om foardat it pakket weromgiet nei de klant.

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

De POSTROUTING-regel is mei opsetsin smel: hy past by de oersette bestimming en de tunnelinterfaces, sadat er gjin oare ferkear oerskriuwt dat tafallich fia wg0 fuortgiet. In brede masquerade-regel soe it klantadres ek ferbergje, mar hy soe dat foar elke stream dwaan en de NAT-tabel dreger te kontrolearjen meitsje.

Pleatstje de regels dêr’t de tunnel bestiet

Regels dy’t nei it tunneladres of de interface ferwize, moatte rinne neidat wg-quick it konfigurearre hat. De interface wurdt foar PreUp makke, mar adressen, MTU, DNS en rûtes wurde dêrnei tapast, en PostUp rint as dat alles op syn plak is. Set de tafoegings yn PostUp en de fuortsmittingen yn 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

De fuortsmittingen moatte de tafoegings token foar token passe, ynklusyf de multiport- en interface-oerienkomsten. In fuortsmitting dy’t ien oerienkomst ferskilt, smyt neat fuort, en de folgjende werferbining foeget in twadde kopy fan ’e regel ta. Nei in pear werferbinings befettet de tabel duplikaten dy’t dreech oan in konfiguraasjerigel taskriuwe binne.

Kontrolearje it resultaat mei iptables -t nat -S nei in werferbining. As deselde regel twaris ferskynt, past de PreDown-rigel net en mislearret it opromjen stil.

Trochstjoering, filterjen en de oare NAT

Skeakel IPv4-trochstjoering permanint yn en stean dan de trochstjoerde stream ta yn ’e filtretabel. DNAT bart foar de FORWARD-keten, sadat de filterregel by de oersette bestimming past ynstee fan by it iepenbiere adres. As UFW de firewall beheart, uterje de tastimming as in rûteregel; in gewoane hostregel dekt trochstjoerde ferkear net.

Twa oare NAT-lagen kinne it paad noch brekke, sels as de proxyregels korrekt binne. Op in thúsferbining heart it iepenbiere adres by de router, en it iepenjen fan ’e poarte yn syn firewall is net itselde as it meitsjen fan in porttrochstjoeryngsitem dat dy poarte nei de proxy stjoert. In poarte dy’t fan bûten iepen liket wylst neat antwurdet, mist faak krekt dy mapping.

Op in NAT-VPS maps de provider in iepenbiere poarte nei in privee adres. De mapping moat oerienkomme mei de poarte dy’t jo oankundigje, en in ôfwiking liket identyk oan in brutsen tunnel. Befêstigje de mapping fan ’e provider foardat jo de WireGuard-konfiguraasje feroarje.

Kontrolearje it werompaad en akseptearje de kosten

Ferbyn jo fan in netwurk dat net de LAN fan ’e proxy is, en besjoch dan it oersettingspear wylst de ferbining iepen is:

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

De conntrack-ynfier moat de oarspronklike tuple, de oersette tuple en de antwurdrjochting sjen litte. As it antwurd ûntbrekt, stjoert de peer net troch de tunnel, wat normaal betsjut dat de SNAT-regel net tapast is of dat de eigen firewall fan ’e peer de stream fuortsmiten hat.

Start ien kear opnij om te bewizen dat PostUp de regels opnij tapast, stop dan de tunnel en befêstigje dat PreDown se fuortsmiten hat. Deade regels dy’t in ferbrekking oerlibje binne de reden dat in lettere feroaring ûnfoarsisber gedraacht.

Akseptearje úteinlik wat SNAT kostet. De tsjinst sjocht elk fersyk as fan ’e proxy komme, sadat tagongslogs, snelheidslimiten per klant en adres-allowlists gjin brûkers mear ûnderskiede. It hairpin-gefal hat syn eigen boarne-oersetting nedich foar klanten op ’e LAN fan ’e proxy. As de peer echte klantadressen nedich hat, is it alternatyf in weromrûte nei it klantnetwurk, wat mear wurk is mar de ynformaasje bewarret.