Einen LAN-Dienst auf der eigenen Adresse des VPN-Gateways veröffentlichen

Ein LAN-Gerät auf einer der eigenen Tunneladressen des Gateways darzustellen erfordert eine einzige Zeile NAT. Die Verbindung scheitert trotzdem, weil das antwortende Gerät nicht weiß, dass die Client-Adresse über dieses Gateway erreichbar ist. Gehen Sie das Paket vom Client nach innen, dann die Antwort nach außen zurück, und die fehlende Hälfte wird offensichtlich.

Beginnen Sie bei der Sicht des Clients

Der Client in diesem Beispiel liegt im VPN-Pool 10.62.0.0/24 und verbindet sich mit 10.62.0.1 auf Port 8080. Diese Adresse gehört dem Gateway selbst, also kommt das Paket im Kernel des Gateways an und nicht bei einem anderen Peer. Hinter dem Gateway ist das LAN 172.21.4.0/24. Das Gateway hält 172.21.4.10, und das Gerät, das tatsächlich HTTP bedient, ist 172.21.4.40.

Eine Adresse, die zu einem anderen VPN-Peer gehört, ist nicht gegen die Dienst-Adresse des Gateways austauschbar. Verbindet sich der Client mit der Adresse eines Peers, ist überhaupt keine Gateway-Regel beteiligt, und dieser ganze Durchgang ist der falsche.

Grenzen Sie die Zielübersetzung bewusst ein

Die enge Variante stellt einen Port dar und schreibt nur das Ziel um. Das Paket behält sein Protokoll und seine Quelle, und das macht den Rest des Durchgangs interessant.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Eine Regel ohne Kriterien für Protokoll und Port ist die weite Variante: Sie behält den Port, den der Client gewählt hat, und ändert nur die Adresse. Das ist legitim, wenn der ganze Host dargestellt werden soll, und falsch, wenn ein einzelner Dienst beabsichtigt war. Lesen Sie die Regel zurück und bestätigen Sie den Schnittstellennamen. Eine DNAT-Regel auf der falschen Schnittstelle trifft nichts, was dieselbe Zeitüberschreitung erzeugt wie eine fehlende Regel und eine Stunde beim Betrachten des Geräts verschwendet.

Lassen Sie die Weiterleitungsgrenze zustimmen

Die Übersetzung ändert den Header, sie erteilt keine Erlaubnis. Bei einer Standard-Drop-Richtlinie braucht der weitergeleitete Fluss eine eigene Annahme, und die Rückrichtung braucht die Regel für etablierte Verbindungen, die Ihre Richtlinie wahrscheinlich schon hat.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Eine bedingungslose Annahme für jeden DNAT-Fluss ist weiter als dieses Design und erlaubt auch Zuordnungen, die später jemand anderes hinzufügt. Benennen Sie Ziel und Port, und lassen Sie den Rest geschlossen scheitern. Bleiben die Zähler der Weiterleitungsregel auf null, während die NAT-Zähler steigen, wird das Paket vor Ihrer Regel verworfen. Lesen Sie die Kettenreihenfolge, statt eine zweite Kopie hinzuzufügen.

Das Gerät muss irgendwie antworten

Nach der Übersetzung sieht das Gerät eine Quelle in 10.62.0.0/24. Seine Antwort geht an sein Standard-Gateway, und das ist der LAN-Router, nicht das VPN-Gateway, solange nichts ihm etwas anderes sagt. Zwei Anordnungen beheben das, und sie sind nicht gleichwertig. Eine Route auf dem Gerät oder auf dem LAN-Router schickt 10.62.0.0/24 an 172.21.4.10 und bewahrt die Client-Quelle. Eine begrenzte Quellübersetzung versteckt den Client stattdessen hinter der LAN-Adresse des Gateways.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Wählen Sie danach, was der Dienst braucht. Richtlinien pro Client und aussagekräftige Protokolle wollen die geroutete Form; ein Gerät, dem keine Route gegeben werden kann, oder ein Dienst, der einfach eine LAN-Adresse sehen muss, weist auf die übersetzte Form. Greifen Sie nicht zu einer globalen Masquerade-Regel, damit eine einzige Antwort funktioniert. Sie versteckt jeden Client vor jedem Ziel und bricht still die Richtlinien, die von Quelladressen abhängen.

Testen Sie nicht vom Gateway selbst

Eine auf dem Gateway erzeugte Anfrage an 10.62.0.1 verlässt es über die OUTPUT-Kette, nicht über das eingehende PREROUTING. Ihr Scheitern oder Gelingen sagt nichts über die clientseitige Regel aus, und genau so kommen Leute zu dem Schluss, eine funktionierende Regel sei kaputt.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Starten Sie eine echte Client-Anfrage und lesen Sie beides. Der conntrack-Eintrag zeigt die angewandte Übersetzung, und die Mitschnitte zeigen, ob die Anfrage ins LAN ging und ob eine Antwort zum Tunnel zurückkam. Verwenden Sie nach Regeländerungen eine neue Verbindung, denn bestehender Zustand behält seine frühere Zuordnung und wird weiter auf die alte Weise scheitern. Bestätigen Sie dann das ganze Gespräch: Geräteadresse, Weiterleitungserlaubnis und Antwortroute beschreiben denselben Fluss.