Wir führen derzeit AWS-Lambda-Funktionen innerhalb einer VPC aus und haben beispielsweise bereits eine Peering-Verbindung zu MongoDB Atlas eingerichtet, damit unsere AWS-Lambdas innerhalb der VPC mit unserer auf MongoDB Atlas gehosteten Datenbank kommunizieren können.
Nun ist die Anforderung aufgekommen, dass ein bestimmter Dienst innerhalb unseres VPC, den wir durch ein AWS Lambda auslösen und der auch innerhalb desselben VPC läuft, über VPN auf eine lokale Netzwerkfunktion/einen lokalen Host zugreifen muss. Darüber hinaus muss dieses Netzwerk in der Lage sein, auf Nachrichten an diesen Dienst zu reagieren, sodass meines Erachtens eine Site-to-Site-Verbindung erforderlich ist.
Der Kunde hat uns die IKE-Phase-1-Parameter, die IKE-Phase-2-Parameter (IPSEC), seine lokalen Peer-IP-Adressen, die akzeptierten VPN-Kommunikationsports und die lokalen Verschlüsselungsdomänen mitgeteilt.
Sie fragen jetzt nach unseren Remote-Peer-IP-Adressen und Remote-Verschlüsselungsdomänen.
Frage 1: Ist das, was wir erreichen möchten, auf AWS in einem VPC machbar (ich lese widersprüchliche Beiträge dazu).
Frage 2: Gehe ich recht in der Annahme, dass der Tunnel von der Kundenseite aus initiiert werden muss und dass wir dann Netzwerküberwachungs-Polling verwenden, um den Tunnel aktiv zu halten?
Antwort1
Zu Frage 1.
Angenommen, Sie meinen die Möglichkeit, über ein IPSec-basiertes VPN eine sichere Verbindung zu Ressourcen außerhalb von AWS herzustellen. Die Antwort lautet ja. Die native AWS-Implementierung weist jedoch einige Einschränkungen auf. Erstens ist es nicht möglich, Aspekte der Konfigurationseinstellungen für Phase 1 oder Phase 2 anzugeben. Stattdessen bietet Ihnen AWS die Möglichkeit, vorkonfigurierte Einstellungen für eine Reihe von Herstellern herunterzuladen, bietet aber auch einige gute allgemeine Beispiele.
Einige gute Ressourcen sind:
Von AWS verwaltete VPN-Verbindungen- bietet Details zum AWS VPN Gateway-Dienst
Ihr Kunden-Gateway- informiert über die notwendigen Einstellungen am Gerät außerhalb von AWS
Zu Frage 2.
Das stimmt, wenn der Tunnel aus irgendeinem Grund abbricht, kann die AWS-Seite ihn nicht initiieren (das ist meiner Meinung nach eine SEHR ärgerliche Einschränkung). Es gibt jedoch Möglichkeiten, dies zu umgehen. Einige Geräte unterstützen das Senden von Keep-Alive-Paketen, um den Tunnel aufrecht zu erhalten. Beispielsweise können Cisco ASAs die IP-SLA-Funktion nutzen, um SLA-Nachrichten über den Tunnel zu senden und ihn aufrechtzuerhalten. Auszug ausdie Beispiel-ASA-Konfiguration:
Um den Tunnel in einem aktiven oder immer aktiven Zustand zu halten, muss die ASA Datenverkehr an das in acl-amzn definierte Subnetz senden. Die SLA-Überwachung kann so konfiguriert werden, dass Pings an ein Ziel im Subnetz gesendet werden und der Tunnel aktiv bleibt. Dieser Datenverkehr muss an ein Ziel gesendet werden, das eine Antwort zurückgibt. Dies kann manuell getestet werden, indem von der ASA aus ein Ping an das Ziel gesendet wird, das von der externen Schnittstelle stammt. Ein mögliches Ziel für den Ping ist eine Instanz innerhalb der VPC. Zur Redundanz können mehrere SLA-Monitore für mehrere Instanzen konfiguriert werden, um vor einem einzelnen Ausfallpunkt zu schützen.
Oder Sie veranlassen einfach, dass ein System auf einer Seite regelmäßig einen Ping sendet – über einen Cron-Job oder eine geplante Aufgabe.
Eine andere Möglichkeit besteht jedoch darin, Ihr eigenes IPSec-Gateway in AWS bereitzustellen. Dies kann entweder auf der Instanz selbst oder auf einer anderen Instanz ausgeführt werden. Anschließend können Sie die Routentabelle in Ihrem Subnetz aktualisieren, um über diese Instanz zu den externen AWS-Subnetzen zu routen. Dies ermöglicht Ihnen mehr Kontrolle über die IPSec-Einstellungen und das Verhalten, ist aber im Vergleich zum nativen AWS-Dienst wohl komplexer zu verwalten.