Nach einem IP-Wechsel des Servers nennt die SNAT-Regel noch die alte Adresse

Der Server ist auf eine neue Adresse umgezogen, die Clients verbinden sich weiterhin, und nichts von dem, was sie senden, erreicht das Internet. Genau diese Trennung ist der Hinweis: Der lauschende Socket und die Portweiterleitung haben den Umzug überlebt, also kommt der Tunnel hoch, während die auf weitergeleitete Pakete angewendete Quellübersetzung noch eine Adresse nennt, die der Host nicht mehr besitzt. Antworten auf diese umgeschriebenen Pakete gehen an eine Maschine, die es nicht mehr gibt.

Verbinden und Weiterleiten scheitern an verschiedenen Stellen

Der Aufbau hängt von dem Endpunkt ab, den die Clients bereits kennen: die öffentliche Adresse, die Portweiterleitung davor und der Listener im Inneren. Der weitergeleitete Verkehr hängt von einer zweiten Entscheidung ab, die getroffen wird, nachdem das Paket in den Tunnel eintritt, wenn der Host seine Quelle umschreibt, damit Antworten den Weg zurückfinden.

Ein Adresswechsel bricht nur die zweite Entscheidung, und deshalb liest sich das Symptom als "verbunden, aber kein Internet". Das erklärt auch, warum die üblichen Prüfungen auf Clientseite gesund aussehen: Der Handshake läuft durch, der Client erhält eine Adresse, und sogar ein Ping auf die Tunneladresse des Servers kann antworten. Stunden werden am Client für einen Fehler verbracht, der auf der anderen Seite sitzt, weshalb die Regeltabelle die erste Stelle zum Nachsehen ist.

Lesen Sie die Regel und ihre Zähler, bevor Sie bearbeiten

Listen Sie die Übersetzungsregeln mit Zählern auf und vergleichen Sie die konfigurierte Quelle mit den Adressen, die der Host tatsächlich hält. Eine Regel, die auf eine tote Adresse umgeschrieben wurde, zeigt meist Verkehr auf dem Hinweg, weil Pakete sie erreichen und übersetzt werden, und nichts auf dem Rückweg.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Prüfen Sie drei Felder, während Sie dort sind: den Pool im Quell-Match, das Ausgangsinterface, falls die Regel eines nennt, und die Ausnahme, die verhindert, dass Tunnel-zu-Tunnel-Verkehr umgeschrieben wird. Diese Ausnahme geht bei einer Bearbeitung leicht verloren, und ihr Verlust lässt Peer-Verkehr funktionieren, während seine Antworten einen seltsamen Weg nehmen.

Stehen die Zähler auf null, erreichen Pakete diese Regel nie, und die Adresse ist nicht das aktuelle Problem. Suchen Sie nach einer konkurrierenden Regel weiter oben in der Kette, was passiert, wenn jemand einen Ersatz hinzufügt, statt das Original zu bearbeiten. Vergleichen Sie die Regelnummern mit der Ausgabe, die Sie sich vor einer Minute notiert haben. Reihenfolge ist Teil der Konfiguration, kein kosmetisches Detail.

Ersetzen Sie die Quelle, oder nennen Sie gar keine

Hat der Host eine stabile Adresse, ersetzen Sie die Regel an Ort und Stelle, statt eine weitere anzuhängen. Das Ersetzen nach Regelnummer erhält die Reihenfolge, von der der Rest der Kette abhängt.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Wird die Adresse dynamisch zugewiesen, nennen Sie überhaupt keine Quelle und lassen Sie den Kernel die aktuelle aus dem Ausgangsinterface wählen. Diese Variante übersteht den nächsten Umzug ohne Bearbeitung, um den Preis, zu verbergen, welche Adresse verwendet wurde.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Bestätigen Sie, dass die IPv4-Weiterleitung noch über verwaltete Konfiguration aktiviert ist, und machen Sie die Regel dann mit dem eigenen Mechanismus der Distribution dauerhaft. Eine Änderung, die nur im laufenden Kernel vorgenommen wurde, kehrt mit dem nächsten Neustart zurück, meist in einem Wartungsfenster, das niemand mit der Änderung verbindet.

Zwei Wege, die Ersetzung falsch zu machen

Den Pool auf die Tunneladresse des Servers statt auf seine LAN-Adresse zu übersetzen, schickt Antworten direkt zurück in den Tunnel, wo sie zu einem Client geroutet werden, der sie nie angefordert hat. Die Verbindung hängt auf eine Weise, die wie eine Routingschleife aussieht, weil sie eine ist.

Eine zweite Übersetzung über die alte zu stapeln ist der andere Fehler. Die erste passende Regel gewinnt, also bearbeitet der veraltete Eintrag weiterhin Pakete, bis er gelöscht wird, und die Zähler der neuen Regel bleiben auf null, während alle die Ersetzung beschuldigen. Löschen Sie das Duplikat, bevor Sie etwas Neues hinzufügen. Lesen Sie dann die Liste noch einmal und bestätigen Sie, dass genau eine Übersetzung zum Pool passt.

Trägt der Tunnel auch IPv6, wiederholen Sie die gesamte Prüfung auf dem anderen Stack. Eine IPv6-Standardroute ohne Übersetzung und ohne geroutetes Präfix scheitert ebenso lautlos, und es ist leicht zu vergessen, weil alles darüber identisch aussieht.

Eingehende Dienste brauchen die umgekehrte Übersetzung

Ein Dienst auf einem VPN-Client, der von außen erreichbar sein muss, braucht Zielübersetzung, nicht Quellübersetzung: Der öffentliche Port wird auf die Tunneladresse des Clients umgeschrieben, bevor er eintritt. Der Weiterleitungsweg braucht dann eine ausdrückliche Regel, die diesen Verkehr erlaubt.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Übersetzen Sie niemals den Port, der den Tunnel selbst trägt, denn diese Umschreibung unterbricht die Verbindung, die den Dienst erreichbar hält. Halten Sie den Tunnelport vollständig aus den Zielregeln heraus. Prüfen Sie anschließend von beiden Enden: Zähler an der neuen Regel, eine kurze Aufzeichnung am Tunnelgerät und eine Anfrage an eine Adresse innerhalb des Tunnels, bevor Sie die öffentliche probieren.