Der Router beendet das VPN selbst, und eine alte Weiterleitungsregel schickt denselben UDP-Port weiterhin an eine Maschine im LAN. Nur eines davon kann der echte Endpunkt sein, und der Kernel entscheidet nicht zwischen ihnen. Die Zielübersetzung schreibt das Paket um, bevor der lokale Dienst befragt wird, sodass der VPN-Prozess auf Verkehr wartet, der bereits woandershin geschickt wurde. Die Aufgabe ist, zu entscheiden, wem der Port gehört, und dann die Regeln in Einklang zu bringen.

Ein Port, zwei beanspruchte Eigentümer

Ein VPN-Server, der im Router läuft, braucht eine eingehende Erlaubnis, die zu seinem eigenen Socket führt. Ein Ziel-NAT-Eintrag für denselben Port führt ganz woandershin: zu einer LAN-Adresse und einer Weiterleitungsentscheidung. Das sind verschiedene Endpunkte mit verschiedenen Protokollen und verschiedenen Fehlerarten. Der übliche Hinweis ist, dass eine Adressfamilie funktioniert und die andere nicht, weil der übrig gebliebene Eintrag für eine einzige Familie geschrieben und nie überprüft wurde.

Notieren Sie den Anspruch vor dem Bearbeiten: Familie, externe Adresse, Transport, Port und das übersetzte Ziel.

Die Übersetzung läuft vor der lokalen Prüfung

Ziel-NAT ändert das Ziel des Pakets in der Prerouting-Phase, bevor der Kernel zwischen lokaler Zustellung und Weiterleitung wählt. Sobald das Ziel ein LAN-Host ist, nimmt das Paket den Weiterleitungspfad. Eingangsregeln für den eigenen Socket des Routers werden nie herangezogen, deshalb bleibt das VPN-Protokoll leer, während der Client in einen Timeout läuft.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Diese Reihenfolge ist der ganze Mechanismus, und Geräteoberflächen verstecken sie hinter Kontrollkästchen, ohne sie zu ändern. Der Eigentümer des Ziels entscheidet weiterhin, welchen Pfad ein Paket nimmt.

Wenn der LAN-Host der beabsichtigte Endpunkt ist, ist die Weiterleitung richtig, und der Router sollte nicht zusätzlich auf diesem Port lauschen.

Eine Zuordnung behalten und die andere entfernen

Listen Sie die NAT-Einträge für diesen Port und diese Familie auf und wählen Sie den Überlebenden:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Ein TCP-Eintrag mit derselben Nummer ist für einen UDP-Fehler irrelevant, und wenn man beide als ein Objekt behandelt, löscht man die falsche Regel. Wenn der lokale Socket gewinnen soll, entfernt oder überschreibt der Eigentümer der widersprüchlichen Zuordnung genau diesen Eintrag, und die eingehende Erlaubnis für den eigenen Port des Routers bleibt bestehen. Unbeteiligte Weiterleitungen, der Verwaltungspfad und eine Kopie des Regelsatzes sollten die Änderung alle überstehen.

Wenn das VPN auf einem separaten Host lebt, ist die Weiterleitung das richtige Objekt. Ein Dienst in einem Container oder einer virtuellen Maschine braucht möglicherweise einen veröffentlichten Port, selbst wenn die Kiste Router genannt wird; folgen Sie also dem Socket und seinem Namespace statt dem Etikett auf dem Gehäuse.

Den Eigentümer von außen bestätigen

Testen Sie jede Familie einzeln, denn eine IPv6-Verbindung, die am Router endet, sagt nichts über eine IPv4-Verbindung aus, die eine alte Regel umleitet. Lesen Sie das Protokoll des empfangenden Dienstes, um zu sehen, welcher Endpunkt geantwortet hat, und behandeln Sie die Erfolgsmeldung des Clients als schwachen Beweis. Für einen aussagekräftigen Test ist ein neuer Flow nötig. Senden Sie eine Sonde von einem externen Host mit nc -zvu 203.0.113.7 1194 und lesen Sie das Protokoll des Gewinners mit journalctl -u openvpn@server -n 20. Der Listener des Routers protokolliert die Verbindung selbst, während ein LAN-Host sie in seinem eigenen Dienst protokolliert.

Die Verbindungsverfolgung hält bestehende Flows auf ihrer ursprünglichen Zuordnung, sodass eine etablierte Sitzung die gerade korrigierte Regel überleben kann.

Wenn der beabsichtigte Endpunkt mit seinen normalen Identitätsprüfungen antwortet, testen Sie eine private Ressource hinter dem Tunnel. Den äußeren Listener zu erreichen ist nur der erste Sprung; inneres Routing und Anwendungsautorisierung sind getrennte Ergebnisse.

Ähnliche Artikel