Poort doorsturen naar een WireGuard-peer achter NAT: DNAT plus SNAT

Een browser vraagt https://203.0.113.10:8443 aan, de proxy accepteert de verbinding en de dienst op de WireGuard-peer antwoordt nooit. De DNAT-regel doet zijn werk; het antwoord is het deel dat faalt. Volg het pakket door beide vertalingen en de ontbrekende regel wordt duidelijk. De oplossing is één extra NAT-instructie in de juiste hook, geen nieuwe tunnel.

Volg één verzoek van begin tot eind

Het verzoek komt binnen op de openbare interface van de proxy, met het openbare adres van de client als bron en het adres van de proxy als bestemming. In nat PREROUTING herschrijft de DNAT-regel de bestemming naar het tunneladres van de peer, 10.90.0.2. Daarna stuurt de routeringsbeslissing het pakket via wg0 naar buiten, en het doorstuurpad is compleet.

Op de peer draagt het pakket nu het oorspronkelijke openbare bronadres, omdat niets het heeft herschreven. De dienst accepteert de verbinding en stuurt zijn antwoord naar zijn eigen standaardgateway, de thuisrouter vóór de peer. Die router heeft geen status voor een stroom die hij nooit heeft gezien en laat het pakket vallen of vertaalt het naar zijn eigen openbare adres, wat de client niet zal accepteren.

De asymmetrie is het hele probleem: het verzoek gaat via de proxy en het antwoord probeert rechtstreeks te gaan. De verbindingsregistratie van de proxy helpt alleen als het antwoord via de proxy terugkomt, en het kan daar niet terugkomen zolang het bronadres nog naar de oorspronkelijke client wijst.

Voeg de terugvertaling toe

Herschrijf de bron van de doorgestuurde stroom naar het tunneladres van de proxy voordat die naar de peer vertrekt. De dienst antwoordt dan naar 10.90.0.1, de proxy ontvangt het en de verbindingsregistratie keert beide vertalingen om voordat het pakket teruggaat naar de 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

De POSTROUTING-regel is bewust smal: hij past op de vertaalde bestemming en de tunnelinterface, zodat hij geen ongerelateerd verkeer herschrijft dat toevallig via wg0 naar buiten gaat. Een brede masquerade-regel zou het clientadres ook verbergen, maar zou dat voor elke stroom doen en de NAT-tabel moeilijker te auditen maken.

Plaats de regels waar de tunnel bestaat

Regels die naar het tunneladres of de interface verwijzen, moeten draaien nadat wg-quick die heeft geconfigureerd. De interface wordt vóór PreUp aangemaakt, maar adressen, MTU, DNS en routes worden daarna toegepast, en PostUp draait als dat alles op zijn plaats staat. Zet de toevoegingen in PostUp en de verwijderingen 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

De verwijderingen moeten de toevoegingen token voor token volgen, inclusief de multiport- en interface-overeenkomsten. Een verwijdering die één overeenkomst verschilt, verwijdert niets, en de volgende herverbinding voegt een tweede kopie van de regel toe. Na enkele herverbindingen bevat de tabel duplicaten die moeilijk aan een configuratieregel zijn toe te schrijven.

Controleer het resultaat met iptables -t nat -S na een herverbinding. Als dezelfde regel twee keer verschijnt, past de PreDown-regel niet en mislukt het opruimen stil.

Doorsturen, filteren en de andere NAT

Schakel IPv4-doorgifte permanent in en sta daarna de doorgestuurde stroom toe in de filtertabel. DNAT gebeurt vóór de FORWARD-keten, dus de filterregel past op de vertaalde bestemming en niet op het openbare adres. Als UFW de firewall beheert, druk de toestemming uit als een routeregel; een gewone hostregel dekt doorgestuurd verkeer niet.

Twee andere NAT-lagen kunnen het pad nog steeds breken, zelfs als de proxyregels correct zijn. Bij een thuisverbinding hoort het openbare adres bij de router, en de poort in zijn firewall openen is niet hetzelfde als een port-forwarding-item maken dat die poort naar de proxy stuurt. Een poort die van buiten open lijkt terwijl niets antwoordt, mist vaak precies die mapping.

Op een NAT-VPS koppelt de provider een openbare poort aan een privéadres. De koppeling moet overeenkomen met de poort die u aankondigt, en een afwijking ziet er identiek uit als een kapotte tunnel. Bevestig de koppeling van de provider voordat u de WireGuard-configuratie wijzigt.

Controleer de terugweg en accepteer de prijs

Maak verbinding vanaf een netwerk dat niet het LAN van de proxy is en bekijk dan het vertaalpaar terwijl de verbinding open is:

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

De conntrack-vermelding zou de oorspronkelijke tuple, de vertaalde tuple en de antwoordrichting moeten tonen. Als het antwoord ontbreekt, stuurt de peer niet door de tunnel, wat meestal betekent dat de SNAT-regel niet is toegepast of dat de eigen firewall van de peer de stroom heeft laten vallen.

Herstart één keer om te bewijzen dat PostUp de regels opnieuw toepast, stop dan de tunnel en bevestig dat PreDown ze heeft verwijderd. Dode regels die een verbreking overleven, zijn de reden dat een latere wijziging onvoorspelbaar gedraagt.

Accepteer ten slotte wat SNAT kost. De dienst ziet elk verzoek als afkomstig van de proxy, dus toegangslogs, snelheidslimieten per client en lijsten met toegestane adressen onderscheiden geen gebruikers meer. Het hairpin-geval heeft zijn eigen bronvertaling nodig voor clients op het LAN van de proxy. Als de peer echte clientadressen nodig heeft, is het alternatief een terugroute naar het clientnetwerk, wat meer werk is maar de informatie behoudt.