Portweiterleitung zu einem WireGuard-Peer hinter NAT: DNAT plus SNAT

Ein Browser fragt https://203.0.113.10:8443 an, der Proxy nimmt die Verbindung an, und der Dienst auf dem WireGuard-Peer antwortet nie. Die DNAT-Regel tut ihre Arbeit; die Antwort ist der Teil, der scheitert. Verfolgen Sie das Paket durch beide Übersetzungen, dann wird die fehlende Regel offensichtlich. Die Korrektur ist eine weitere NAT-Anweisung im richtigen Hook, kein neuer Tunnel.

Eine Anfrage von Anfang bis Ende verfolgen

Die Anfrage kommt am öffentlichen Interface des Proxys an, mit der öffentlichen Adresse des Clients als Quelle und der Proxy-Adresse als Ziel. In nat PREROUTING schreibt die DNAT-Regel das Ziel auf die Tunneladresse des Peers um, 10.90.0.2. Die Routing-Entscheidung schickt das Paket dann über wg0 hinaus, und der Weiterleitungspfad ist vollständig.

Auf dem Peer trägt das Paket nun die ursprüngliche öffentliche Quelladresse, weil nichts sie umgeschrieben hat. Der Dienst nimmt die Verbindung an und schickt seine Antwort an sein eigenes Standard-Gateway, den Heimrouter vor dem Peer. Dieser Router hat keinen Zustand für einen Flow, den er nie gesehen hat, und verwirft das Paket entweder oder übersetzt es auf seine eigene öffentliche Adresse, was der Client nicht akzeptieren wird.

Die Asymmetrie ist das ganze Problem: Die Anfrage geht über den Proxy, und die Antwort versucht, direkt zu gehen. Die Verbindungsverfolgung des Proxys hilft nur, wenn die Antwort über den Proxy zurückkommt, und dorthin kann sie nicht zurückkehren, solange die Quelladresse noch auf den ursprünglichen Client zeigt.

Die Rückübersetzung hinzufügen

Schreiben Sie die Quelle des weitergeleiteten Flows auf die Tunneladresse des Proxys um, bevor er zum Peer verlässt. Der Dienst antwortet dann an 10.90.0.1, der Proxy empfängt es, und die Verbindungsverfolgung kehrt beide Übersetzungen um, bevor das Paket zum Client zurückgeht.

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-Regel ist bewusst eng: Sie passt auf das übersetzte Ziel und das Tunnel-Interface, sodass sie keinen fremden Verkehr umschreibt, der zufällig über wg0 hinausgeht. Eine breite Masquerade-Regel würde die Client-Adresse ebenfalls verbergen, aber sie würde es für jeden Flow tun und die NAT-Tabelle schwerer prüfbar machen.

Die Regeln dort platzieren, wo der Tunnel existiert

Regeln, die die Tunneladresse oder das Interface referenzieren, müssen laufen, nachdem wg-quick es konfiguriert hat. Das Interface wird vor PreUp erstellt, aber Adressen, MTU, DNS und Routen werden danach angewendet, und PostUp läuft, sobald all das vorhanden ist. Setzen Sie die Ergänzungen in PostUp und die Löschungen 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 Löschungen müssen die Ergänzungen Token für Token abbilden, einschließlich der multiport- und Interface-Matches. Eine Löschung, die um einen Match abweicht, entfernt nichts, und die nächste Wiederverbindung fügt eine zweite Kopie der Regel hinzu. Nach einigen Wiederverbindungen enthält die Tabelle Duplikate, die sich schwer einer Konfigurationszeile zuordnen lassen.

Prüfen Sie das Ergebnis mit iptables -t nat -S nach einer Wiederverbindung. Erscheint dieselbe Regel zweimal, passt die PreDown-Zeile nicht, und die Bereinigung schlägt still fehl.

Weiterleitung, Filterung und das andere NAT

Aktivieren Sie die IPv4-Weiterleitung dauerhaft und erlauben Sie dann den weitergeleiteten Flow in der Filter-Tabelle. DNAT geschieht vor der FORWARD-Kette, daher passt die Filterregel auf das übersetzte Ziel statt auf die öffentliche Adresse. Wenn UFW die Firewall verwaltet, drücken Sie die Erlaubnis als Routenregel aus; eine einfache Host-Regel deckt weitergeleiteten Verkehr nicht ab.

Zwei andere NAT-Schichten können den Pfad weiterhin brechen, selbst wenn die Proxy-Regeln korrekt sind. Bei einem Heimanschluss gehört die öffentliche Adresse dem Router, und den Port in dessen Firewall zu öffnen ist nicht dasselbe wie ein Port-Forward-Eintrag, der diesen Port an den Proxy schickt. Ein Port, der von außen offen aussieht, während nichts antwortet, vermisst oft genau diese Zuordnung.

Auf einem NAT-VPS ordnet der Anbieter einen öffentlichen Port einer privaten Adresse zu. Die Zuordnung muss zu dem Port passen, den Sie ankündigen, und eine Abweichung sieht identisch aus wie ein defekter Tunnel. Bestätigen Sie die Zuordnung des Anbieters, bevor Sie die WireGuard-Konfiguration ändern.

Den Rückweg prüfen und den Preis akzeptieren

Verbinden Sie sich aus einem Netz, das nicht das LAN des Proxys ist, und untersuchen Sie dann das Übersetzungspaar, während die Verbindung offen ist:

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

Der conntrack-Eintrag sollte das ursprüngliche Tupel, das übersetzte Tupel und die Antwortrichtung zeigen. Fehlt die Antwort, sendet der Peer nicht durch den Tunnel, was normalerweise bedeutet, dass die SNAT-Regel nicht angewendet wurde oder die eigene Firewall des Peers den Flow verworfen hat.

Starten Sie einmal neu, um zu beweisen, dass PostUp die Regeln erneut anwendet, stoppen Sie dann den Tunnel und bestätigen Sie, dass PreDown sie entfernt hat. Tote Regeln, die einen Verbindungsabbruch überleben, sind der Grund, warum eine spätere Änderung unvorhersehbar reagiert.

Akzeptieren Sie schließlich, was SNAT kostet. Der Dienst sieht jede Anfrage als vom Proxy kommend, sodass Zugriffsprotokolle, Ratenbegrenzungen pro Client und Adress-Allowlists keine Benutzer mehr unterscheiden. Der Hairpin-Fall braucht seine eigene Quellübersetzung für Clients im LAN des Proxys. Wenn der Peer echte Client-Adressen benötigt, ist die Alternative eine Rückroute zum Clientnetz, was mehr Arbeit ist, aber die Information bewahrt.