Zwei VPN-Clients, zwei öffentliche Adressen: SNAT passend machen

Zwei VPN-Clients können über zwei verschiedene öffentliche IPv4-Adressen nach außen gehen, und die Regel dafür ist kürzer, als die meisten erwarten. Was sie funktionieren lässt, ist nicht die iptables-Syntax, sondern der Zustand des Pakets, wenn es die Egress-Kette erreicht: Die Quelladresse dort muss die Clients noch unterscheiden können. Hat ein früheres Masquerade beide bereits auf eine Adresse zusammengelegt, kann keine Regel pro Client die Unterscheidung wiederherstellen. Klären Sie diese Frage zuerst, und schreiben Sie dann die Übersetzung.

Welche Identität das Gateway erreicht

Die Regel gleicht die Quelladresse des Pakets ab, nicht einen VPN-Benutzernamen und nicht den Namen, den eine Client-Anwendung anzeigt. Alles, was das Paket vorher auf dem Weg übersetzt, entscheidet, was Ihre Regel noch sehen kann. Führen Sie die nat-Tabelle der Reihenfolge nach aus und finden Sie die Stelle, an der die Quelle noch pro Client verschieden ist.

iptables -t nat -S POSTROUTING

Lesen Sie diese Auflistung von oben. Eine Masquerade-Regel nahe dem Anfang schreibt die Quelle für jeden passenden Fluss um, und danach platzierte Einträge pro Client gleichen eine Adresse ab, die es nicht mehr gibt. Wenn zwei LAN-Geräte einen Tunnel teilen und als eine einzige innere Adresse ankommen, muss sich das Design ändern, bevor es die Firewall tut: Halten Sie ihre Quellbereiche getrennt oder geben Sie jedem seine eigene innere Adresse.

Binden Sie die Zuweisung der inneren Adresse an den authentifizierten Client. Wer diese Adresse an ein anderes Gerät weitergibt, gibt die Egress-Richtlinie mit weiter, und Quellübersetzung ist für sich genommen kein Identitätsnachweis.

Übersetzung kann keine Adresse erfinden

Jede öffentliche Adresse muss diesem Egress-Punkt zugewiesen oder dorthin geroutet sein, und die Antworten müssen den Weg dorthin zurückfinden. Eine Regel, die Verkehr von einer Adresse sendet, zu der niemand zurückroutet, wird am fernen Ende verworfen oder an einen Host beantwortet, der nie danach gefragt hat. Eine Cloud-Provider-Instanz hat ihre öffentliche Adresse meist schon vor dem Verlassen des Pakets auf eine private Interface-Adresse übersetzt, also muss die SNAT-Quelle die Adresse sein, die der Provider akzeptiert, nicht der Wert, den die Konsole zeigt. Lesen Sie das Adressmodell des Providers und folgen Sie ihm, statt den öffentlichen Wert in jedes Paket zu kopieren.

In der Praxis heißt das, das geroutete Präfix in der Provider-Konsole zu prüfen, bevor Sie die Firewall anfassen, und die private Interface-Adresse als Übersetzungsquelle zu verwenden, wenn die Zuordnung eins zu eins ist. Die in den Beispielen unten verwendeten Adressen stammen aus den Dokumentationsbereichen, also ist das Erste, was ersetzt werden muss, der Adresstext selbst.

Vor dem generischen Masquerade einfügen

Bestätigen Sie das Egress-Interface und die aktuelle Kette, bevor Sie etwas hinzufügen. Das erste entscheidet, welche Pakete die Regel abgleichen kann, und das zweite zeigt, was bereits davor steht.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

Der erste Befehl nennt das Interface, über das ein Paket ins Internet tatsächlich hinausgeht. Der zweite gibt die Kette mit Zeilennummern aus. Der generische Masquerade-Eintrag ist die Zeile, über der Sie bleiben müssen.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

Die beiden Regeln oben gleichen je eine innere Adresse ab, beschränken den Abgleich auf das Egress-Interface und setzen die Quelle ausdrücklich. Einfügen statt anhängen: an Position 1 werden sie vor der Masquerade-Zeile ausgewertet. Die Reihenfolge zwischen beiden spielt keine Rolle, weil sich ihre Quellen unterscheiden. Ersetzen Sie ens3 durch das, was der route-Befehl gemeldet hat, und halten Sie andere Firewall-Manager von denselben Hooks fern, denn zwei Werkzeuge, die eine Tabelle schreiben, sind der übliche Grund, warum eine korrekte Regel keine Wirkung hat.

Die Quelle mit einem neuen Fluss beweisen

Stateful NAT bindet eine Übersetzung, wenn ein Fluss beginnt, und verwendet sie für spätere Pakete wieder, sodass eine vor der Änderung geöffnete Sitzung nach der Änderung ihre alte Quelle behält. Nur eine neu aufgebaute Verbindung beweist die Regel.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Lesen Sie die Antwortrichtung dieses Eintrags: Sein Ziel ist die Adresse, die der entfernte Endpunkt als Quelle sieht. Vergleichen Sie sie mit der beabsichtigten öffentlichen Adresse, und behandeln Sie einen Eintrag mit der alten Adresse als Beleg für einen zu früh gestarteten Fluss, nicht für eine defekte Regel. Bitten Sie den Client, eine neue Verbindung zu öffnen, und wiederholen Sie dann die Abfrage. Die gesamte Tracking-Tabelle zu leeren, um den Test zu erzwingen, unterbricht jede andere Sitzung am Gateway.

Übersetzung wählt weiterhin nicht die Route, lässt den Fluss nicht durch den Filter und veröffentlicht keinen eingehenden Dienst. Eine falsche Route und eine fehlende Allow-Regel scheitern auch nach einer perfekten SNAT-Regel weiter. Prüfen Sie auch IPv6 und jeden sekundären Egress-Pfad, und notieren Sie dann die Paare innen-zu-öffentlich in der Firewall-Dokumentation, damit die nächste Änderung von der Zuordnung ausgeht statt vom Regeltext.