Portweiterleitung op e WireGuard-Peer hannert NAT: DNAT plus SNAT

E Browser freet https://203.0.113.10:8443 un, de Proxy hëlt d’Verbindung un, an den Déngscht op dem WireGuard-Peer äntwert ni. D’DNAT-Regel mécht seng Aarbecht; d’Äntwert ass den Deel, dee feelt. Follegt de Paket duerch béid Iwwersetzungen an déi fehlend Regel gëtt evident. D’Korrektur ass eng zousätzlech NAT-Anweisung am richtegen Hook, keen neien Tunnel.

Follegt enger Ufro vum Ufank bis zum Enn

D’Ufro kënnt um ëffentlechen Interface vum Proxy un, mat der ëffentlecher Adress vum Client als Quell an der Adress vum Proxy als Zil. An nat PREROUTING schreift d’DNAT-Regel d’Zil ëm op d’Tunneladress vum Peer, 10.90.0.2. Duerch d’Routing-Entscheedung gëtt de Paket duerno iwwer wg0 erausgeschéckt, an de Weiderleeungswee ass komplett.

Op dem Peer dréit de Paket elo déi originell ëffentlech Quelladress, well näischt se ëmgeschriwwen huet. Den Déngscht hëlt d’Verbindung un an schéckt seng Äntwert op seng eege Standardgateway, dat ass de Heemrouter virum Peer. Dee Router huet keen Zoustand fir e Flux, deen hien ni gesinn huet, an hien entweder verwërft de Paket oder iwwersetzt en op seng eege ëffentlech Adress, wat de Client net akzeptéiere wäert.

D’Asymmetrie ass de ganze Problem: d’Ufro geet duerch de Proxy, an d’Äntwert probéiert direkt ze goen. D’Verbindungsverfolgung vum Proxy hëlleft nëmme wann d’Äntwert duerch de Proxy zréckkënnt, an et kann net dohinner zréck kommen, soulaang d’Quelladress nach op den originelle Client weist.

Füügt d’Zréckiwwersetzung derbäi

Schreift d’Quell vum weidergeleetem Flux ëm op d’Tunneladress vum Proxy, ier en op de Peer fortgeet. Duerno äntwert den Déngscht op 10.90.0.1, de Proxy kritt et, an d’Verbindungsverfolgung dréit béid Iwwersetzungen ëm, ier de Paket zréck op de Client geet.

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

D’POSTROUTING-Regel ass bewosst schmuel: se passt op dat iwwersat Zil an den Tunnelinterface, sou datt se onzougehéieregen Trafick net ëmschreift, dee zoufälleg iwwer wg0 erausgeet. Eng breet Masquerade-Regel géif d’Clientadress och verstoppen, awer se géif et fir all Flux maachen an d’NAT-Tabell schwéier ze auditéieren.

Setzt d’Reegelen do, wou den Tunnel existéiert

Reegelen, déi op d’Tunneladress oder den Interface referenzéieren, musse lafen nodeems wg-quick en konfiguréiert huet. Den Interface gëtt virum PreUp erstallt, awer Adressen, MTU, DNS a Routen ginn duerno ugewannt, an de PostUp leeft, wann dat alles do ass. Setzt d’Ergänzungen an de PostUp an d’Läschungen an de 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

D’Läschungen mussen d’Ergänzungen Token fir Token entspriechen, inklusiv de multiport- an Interface-Match. Eng Läschung déi ëm ee Match ofwäicht, läscht näischt, an déi nächst Verbindung setzt eng zweet Kopie vun der Regel derbäi. No e puer Verbindungen enthält d’Tabell Duplikater, déi schwéier enger Konfiguratiounszeil zouzeschreiwen sinn.

Iwwerpréift d’Resultat mat iptables -t nat -S no enger Verbindung. Wa déiselwecht Regel zweemol erschéngt, passt d’PreDown-Zeil net an d’Botzen feelt roueg.

Weiderleeung, Filterung an déi aner NAT

Aktivéiert d’IPv4-Weiderleeung permanent, an erlaabt dann de weidergeleetem Flux an der Filtertabell. DNAT geschitt virun der FORWARD-Ketten, also passt d’Filterregel op dat iwwersat Zil an net op d’ëffentlech Adress. Wa UFW d’Firewall managt, dréckt d’Erlaabnis als Routenregel aus; eng normal Host-Regel deckt weidergeleetem Trafick net of.

Zwee aner NAT-Schichten kënnen de Wee nach ëmmer briechen, och wann d’Proxy-Reegelen korrekt sinn. Bei enger Heemverbindung gehéiert d’ëffentlech Adress dem Router, an de Port an senger Firewall opzemaachen ass net datselwecht wéi en Portweiderleeungs-Andrag ze schafen, deen dee Port op de Proxy schéckt. E Port, dee vun dobaussen op ausgesäit, während näischt äntwert, fillt dacks genee déi Mapping.

Op engem NAT-VPS mapéiert de Provider en ëffentleche Port op eng privat Adress. D’Mapping muss mat dem Port iwwerenee Stëmmen, deen Dir annoncéiert, an eng Ofwäichung gesäit identesch aus wéi en ënnerbrachne Tunnel. Bestätegt d’Mapping vum Provider, ier Dir d’WireGuard-Konfiguratioun ännert.

Iwwerpréift den Zréckwee a akzeptéiert de Präis

Verbindt Iech vun engem Netz, dat net d’LAN vum Proxy ass, a kuckt dann d’Iwwersetzungspaar, während d’Verbindung op ass:

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

D’conntrack-Andro sollte de originalen Tuple, den iwwersaten Tuple an d’Richtung vun der Äntwert weisen. Wann d’Äntwert feelt, schéckt de Peer net duerch den Tunnel, wat normalerweis heescht, datt d’SNAT-Regel net ugewannt gouf oder datt dem Peer seng eegen Firewall de Flux verworf huet.

Startt eemol nei, fir ze beweisen, datt de PostUp d’Reegelen erëm uwennt, stoppt dann den Tunnel a bestätegt, datt de PreDown se ewechgeholl huet. Doudeg Reegelen, déi en Ofbroch iwwerliewen, sinn de Grond firwat eng spéider Ännerung onberechenbar reagéiert.

Zum Schluss akzeptéiert, wat SNAT kascht. Den Déngscht gesäit all Ufro wéi vum Proxy komm, sou datt Zougangslogs, Vitesslimit pro Client an Adress-Allowlisten d’Benotzer net méi ënnerscheeden. Den Hairpin-Fall brauch seng eege Quell-Iwwersetzung fir Clienten um LAN vum Proxy. Wann de Peer richteg Clientadressen brauch, ass d’Alternativ eng Zréckroute zum Clientnetz, wat méi Aarbecht ass, awer d’Informatioun behält.