Warum OpenVPN-Clients die IPsec-Selektoren des Gateways verfehlen

Pingen Sie einen Host hinter dem entfernten IPsec-Tunnel vom Gateway aus, antwortet er sauber, der Tunnel wirkt gesund und das Ticket geht weiter. Danach versucht ein verbundener Client denselben Host und bekommt nichts zurück. Dieser Ping war nie ein Beleg für den Fluss des Clients, denn er ging mit der eigenen Quelladresse des Gateways hinaus und traf einen anderen IPsec-Selektor. Zu verstehen, warum die beiden Fälle auseinanderlaufen, ist der größte Teil der Lösung.

Der Ping vom Gateway prüft einen Fluss, den Ihr Client nie nutzt

Die Quelladresse entscheidet, welche Richtlinie gilt. Ein auf dem Gateway erzeugtes Paket verlässt es mit einer Adresse aus seinem lokalen LAN oder von seinem Tunnelendpunkt, und die Richtlinie, die dazu passt, wurde genau für diesen Fall geschrieben. Das Paket eines Clients kommt auf der OpenVPN-Schnittstelle mit einer Adresse aus dem Client-Pool an, was ein völlig anderer Selektor ist.

Deshalb sieht der Fehler wie ein Routingproblem aus, obwohl er in Wahrheit ein Problem des Richtlinienumfangs ist. Erreichbarkeit vom Gateway beweist, dass der Peer läuft und die Vorschläge ausgehandelt wurden, und sie beweist nichts darüber, ob der Pool geschützt ist.

Pushen Sie das entfernte Präfix, das die Anwendung wirklich braucht

Nehmen Sie das illustrative Paar 10.8.0.0/24 für verbundene Clients und 172.30.239.0/25 für das geschützte entfernte Netz. Ein Client braucht eine Route zu diesem zweiten Präfix, nicht zum LAN des Gateways und nicht zu irgendeiner anderen Tunneladresse. Eine in den Pool gepushte Route ist es, die den Client diesen Verkehr überhaupt an das Gateway übergeben lässt. Ohne sie erreicht das Paket niemals die Richtlinienentscheidung, die Sie debuggen.

Auf einem Community-Server, der gepushte Routen annimmt, übernimmt die Direktive die echte Maske: push "route 172.30.239.0 255.255.255.128". Access Server konfiguriert dasselbe Ziel über die Einstellungen für private Netzwerke oder Zugriffsregeln der installierten Version, wobei gerouteter oder übersetzter Modus bewusst gewählt wird. Generierte Firewall-Ketten statt der zuständigen Konfiguration zu bearbeiten, ist der Weg, auf dem eine funktionierende Installation nicht mehr reproduzierbar wird.

Lesen Sie nach dem Verbinden die Routing-Tabelle des Clients statt die Absicht des Servers. Eine Route, die nur den Pool abdeckt, bedeutet, dass der Push nie ankam, und eine Standardroute durch den Tunnel ist breiter als diese Anforderung und wird Sie später überraschen. Prüfen Sie die Maske ebenso wie das Präfix, denn ein als /24 gepuschtes /25 schickt Verkehr für benachbarte Adressen in einen Weg, der ihn nicht tragen kann. Bestätigen Sie dann, dass der Client für dieses Ziel die Tunnelschnittstelle gewählt hat.

Lassen Sie die Selektoren den Client-Pool einschließen

Für gerouteten Zugriff, der Client-Adressen erhält, muss die IPsec-Richtlinie den Verkehr zwischen Pool und entferntem Präfix schützen. Selektoren, die für das eigene LAN des Gateways geschrieben wurden, lassen den Ping zu und verwerfen die Anfrage des Clients, und genau das ist die Asymmetrie, mit der diese Untersuchung begann.

Prüfen Sie die ausgehandelte Richtlinie ebenso wie die konfigurierten Vorschläge, zum Beispiel mit ipsec statusall unter strongSwan oder dem entsprechenden Statusbefehl für Ihre Implementierung. Bei richtlinienbasiertem IPsec kann die gewöhnliche Route auf eine physische Schnittstelle zeigen, während passender Verkehr dennoch verschlüsselt wird, sodass ein fehlendes Tunnelgerät nichts beweist. Vergleichen Sie die Selektor-Paare mit dem Pool und dem Präfix, die Sie notiert haben.

Generisches Quell-NAT auf dem Gateway kann die Übereinstimmung ebenfalls brechen. Wenn eine Masquerade-Regel die Quelle des Clients vor der Richtlinienprüfung umschreibt, sieht das Paket nicht mehr wie der Selektor aus, den Sie geschrieben haben. Das ist ein Grund, warum eine breite Masquerade-Regel eine schlechte Lösung für ein zweites VPN ist: Sie ändert, welche Richtlinie gilt und welche Adresse die Gegenseite protokolliert. Nehmen Sie den Verkehr aus, den Sie routen wollen, oder übersetzen Sie ihn bewusst und aktualisieren Sie die Selektoren.

Wählen Sie Routing oder Übersetzung mit Absicht

Routing hält die Client-Adresse für die Gegenseite sichtbar, sodass entfernte Protokolle und Regeln pro Quelle aussagekräftig bleiben, und es verlangt, dass das entfernte Gateway den Rückweg zum Pool kennt. Übersetzung verbirgt den Pool hinter einer Adresse, was das Rückwegproblem beseitigt und die Identität pro Client zerstört.

Wählen Sie ein Design und schreiben Sie es auf, denn die beiden brauchen unterschiedliche Selektoren und eine unterschiedliche Firewall-Reihenfolge. Eine halb angewandte Masquerade landet dazwischen und erfüllt keines von beiden. Die schriftliche Wahl ist auch das, was den nächsten Ingenieur einen Fehler von einer bewussten Entscheidung unterscheiden lässt.

Schließen Sie den Kreis bei Weiterleitung und Antwort

Das Gateway muss das Protokoll und das Ziel weiterleiten, die Sie beabsichtigen, was aktiviertes IP-Forwarding und eine Forward-Kette bedeutet, die das Paar erlaubt. Die Gegenseite muss Antworten dann über den IPsec-Weg zurückschicken, und das ist eine Routingentscheidung auf deren Gateway und nicht auf Ihrem. Beide Hälften sind gewöhnliche Konfiguration, und beide bleiben leicht halb fertig. Testen Sie sie getrennt, damit eine fehlende Forward-Regel nicht für einen kaputten Tunnel gehalten wird.

Prüfen Sie mit einer echten Anfrage von Client zu Anwendung und beobachten Sie, wie sie die OpenVPN-Schnittstelle, die IPsec-Entscheidung und den entfernten Host durchläuft. Betrachten Sie die Antwort als separate Beobachtung, denn eine ankommende Anfrage und eine Antwort, die nie zurückkehrt, sehen vom Platz des Clients gleich aus. Eine nachverfolgte Anfrage ist mehr wert als beliebig viele Pings vom Gateway.

Halten Sie die Zielautorisierung während des Tests eng und bestätigen Sie, dass ein Client ohne die Regel den Dienst nicht erreicht. Eine installierte Route plus eine aufgebaute Assoziation ist nicht dasselbe wie gewährter Zugriff.