strongSwan auf EC2: Die VPC muss die Arbeitslast routen

Der Tunnel steht, die Gateway-Instanz kann das entfernte Netz pingen, und die Anwendungsinstanz daneben erreicht nichts. Nichts ist kaputt. Der erfolgreiche Test ging vom VPN-Host aus und fragte nie, ob dieser Host eine andere Quelladresse durch dieselbe IPsec-Beziehung tragen kann. Dieses Runbook schließt diese Lücke in vier Schritten, in der Reihenfolge, die jeden Fehler sichtbar hält.

Schreiben Sie zuerst die vier Adressen auf

Jeder folgende Schritt bezieht sich darauf, füllen Sie sie also für Ihr eigenes Konto aus, bevor Sie eine Routentabelle anfassen.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Das Beispiel setzt eine genehmigte, funktionierende richtlinienbasierte IPsec-Verbindung und einen quellentreuen Fluss voraus. Dies ist kein NAT-ter Remote-Access-Client, der eine zugewiesene Adresse leiht, und dieser Unterschied entscheidet, ob die Selektoren geändert werden müssen.

Schritt 1: Geben Sie dem Arbeitslast-Subnetz eine Route

Die Routentabelle, die tatsächlich dem Arbeitslast-Subnetz zugeordnet ist, braucht einen Pfad für das entfernte Präfix, der auf die Netzwerkschnittstelle des Gateways zeigt. Eine im Inneren der Instanz installierte Gastroute ist kein Eintrag in dieser AWS-Routentabelle, und keine noch so große strongSwan-Konfiguration erzeugt einen.

Die Anleitungen zum Appliance-Routing von AWS beschreiben Ziele vom Typ Netzwerkschnittstelle und die Anforderung der Quell-/Zielprüfung für die weiterleitende Instanz. Beschränken Sie diese Prüfungsänderung auf die Gateway-Rolle und lassen Sie gewöhnliche Anwendungsinstanzen in Ruhe.

Ersetzen Sie nicht die lokale Route der VPC oder jeden vorhandenen Eintrag, um Platz für ein genehmigtes Netz zu schaffen. Prüfen Sie, was zugeordnet und aktiv ist, statt was eine Konsolenseite für eine Routentabelle zeigt, die niemand nutzt. Zwei Tabellen, die gleich aussehen, können unterschiedliche Zuordnungen haben. Die entscheidende ist die, an die das Arbeitslast-Subnetz angebunden ist.

Schritt 2: Aktivieren Sie die Weiterleitung auf dem Gast

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Der Kernel muss weiterleiten, und die Host-Firewall muss den Transit erlauben. Fügen Sie die vorgesehenen Weiterleitungsregeln für die Arbeitslast- und die entfernten Präfixe hinzu, statt alles zu akzeptieren, und bestätigen Sie, dass das Gateway-Subnetz eine nutzbare Transportroute für seinen eigenen Verkehr behält.

Sicherheitsgruppen sind der Punkt, an dem dieser Schritt meist hängen bleibt. Eine Middlebox erbt nicht das Sicherheitsgruppen-Referenzverhalten direkter Instanzkommunikation, daher passt eine aus einem verwalteten Client-VPN-Beispiel kopierte Regel möglicherweise nie. Prüfen Sie die Sicherheitsgruppe und die Subnetz-ACL auf dem tatsächlichen Pfad, in beide Richtungen.

Schritt 3: Erweitern Sie die Selektoren auf die echten Quellen

Eine Richtlinie, die auf AWS-Seite nur 10.60.1.10/32 abdeckt, erklärt einen vom Gateway ausgehenden Erfolg, ohne 10.60.2.20 abzudecken. Eine Route zum entfernten Ziel erweitert keinen Traffic-Selector, und das ist die zweite Hälfte derselben Überraschung.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Wenn das vereinbarte Design die gesamte VPC schützt, müssen beide Peers 10.60.0.0/16 und 10.90.0.0/24 akzeptieren. Wenn es eine einzelne Arbeitslast schützt, verwenden Sie bewusst das engere Präfix. Prüfen Sie in jedem Fall die installierte CHILD-SA-Richtlinie, denn eine von Ihnen bearbeitete Konfiguration und ein Peer, der sie anders verengt hat, sind nicht dieselbe Vereinbarung.

Die entfernte Seite muss außerdem Antworten für die erhaltenen VPC-Quellen über das vorgesehene IPsec-Gateway zurückrouten. Behalten Sie die unterstützte NAT-Ausnahme für geschützten Verkehr bei, wo andere Quell-NAT-Regeln bestehen; eine nicht genehmigte Arbeitslast in eine erlaubte Hostadresse zu übersetzen ist ein anderer Identitätsvertrag, keine Abkürzung zu dem Zugang, den Sie wollten.

Schritt 4: Prüfen Sie, und rollen Sie bei Bedarf zurück

Testen Sie von der Arbeitslast selbst mit einer frischen erlaubten Anwendungsoperation und wiederholen Sie dann mit einem Ziel, das ausgeschlossen sein sollte. Notieren Sie die Quelladresse, die der entfernte Dienst sieht, und den Rückweg, den er nutzt. Ein Gateway-Ping oder ein grüner IKE-Status ist dieser Test nicht.

Wenn die Arbeitslast weiterhin fehlschlägt, während das Gateway funktioniert, gehen Sie die Schritte der Reihe nach zurück: Selektor, dann Weiterleitung und Sicherheitsgruppen, dann die zugeordnete Routentabelle. Jeder hat ein eigenes Symptom, und Raten überspringt genau den, der tatsächlich falsch ist.

Das Zurückrollen kehrt dieselbe Reihenfolge um. Entfernen Sie die Route des Arbeitslast-Subnetzes zuletzt, nachdem Sie die vorherigen Selektoren wiederhergestellt haben, damit kein Subnetz auf ein Gateway zeigt, das seine Quellen nicht mehr schützt. Selbsthosting kann mehr als den Gateway-Host bedienen, wenn diese Verträge gelten, und von AWS verwaltetes Site-to-Site VPN ist ein anderes Betriebsmodell, bei dem strongSwan stattdessen am Ende des Kundengateways sitzen kann.