strongSwan zu AWS Site-to-Site: warum die Child SA nichts auswählt

Ein IKE-Tunnel kann stehen, während die Child-Assoziation Ihre Subnetze ausschließt. Vergleichen Sie zuerst die lokale und entfernte CIDR in AWS mit leftsubnet und rightsubnet.

Die Konsole meldet up, strongSwan meldet eine aufgebaute IKE-Assoziation, und die Pakete kommen trotzdem nicht an. Als Nächstes ist nicht der vorab geteilte Schlüssel zu vergleichen, sondern das Paar von Präfixen, von dem jede Seite glaubt, der Tunnel schütze es. Gehen Sie die folgenden Prüfungen der Reihe nach durch, denn die ersten beiden entscheiden, ob der Tunnel Ihren Verkehr überhaupt tragen kann.

Übersetzen Sie die AWS-Namen in die von strongSwan

AWS beschreibt die Verbindung aus Kundensicht: Die Kundengateway-Adresse und das lokale CIDR gehören Ihnen, das entfernte CIDR gehört der VPC. strongSwan nennt die beiden Enden left und right, mit Ihrem Präfix in leftsubnet und dem VPC-Präfix in rightsubnet. Vertauscht man ein Paar, entsteht ein Tunnel, der den falschen Verkehr aushandelt und auswählt.

Laden Sie die Konfiguration herunter, die AWS für die Verbindung erzeugt, und behandeln Sie sie als Referenz genau für diese Verbindung, einschließlich Tunneladressen und Präfixen. Bleiben beide CIDR-Felder beim Anlegen leer, verwendet der Dienst standardmäßig 0.0.0.0/0 auf jeder Seite. Ein Router, der mit einem engen Präfix konfiguriert ist, wird dann nie passen, also füllen Sie die Felder aus oder erweitern Sie den Selektor bewusst.

Eine Abweichung hier sieht wie ein Routingfehler aus und ist keiner.

Fixieren Sie die Adresse, die AWS tatsächlich sieht

Ein Router hinter NAT kann IKE von einer Schnittstelle senden, von der die Gegenseite nie erfahren hat. Die in AWS erfasste Gateway-Adresse muss die sein, die AWS auf der Leitung sieht, und der Router muss auf dieselbe lokale Adresse festgelegt werden, statt seiner Standardroute zu folgen.

conn %default
    local_addrs = 203.0.113.10

In strongSwan wählt local_addrs die Quelladresse für IKE, und ältere OpenSwan-Konfigurationen schreiben dieselbe Idee als left. Richten Sie sie auf die Schnittstelle mit der öffentlichen Adresse, und prüfen Sie dann auf dem NAT-Gerät selbst, ob UDP 500 und 4500 diesen Host erreichen, denn eine Regel, die von einem früheren Router übrig blieb, verwirft sie stillschweigend. Ein korrektes Selektorpaar mit falscher Quelladresse scheitert trotzdem, und das Protokoll beschuldigt den Vorschlag. Diese Irreführung ist der Grund, warum die Quelladresse eine eigene Prüfung verdient.

Bestätigen Sie die Weiterleitungsregel, statt sie anzunehmen, denn eine Regel, die für den vorherigen Router richtig war, bleibt häufig zurück.

Behandeln Sie Phase 1 und Phase 2 getrennt

AWS zeigt IKE- und ESP-Optionen als getrennte Listen. Eine IKE-Suite, die beide Seiten akzeptieren, sagt nichts über den ESP-Vorschlag aus, weil die beiden Listen unabhängig sind. Lesen Sie beide aus der erzeugten Konfiguration und vergleichen Sie sie nacheinander.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Syntax wandert nicht zwischen Implementierungen. Ein Paar, das in OpenSwan funktioniert, etwa phase2alg=aes_gcm mit ike=aes256-sha1;modp1024, muss in strongSwans esp=- und ike=-Form übersetzt werden, und die Algorithmusnamen unterscheiden sich. Weil GCM beim Verschlüsseln authentifiziert, braucht es keine gesonderte Integritätstransformation, anders als eine CBC-Suite mit SHA. Eine Phase-2-Zeile, die unübersetzt von einem Daemon in einen anderen kopiert wird, erzeugt eine Ablehnung, die wie eine Selektorabweichung klingt.

Prüfen Sie die Child-Assoziation, nicht die Tunnelanzeige

Lädt die Verbindung, kommt aber keine Child-Assoziation zustande, wurde entweder der Vorschlag oder die Selektoren abgelehnt. Kommt ein Child zustande und schließen seine Selektoren Ihre Präfixe aus, werden Pakete gefiltert, bevor sie den Tunnel erreichen. Die Anzeige der Konsole deckt nur die IKE-Ebene ab, sie kann Ihnen also nicht sagen, welches der beiden Ereignisse eingetreten ist.

ipsec statusall

Suchen Sie die Child-Sicherheitsassoziation und lesen Sie die daneben ausgegebenen Verkehrsselektoren, dann vergleichen Sie sie mit den Präfixen aus der erzeugten Konfiguration.

Testen Sie von einem Host im lokalen Präfix zu einem Host im VPC-Präfix und prüfen Sie den Rückweg sowie jede Sicherheitsgruppe oder Netzwerk-ACL auf der AWS-Seite. Korrekte Selektoren schützen ein Paket nicht davor, später verworfen zu werden.

Wenn es nach passenden Selektoren immer noch scheitert

Bestätigen Sie, dass die Route auf beiden Seiten zum Tunnel zeigt, und bestätigen Sie dann, dass das NAT-Gerät den Verkehr nicht so umschreibt, wie es die Richtlinie nicht erwartet. Ein richtlinienbasierter Tunnel gleicht Paketadressen ab, eine Übersetzung nach der Richtlinienentscheidung ändert also das Ergebnis.

Protokollieren Sie je ein eingehendes und ein ausgehendes Paket auf jeder Seite, bevor Sie einen weiteren Vorschlag ändern.

Halten Sie die Selektoren, die Phase-1- und Phase-2-Vorschläge und die Quelladresse im Ticket fest. Diese vier Werte erklären die meisten Site-to-Site-Fehler ohne Anruf.

Ähnliche Artikel