Problemstellung
Ich benötige einen Geschäftskontinuitätsplan unter Verwendung von AWS Cloud VPC mit folgenden Anforderungen:
- Im privaten AWS VPC-Subnetz unseres Entwicklers werden wir für jeden Entwickler Workspaces (d. h. AWS Secure Desktop-as-a-Service) haben
- Von diesen Arbeitsbereichen aus kann jeder Entwickler über VPN eine Verbindung zu verschiedenen Remote-Clouds herstellen, z. B. zu den öffentlichen Clouds GCP/AWS/Azure oder sogar zu Rechenzentren vor Ort. Diese verschiedenen Remote-Rechenzentren oder öffentlichen Clouds können überlappende IP-Adressbereiche aufweisen, und wir haben keine Kontrolle über die Verwaltung dieser IP-Bereiche.
- Entwickler können vom Arbeitsbereich aus über VPN problemlos zwischen verschiedenen Clouds wechseln und eine Verbindung herstellen.
AWS native Dienste/Funktionen helfen nicht direkt
Site2Site VPN- Um diesen Anforderungen gerecht zu werden, ist AWS Site-to-Site VPN Transit Networking nicht möglich, da es keine überlappenden IP-Bereiche zulässt.
Um das Problem überlappender IP-Adressbereiche indirekt zu lösen, gibt es in den AWS-Dokumentationen einen redundanten Site-to-Site VPN-Plan, der jedoch für Failover-Szenarien gedacht ist und bei dem alle Remote-Clouds jederzeit verbunden sein müssen, also immer aktiv sind.
Transit-Gateway- AWS Transit Gateway hilft nicht, da es idealerweise keine überlappenden IP-Bereiche in Multicloud-Netzwerken zulässt.
Es gibt eine Möglichkeit zur Routensegmentierung, d. h. zur Trennung des Routing-Pfades für separate Kombinationen von miteinander verbundenen Clouds, indem mehrere Routentabellen im Transit Gateway verwendet werden, aber dieser Ansatz erfordert eine solche Segmentierung mithilfe von Transit Gateway-Anhängen, und AWS VPC kann nicht mehr als einen Anhang haben.
Und selbst wenn wir so etwas tun, verwenden wir möglicherweise Software-VPN auf EC2-Instanzen (nicht sicher, ob das möglich ist). Ich bin mir nicht sicher, ob wir problemlos von jedem Arbeitsbereich aus eine Verbindung herstellen und zu allen verschiedenen Clouds wechseln können, da die AWS VPC-Subnetz-Routentabelle des Entwicklers keine überlappenden IP-Bereiche im Ziel haben kann.
Mein Lösungsansatz
Mein Netzwerkplan
Im selben Subnetz dachte ich daran, einen softwarebasierten IPSec-VPN-Ansatz zu verwenden, d. h. in einer Instanz auf EC2 wird es VPN-Dienste wie Strongswan und Iptable-Regeln für SNAT geben. Dieser Ansatz ist inspiriert von der AWS-Support-Antwort aufKonfigurieren von NAT für VPN-Datenverkehr.
Für jede Cloud/jedes Rechenzentrum wird eine EC2-Instanz mit Software-IPSec-VPN und IPtable-Regeln eingerichtet.
Auf der Remote-Seite wird es auch ein Gateway für das VPN geben, genau wie bei der AWS VGW- und Customer Gateway-Kopplung.
Damit der Datenverkehr über VPN vom Workspace zur richtigen Remote-Cloud geleitet werden kann, muss ich in der Routentabelle des Subnetzes einen Eintrag mit „Ziel“ als IP-Adressbereich der Remote-Cloud und „Ziel“ als ENI-ID der VPN-EC2-Instanz vornehmen.
Problem mit diesem Ansatzist wiederum, dass ich für Remote-Clouds mit überlappenden IP-Adressen keinen Eintrag in der AWS VPC-Subnetz-Routingtabelle des Entwicklers haben kann.
Um dieses Problem zu lösen, ich dachte daran, so etwas wie eine IP-Bereichsmanipulation zu machen, bei der ich für jede überlappende Remote-Cloud komplett erfundene oder unrealistische IP-Bereiche haben werde, d. h. für eine Cloud mit einem realen IP-Bereich wie 192.168.xy/16 wird der unrealistische 10.10.pq/16 sein.
Danach werde ich für jede dieser Remote-Clouds einen separaten EC2-VPN-Server haben. Dann wird für die Route für jede der Remote-Clouds der Eintrag in der Routentabelle 10.10.pq/16 als Ziel und die ENI-ID des EC2-VPN-Servers als Ziel sein.
Auf dem EC2-VPN-Server werden wir Iptable-Regeln einrichten, die so etwas wie PREROUTING DNAT und POSTROUTING SNAT für die IP-Only-Weiterleitung tun, wie in diesem gezeigtFragen und Antworten zu Stackoverflow.
Der Entwickler von Arbeitsbereichen muss die Zuordnung zwischen unrealen und realen IPs kennen und den Datenverkehr über unreale IPs senden. Die Iptables-Regeln des EC2-VPN-Servers müssen mithilfe benutzerdefinierter Skripts aktualisiert werden, damit diese Zuordnung immer auf dem neuesten Stand ist.
Ich bin mir der Richtigkeit oder Wirksamkeit meines obigen Ansatzes nicht sicher.
Ein weiteres Problem, das sich aus meinem obigen Ansatz ergibt
Es weckt auch Zweifel, ob ich mich mit Instanzen mit bestimmten IPs in der Remote-Cloud verbinde, aber was ist mit dem Zugriff auf andere Cloud-Dienste wie Serverless-Funktionen oder APIs oder verwaltete/abstrakte Dienste wie DBs/LBs?
Dies kann jedoch durch Senden von Datenverkehr mithilfe von IGW im VPC des Entwicklers oder durch Herstellen einer Verbindung zu einem Bastion-Host in der Remote-Cloud erfolgen.
Anderer Ansatz, den ich im Internet gesucht habeist das Einrichten eines benutzerdefinierten Multicloud-Overlay-Netzwerks, was entmutigend oder Raketenwissenschaft zu sein scheint.
Ich bin mir auch nicht sicher, ob Open-Source-VPNs wie OpenVPN oder pfsense wie Firewall-/Netzwerksoftware mit einigen ihrer nativen Funktionen helfen können, mein ursprüngliches Problem zu lösen.
Ich habe mein gesamtes Wissen über Netzwerke oder VPNs ausschließlich bei meiner Arbeit mit der AWS Cloud erworben und kenne mich mit den allgemeinen Netzwerkkenntnissen der Informatik nicht so gut aus.
Bitte helfen Sie bei diesen Problemen.