Wissensprüfung - Netzwerk und Konnektivität
FinCorp plant den Entwurf eines dreistufigen VDC: eine öffentliche Web-Ebene, eine private Anwendungsebene und eine private Datenebene. Das Sicherheitsteam möchte, dass die Datenebene nur von der Anwendungsebene aus erreichbar ist, und geht davon aus, dass der verwaltete Network Load Balancer vor der Datenebene mit einer IP-Allowlist abgesichert werden kann. Was sollte der Architekt ihnen mitteilen?
NIC-Firewalls und Network Security Groups sind an die Server-NICs und den VDC gebunden, nicht an den verwalteten ALB/NLB oder die Abstraktionsebene des Kubernetes-Clusters. Die korrekte Vorgehensweise besteht darin, die Datenebene topologisch zu isolieren (privates LAN) und auf den Zielsystemen selbst zu filtern; die Erwartung, dass der verwaltete Load Balancer eine Quellfilterung durchführt, ist ein Grenzwertfehler, den die Plattform ausdrücklich nicht unterstützt.
Ein selbst verwaltetes Netzwerk-Firewall-Gerät muss eine einzelne stabile öffentliche IP-Adresse bereitstellen und auf eine Standby-Instanz umschalten, wenn die aktive Instanz ausfällt. Das Team wird seine eigene HA-Software innerhalb des Geräts ausführen. Welches IONOS CLOUD-Konstrukt ist geeignet, und was müssen sie darüber verstehen?
IP-Failover ist genau das selbst verwaltete Active-Passive-Muster: Es provisioniert eine reservierte öffentliche IP-Adresse über redundante NICs und lässt die Gast-HA-Software entscheiden, wann umgeschaltet wird, da die Plattform die Dienstgesundheit nicht überwacht. Ein verwalteter Load Balancer kann kein LAN mit IP-Failover teilen und ist für elastische Ebenen gedacht; das NAT Gateway ist für ausgehenden Traffic bestimmt; DNS-Failover steuert Namen, nicht eine einzelne geteilte IP-Adresse in einem LAN.
FinCorp muss sein On-Premises-Rechenzentrum während der Migration über eine verschlüsselte Site-to-Site-Verbindung mit einem VDC verbinden. Das On-Premises-Gerät ist derzeit für IKEv1 mit BGP-basierter dynamischer Routing-Konfiguration eingerichtet. Was muss der Architekt für das IONOS CLOUD VPN Gateway planen?
Das IONOS CLOUD VPN Gateway unterstützt IKEv2 und WireGuard, jedoch nicht IKEv1. Das Routing erfolgt statisch über die CIDR-Listen für das Cloud-Netzwerk und das Peer-Netzwerk; BGP wird nicht unterstützt. Das veraltete Peer-Gerät muss neu konfiguriert und die zu routenden Subnetze explizit deklariert werden. NAT Gateway und DNAT haben mit dieser Anforderung nichts zu tun.
Private Anwendungsserver in einem VDC müssen OS-Patches herunterladen und eine externe SaaS-API erreichen, dürfen aber nie vom Internet aus erreichbar sein und dürfen keine öffentliche IP besitzen. Der Architekt richtet ein NAT Gateway mit einer reservierten öffentlichen IP und einer SNAT-Regel ein, doch die Server können das Internet weiterhin nicht erreichen. Was ist die wahrscheinlichste Ursache?
Ein NAT Gateway ist ausschließlich SNAT-fähig und leitet Verkehr erst weiter, wenn die privaten VMs den an das Internet gerichteten Verkehr dorthin routen; die Änderung der Routing-Konfiguration (Standardroute zum Gateway oder Ziel-spezifische Routen) ist der am häufigsten übersehene Schritt. Eine DNAT-Regel existiert bei diesem Produkt nicht, und die Zuweisung öffentlicher IPs würde das Ziel eines rein privaten Ausgangsverkehrs vereiteln.
Ein Architekt benötigt eine private Verbindung mit geringer Latenz, um Daten zwischen zwei eigenen VDCs von FinCorp auszutauschen. Die beiden VDCs befinden sich in verschiedenen Regionen und unterliegen, aus Gründen der Abrechnungstrennung, verschiedenen Verträgen. Welche Option ist machbar?
Private Cross-Connect ist kategorisch auf VDCs in derselben Region und unter demselben Vertrag beschränkt, die einen gemeinsamen IP-Bereich nutzen; er kann Regionen oder Verträge nicht überspannen. Die Anforderung an eine Verbindung über Regionen und Verträge hinweg schließt ihn aus, daher muss der Architekt ein anderes Konnektivitätsmodell verwenden. NAT Gateway bietet ausgehenden Internetzugang, aber keinen privaten VDC-zu-VDC-Interconnect.
FinCorp benötigt einen automatisierten Failover für einen öffentlichen Dienst, falls der Endpunkt in der Primärregion ausfällt, um Clients auf einen Endpunkt in der Sekundärregion umzuleiten. Es ist kein verwaltetes Failover-Produkt vorhanden. Wie sollte der Architekt dies gestalten, und welcher Faktor ist der entscheidende Hebel für die Wiederherstellungszeit?
Ohne ein verwaltetes Failover-Produkt ist das native Muster ein vom Kunden orchestriertes DNS-Failover: Ein externer Health Check (zum Beispiel aus der Load-Balancer-Ebene) steuert die Umleitung des Cloud DNS-Eintrags auf einen gesunden Endpunkt. Die TTL des Eintrags bestimmt, wie schnell umgeleitete Clients die Änderung übernehmen, was sie zum dominanten RTO-Hebel macht. Cloud DNS selbst ist nicht health-aware. Da DNS nur neue Verbindungen steuert, muss die bediente Ebene stateless sein. IP-Failover ist auf ein LAN in einer Region beschränkt, und Hebel für NAT/Load Balancer adressieren keinen regionenübergreifenden Endpunkt-Failover.