SNAT, DNAT und Masquerade: was jede VPN-NAT-Regel tut

Setzen Sie eine Aufzeichnung auf beide Seiten eines VPN-Gateways, und ein einzelner Fluss kann vier verschiedene Adressen zeigen. Quell-NAT schreibt um, woher ein Paket zu kommen behauptet; Ziel-NAT schreibt um, wohin es geht. Masquerade ist keine dritte Richtung, sondern eine Quell-NAT-Regel, die ihre Adresse vom ausgehenden Interface statt von einem festen Wert nimmt. Benennen Sie, welche der drei Sie tatsächlich brauchen, und die meisten Tickets „das VPN ist kaputt“ schrumpfen auf eine Frage nach dem Rückweg.

Was jede Regel umschreibt

Quell-NAT, meist SNAT geschrieben, ändert die Quelladresse eines Flusses, wenn er einen Router oder ein Gateway verlässt. Der empfangende Dienst antwortet an die übersetzte Adresse, und die übersetzende Box macht die Änderung mit dem Zustand rückgängig, den sie für diese Verbindung behalten hat. Unter Linux lebt dieser Zustand in conntrack, deshalb gibt conntrack -L die ursprünglichen und die Antwort-Tupel nebeneinander aus.

Ziel-NAT, DNAT, ändert stattdessen das Ziel. Ein Paket an eine öffentliche Adresse auf UDP 51820 lässt sich auf einen internen WireGuard-Server unter 10.8.0.2:51820 umschreiben. So veröffentlicht ein Heimrouter oder ein Cloud-Loadbalancer einen VPN-Listener, und das sagt nichts darüber, was der Tunnel danach tragen darf.

Masquerade gehört zur SNAT-Familie. Die Regel nennt keine Adresse; sie nutzt die, die das ausgehende Interface beim Verlassen des Pakets hat. Linux gibt ihr ein eigenes Ziel, und sie ist die übliche Wahl auf einem WAN-Interface, das seine Adresse per DHCP oder PPPoE bezieht.

Wo die Abbildung lebt, entscheidet den Fehler

Notieren Sie das Tupel an jeder Grenze: vor dem Tunnel, in ihm und auf dem öffentlichen Interface. Eine Aufzeichnung im Tunnel unterscheidet sich legitim von einer außerhalb, und wer beide vergleicht, ohne zu wissen, wo die Übersetzung stattfindet, jagt den falschen Host.

Rückverkehr muss durch das Gerät laufen, das die Abbildung hält. Nimmt die Antwort eine andere Route, einen zweiten Uplink, eine Policy-Route oder einen Anbieter, der von Ihrem privaten Bereich nie gehört hat, findet die zustandsbehaftete Rückübersetzung nie statt und der Client sieht Einbahnverkehr. Mehr Quell-NAT behebt selten einen fehlenden Rückweg; es kann das Symptom auf einem Fluss verbergen und zugleich adressbasierte Politik überall sonst brechen.

Der andere häufige Fehler ist zu erwarten, ein Tunnel erzeuge Routingfähigkeit. Ein privater Client, dessen Pakete ins Internet gehen, braucht eine gültige Ausgangsregelung: eine Default-Route, ein weiterleitendes Gateway und meist Quellübersetzung auf eine öffentliche Adresse. Verschlüsselung allein macht eine private Adresse nicht erreichbar.

Masquerade oder explizites SNAT

Vergleichen Sie beide nach dem, was sie versprechen. Masquerade wählt die Ausgangsadresse, explizites SNAT nagelt sie fest. Auf einem Gateway mit stabiler öffentlicher Adresse gibt das Festnageln Logs und Partner-Allowlists einen vorhersagbaren Wert. Auf einer dynamischen WAN-Strecke wird eine festgenagelte SNAT-Adresse in dem Moment falsch, in dem sich der Lease ändert, und genau für diesen Fall wurde Masquerade gebaut.

Der Umfang zählt so viel wie die Wahl. Eine Masquerade-Regel, die auf jedes Paket passt, das das Gateway verlässt, ohne Quell- oder Zielgrenze, übersetzt auch Verkehr, den Sie unangetastet lassen wollten, einschließlich Verkehr zu anderen privaten Netzen. Beschränken Sie die Regel auf den Client-Bereich, das beabsichtigte Ziel und das Interface.

Bei policybasiertem IPsec beißt das am härtesten. Die Weiterleitungs-Anleitung von strongSwan führt durch das Aktivieren von IP-Forwarding und das Hinzufügen einer Quell-NAT-Regel für Clients, und dieselbe Dokumentation behandelt das Ausnehmen von Verkehr, der seine ursprüngliche Adresse behalten muss. Übersetzen Sie eine Quelle, bevor die Sicherheitsrichtlinie sie trifft, und der Tunnel kann hochkommen, während der Verkehr weiter fällt, weil das Paket nicht mehr wie der ausgehandelte Selektor aussieht.

Entscheiden Sie auch, was die Gegenseite sehen soll. Nach der Übersetzung sieht ein Dienst das Gateway, nicht den einzelnen Client. Das vereinfacht das Rück-Routing und flacht zugleich Logs ab und entkräftet Allowlists pro Client. Wenn der Erhalt von Client-Adressen zählt, planen Sie einen gerouteten Rückweg, statt sie zu verstecken, damit ein Test besteht.

Die Regeln auf einem Linux-Gateway lesen

Ein Remote-Access-Gateway mit Clients auf 10.8.0.0/24 und einem WAN-Interface namens eth0 braucht aktiviertes Forwarding und eine Filterrichtlinie, die den Fluss erlaubt, bevor irgendeine NAT-Regel helfen kann. Die iptables-Version hält beide Richtungen in der nat-Tabelle:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

Die nftables-Form nutzt dieselben zwei Hooks mit benanntem Interface und expliziter Kette:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Beide Schnipsel setzen voraus, dass die Filterkette den weitergeleiteten Fluss bereits akzeptiert. NAT ist keine Erlaubnisregel, und ein korrekt übersetztes Paket kann eine Tabelle später trotzdem verworfen werden. Bestätigen Sie die lebende Abbildung mit conntrack -L, bestätigen Sie, was geladen ist, mit nft list ruleset oder iptables-save -t nat, und zeichnen Sie dann auf beiden Interfaces auf, um zu sehen, dass sich die Adresse wirklich ändert.

Fehlermodi, die wie eine schlechte Regel aussehen

Haarnadel-Verkehr ist der Klassiker. Ein interner Client, der einen internen Server über die öffentliche Adresse des Servers erreicht, braucht das DNAT auf dem Hinweg und eine Quellübersetzung auf dem Rückweg nach draußen, sonst antwortet der Server direkt an den Client und die Antwort wird verworfen. Die Lösung ist eine zweite, engere Regel für diesen Fall intern-zu-öffentlich, keine breitere Masquerade-Regel für alles.

Die doppelte Übersetzung ist die leise. Ein Client, der schon hinter Carrier-Grade-NAT sitzt, kommt mit einer Adresse an Ihr Gateway, die Sie nicht zurückrouten können, also übersetzen Sie erneut. Es funktioniert, aber Logs tragen nun zwei Sprünge privater Adressierung und jede Untersuchung braucht beide Abbildungen. Policybasiertes IPsec fügt eine dritte Wendung hinzu: Übersetzen Sie vor dem Richtlinienabgleich, und Sie erhalten eine SA, die steht, ohne dass Verkehr durchgeht, was wie ein Firewall-Fehler statt wie ein NAT-Fehler gelesen wird.

Dann gibt es den Test, der besteht, und das Deployment, das scheitert. Den NAT-Befehl von Hand auszuführen beweist den Mechanismus, nicht die Konfiguration. Eine zur Laufzeit hinzugefügte Regel verschwindet beim Neustart oder beim nächsten Interface-Ereignis, und eine Masquerade-Regel, die an ein Interface gebunden ist, das sich neu nummeriert, kann die Adresse, die die Gegenseite sieht, still ändern. Legen Sie die Regel in die Konfiguration der zuständigen Firewall und testen Sie nach einer Neuverbindung erneut.

Checkliste, bevor Sie die Regel speichern

Benennen Sie zuerst die Richtung: Quelle, Ziel oder beides. Bestimmen Sie dann, wer den Zustand halten muss — das Gateway, der Router darüber oder der IPsec-Peer —, und bestätigen Sie, dass der Antwortweg durch ihn zurückkommt. Beschränken Sie die Regel auf den Client-Bereich, das Ziel und das Interface, die Sie wirklich meinen, und entscheiden Sie vorher, ob die Gegenseite das Gateway oder die ursprüngliche Client-Adresse sehen soll.

Testen Sie von einem Client aus, nicht vom Gateway. Ein Browser auf dem Gateway selbst kann die Client-Übersetzungsregel völlig umgehen, eine dort funktionierende Seite beweist also nichts über den Tunnel. Senden Sie eine vom Client ausgehende Anfrage, beobachten Sie die Zähler und die conntrack-Tabelle, und wiederholen Sie das nach einer Tunnel-Neuverbindung und einem WAN-Adresswechsel, falls eines davon an Ihrem Arbeitsplatz möglich ist.