Pag-forward ng port sa isang WireGuard peer sa likod ng NAT: DNAT at SNAT

Humihiling ang browser ng https://203.0.113.10:8443, tinatanggap ng proxy ang koneksyon, at hindi kailanman tumutugon ang serbisyo sa WireGuard peer. Ginagawa ng patakaran ng DNAT ang trabaho nito; ang sagot ang bahaging nabibigo. Sundan ang packet sa dalawang pagsasalin at nagiging malinaw ang nawawalang patakaran. Ang pagwawasto ay isa pang pahayag ng NAT sa tamang hook, hindi bagong tunnel.

Sundan ang isang kahilingan mula simula hanggang wakas

Dumadating ang kahilingan sa pampublikong interface ng proxy, ang pinagmulan ay ang pampublikong address ng kliyente at ang destinasyon ay ang address ng proxy. Sa nat PREROUTING, muling isinusulat ng patakaran ng DNAT ang destinasyon sa address ng tunnel ng peer, 10.90.0.2. Pagkatapos, ipinapadala ng desisyon sa routing ang packet palabas sa wg0, at kumpleto ang landas ng pag-forward.

Sa peer, dala na ng packet ang orihinal na pampublikong source address, dahil walang muling sumulat nito. Tinatanggap ng serbisyo ang koneksyon at ipinapadala ang sagot sa sarili nitong default gateway, na siyang home router sa harap ng peer. Walang estado ang router na iyon para sa isang flow na hindi nito nakita at either itinatapon nito ang packet o isinasalin ito sa sarili nitong pampublikong address, na hindi tatanggapin ng kliyente.

Ang asimetriya ang buong problema: dumadaan ang kahilingan sa proxy, at sinusubukan ng sagot na dumiretso. Ang pagsubaybay ng koneksyon ng proxy ay nakakatulong lamang kung bumabalik ang sagot sa proxy, at hindi ito makakabalik doon habang nakaturo pa ang source address sa orihinal na kliyente.

Idagdag ang pabalik na pagsasalin

Isulat muli ang pinagmulan ng flow na ipinapasa sa address ng tunnel ng proxy bago ito umalis patungo sa peer. Pagkatapos, tumutugon ang serbisyo sa 10.90.0.1, natatanggap ito ng proxy, at binabaliktad ng pagsubaybay ng koneksyon ang dalawang pagsasalin bago bumalik ang packet sa kliyente.

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

Ang patakaran ng POSTROUTING ay sadyang makitid: tumutugma ito sa isinaling destinasyon at sa interface ng tunnel, kaya hindi nito muling isinusulat ang walang kaugnayang trapiko na nagkataong lumalabas sa wg0. Isang malawak na patakaran ng masquerade ay magtatago rin ng address ng kliyente, ngunit gagawin ito para sa bawat flow at gagawing mas mahirap i-audit ang talahanayan ng NAT.

Ilagay ang mga patakaran kung saan mayroong tunnel

Ang mga patakarang tumutukoy sa address o interface ng tunnel ay dapat tumakbo pagkatapos i-configure ito ng wg-quick. Nagagawa ang interface bago ang PreUp, ngunit ang mga address, MTU, DNS at ruta ay inilalapat pagkatapos, at tumatakbo ang PostUp kapag nasa lugar na ang lahat ng ito. Ilagay ang mga dagdag sa PostUp at ang mga pag-alis sa 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

Ang mga pag-alis ay dapat tumugma sa mga dagdag token bawat token, kasama ang mga tugma ng multiport at interface. Ang pag-alis na naiiba sa isang tugma ay walang tinatanggal, at ang susunod na muling pagkonekta ay nagdaragdag ng pangalawang kopya ng patakaran. Pagkatapos ng ilang muling pagkonekta, may mga doble sa talahanayan na mahirap iugnay sa isang linya ng configuration.

Suriin ang resulta gamit ang iptables -t nat -S pagkatapos ng muling pagkonekta. Kung ang parehong patakaran ay lumitaw nang dalawang beses, hindi tumutugma ang linya ng PreDown at tahimik na nabibigo ang paglilinis.

Pag-forward, pag-filter at ang isa pang NAT

Paganahin nang permanente ang pag-forward ng IPv4, pagkatapos ay payagan ang na-forward na flow sa talahanayan ng filter. Nangyayari ang DNAT bago ang chain na FORWARD, kaya tumutugma ang patakaran ng filter sa isinaling destinasyon at hindi sa pampublikong address. Kung ang UFW ang namamahala sa firewall, ipahayag ang pahintulot bilang patakaran ng ruta; hindi saklaw ng simpleng patakaran ng host ang na-forward na trapiko.

Dalawang iba pang layer ng NAT ang makakasira pa rin ng landas kahit tama ang mga patakaran ng proxy. Sa koneksyon sa bahay, pag-aari ng router ang pampublikong address, at ang pagbukas ng port sa firewall nito ay hindi katulad ng paggawa ng entry ng port forwarding na nagpapadala ng port na iyon sa proxy. Ang port na mukhang bukas mula sa labas habang walang tumutugon ay kadalasang kulang sa mismong mapping na iyon.

Sa NAT VPS, iminamapa ng provider ang pampublikong port sa pribadong address. Dapat tumugma ang mapping sa port na inaanunsyo mo, at ang hindi pagtutugma ay mukhang katulad ng sirang tunnel. Kumpirmahin ang mapping ng provider bago baguhin ang configuration ng WireGuard.

I-verify ang pabalik na landas at tanggapin ang gastos

Kumonekta mula sa network na hindi LAN ng proxy, pagkatapos ay suriin ang pares ng pagsasalin habang bukas ang koneksyon:

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

Dapat ipakita ng entry ng conntrack ang orihinal na tuple, ang isinaling tuple at ang direksyon ng sagot. Kung wala ang sagot, hindi nagpapadala ang peer sa tunnel, na karaniwang nangangahulugan na hindi nailapat ang patakaran ng SNAT o itinapon ng sariling firewall ng peer ang flow.

I-restart nang isang beses upang patunayang muli na inilalapat ng PostUp ang mga patakaran, pagkatapos ay ihinto ang tunnel at kumpirmahin na inalis sila ng PreDown. Ang mga patay na patakarang natitira pagkatapos ng pagkadiskonekta ang dahilan kung bakit kumikilos nang hindi mahulaan ang susunod na pagbabago.

Sa huli, tanggapin kung magkano ang SNAT. Nakikita ng serbisyo ang bawat kahilingan bilang nagmumula sa proxy, kaya hindi na nakikilala ng mga access log, rate limit bawat kliyente at listahan ng pinapayagang address ang mga gumagamit. Ang kaso ng hairpin ay nangangailangan ng sarili nitong pagsasalin ng pinagmulan para sa mga kliyenteng nasa LAN ng proxy. Kung kailangan ng peer ang tunay na address ng kliyente, ang alternatibo ay pabalik na ruta sa network ng kliyente, na mas maraming trabaho ngunit pinapanatili ang impormasyon.