Einen IKEv2-Client unter seiner zugewiesenen virtuellen IP erreichen

Ein Gateway muss eine Verbindung zu einem Laptop aufbauen, der über IKEv2 mit ihm verbunden ist, und dabei die zugewiesene virtuelle Adresse dieses Clients verwenden. Der Tunnel steht, der Client erreicht alles hinter dem Gateway, und die Gegenrichtung schlägt weiterhin fehl. Diese Asymmetrie ist normal: Die ausgehandelte Richtlinie beschreibt, welche Adressen miteinander sprechen dürfen, nicht welche Seite beginnen darf. Drei Dinge müssen zusammenpassen, bevor eine vom Gateway ausgelöste Anfrage funktioniert.

Der Tunnel korrigiert die Quelladresse nicht

Eine CHILD SA umfasst ein Paar von Traffic-Selectors, einen pro Seite, und erlaubt Verkehr in beide Richtungen dieses Paares. Sie sagt nichts darüber aus, welcher Peer den IKE-Austausch zuerst eröffnet hat. Ein Gateway, das ursprünglich auf den Tunnel gelauscht hat, kann trotzdem das erste Anwendungspaket senden, sofern die gewählte Quelle und das Ziel innerhalb der installierten Selektoren liegen. Wenn die Anfrage über die falsche Schnittstelle hinausgeht, ist sie für den Tunnel schlicht nicht zulässig.

Routing zum Client ist notwendig und nicht ausreichend. Die Richtlinie muss die Quelle zulassen, die Sie tatsächlich verwendet haben.

Lesen Sie die installierte Richtlinie, nicht die Konfigurationsdatei

Beginnen Sie bei der aktiven Assoziation und ihren Selektoren, denn die dynamische Zuweisung ändert, was im Kernel installiert ist.

ipsec statusall
ip xfrm policy

Die Statusausgabe nennt die Verbindung, die zugewiesene virtuelle Adresse und die Selektoren, die für diesen Peer derzeit gelten. Der Richtlinien-Dump zeigt dieselben Selektoren als Kernelzustand, und genau den zieht die Paketauswahl tatsächlich heran. Vergleichen Sie den Selektor auf der Gateway-Seite mit der Quelle, die Ihre Anwendung verwenden wird, denn eine Abweichung erklärt das Scheitern sofort. Lesen Sie die aktuelle Adresse des Clients und nicht eine aus einer früheren Sitzung, denn eine neu zugewiesene VIP macht die alte Richtlinie ungültig.

Der Client muss dort lauschen, wo das Paket ankommt

Selbst eine perfekte Richtlinie erreicht einen geschlossenen Port, wenn der Dienst nur an Loopback bindet. Der Listener muss auf der zugewiesenen Adresse oder auf einer lokalen Wildcard-Adresse liegen.

ss -ltnp 'sport = :9090'
iptables -S INPUT

Die Socket-Auflistung zeigt, ob der Port an die virtuelle Adresse gebunden ist, und die Firewall-Regeln zeigen, ob neue Verbindungen von der geschützten Quelle angenommen werden. Eine Regel für bestehende Verbindungen lässt eine Verbindung, die das Gateway beginnt, nicht zu. Behalten Sie die eigene Authentifizierung des Dienstes bei, denn die Ankunft durch den Tunnel belegt nur, aus welchem Netz das Paket kam. Ein Client hinter seinem eigenen NAT braucht weiterhin keine eingehende Portweiterleitung, denn diese Anfragen laufen innerhalb des bestehenden Tunnels.

Testen Sie die neue Richtung für sich

Eine funktionierende Anfrage vom Client zum Server durchläuft diesen Pfad nie. Erzeugen Sie die Anfrage vom Gateway und beobachten Sie beide Enden.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

Die Routensuche beantwortet, welche Quelle und Schnittstelle das Gateway verwenden würde, und dieser Wert ist es, den die Richtlinie zulassen muss. Die Aufzeichnung sollte zeigen, dass die Anfrage innerhalb von ESP hinausgeht und nicht als einfaches TCP auf der öffentlichen Schnittstelle. Erfassen Sie auf dem Client den entschlüsselten Verkehr, um die Ankunft und die Antwort des Dienstes zu bestätigen. Wenn die Anfrage ohne ESP auf dem Draht verschwindet, verdächtigen Sie die Quelladresse vor der Firewall des Clients.

Wiederholen Sie den Test nach einem Schlüsselwechsel oder einer erneuten Verbindung, denn die VIP kann sich ändern. Ein Pfad, der nur bis zur nächsten Sitzung funktioniert, ist kein funktionierender Pfad.