11 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Eine dreistufige VDC-Topologie (öffentlicher Rand, private Anwendung, private Daten) entwerfen und erklären, warum die Segmentierung, nicht die Regelmenge, die tragende Isolierungsmaßnahme auf IONOS CLOUD ist.
  • Die LAN-Adressierung korrekt planen: den Standard-/24, den reservierten Bereich für verwaltete Dienste, die Gateway-Adressen und die Fälle, in denen statische Adressierung DHCP übertrifft.
  • Entscheiden, wann eine statische öffentliche IPv4 reserviert werden soll, wer sie reservieren kann und wie sich das IPv6-Zuweisungsmodell unterscheidet.
  • Die Topologie mit drei LANs, NICs und einer reservierten öffentlichen IP im Data Center Designer erstellen.

Einheit 3.1: VDC-Topologie und Segmentierung

Einführung

Die erste wesentliche Entscheidung in jeder IONOS CLOUD-Architektur ist nicht, welchen Server man aufbaut, sondern auf welchem Netzwerk jede Ebene angesiedelt ist, da auf dieser Plattform das LAN, auf dem eine Ressource platziert ist, der primäre Faktor ist, der bestimmt, ob sie aus dem Internet erreichbar ist. Ein LAN innerhalb eines virtuellen Rechenzentrums ist privat, bis es explizit mit dem Internet verbunden wird. Daher ist die Erreichbarkeit von außen etwas, das man bewusst hinzuzufügt, und nicht etwas, das man später wieder entfernt. Diese Einheit legt die Topologie fest, in die jeder nachfolgende Aufbau im Modul eingebettet wird: ein öffentliches Edge-LAN, ein privates Anwendungs-LAN und ein privates Daten-LAN. Sie beginnt mit den Entscheidungen zur Adressierung und Segmentierung und endet mit dem Aufbau dieser Drei-LAN-Struktur im Data Center Designer für die erste regulierte Arbeitslast von FinCorp.

1. Das standardmäßig private Netzwerk und die dreistufige Anordnung

Ein LAN wird nur dann öffentlich, wenn ein Element mit Internetzugang daran angeschlossen wird; ohne diese Verbindung ist das Netzwerk privat. Dieses einzelne Verhalten macht standardmäßig privat zum Weg des geringsten Widerstands: Hinterlässt man eine Ebene auf einem nicht verbundenen LAN, ist sie bereits von außerhalb des VDC aus nicht erreichbar. Die dreistufige Anordnung ergibt sich direkt daraus:

  • Ein öffentliches Edge-LAN trägt ausschließlich den internetzugewandten Einstiegspunkt (den Layer-7-Load Balancer in Einheit 3.3 sowie eine mögliche IP-Failover-Kante in Einheit 3.5).
  • Ein privates Anwendungs-LAN trägt die stateless Compute-Ressourcen oder den Kubernetes-Knotenpool.
  • Ein privates Daten-LAN trägt die verwalteten Datenbanken, den Cache und den gemeinsamen Speicher und ist nur über den internen Layer-4-Balancer in Einheit 3.4 erreichbar.

Der Grund, warum diese Schichtung die Kontrolle darstellt und nicht bloß eine Bequemlichkeit, liegt darin, wo die Filterung der Plattform greift. Firewalls auf NIC-Ebene und Network Security Groups werden nur auf Server-NICs auf VDC-Ebene angehängt; sie gelten nicht für den Managed Application Load Balancer, den Managed Network Load Balancer oder die Managed Kubernetes-Cluster-Abstraktion. Da die verwalteten Balancer nicht in eine Security Group eingehüllt werden können, kann man sich nicht auf eine Firewall-Regel verlassen, um eine Platzierung einer Datenbank auf einem öffentlichen Pfad auszugleichen. Die Topologie selbst muss die Isolation leisten. Segmentierung ist daher die tragende Entscheidung, und die Aufteilung in drei LANs ist das Minimum, das sie sauber ausdrückt. Einheit 3.2 fügt dann Firewall- und NSG-Regeln als zweite Schicht innerhalb dieser Topologie hinzu, niemals als Ersatz dafür.

Für FinCorp, das deutsche Finanzdienstleistungsunternehmen, das seine Workloads unter DSGVO- und BSI-Erwartungen betreibt, ist dies die Hülle, in die die regulierte Anwendung einpasst. Die Compliance-Argumentation ist wesentlich einfacher zu führen, wenn die Datenschicht architektonisch nicht in der Lage ist, eine eingehende Verbindung von außerhalb des VDC anzunehmen, weil das Argument auf der Topologie beruht und nicht auf der Korrektheit einer Regelliste.

2. LAN-Adressierung: Das /24-Subnetz, der reservierte Bereich und das Gateway

Jedes LAN verwendet standardmäßig ein /24-Subnetz, das die Adressierungseinheit darstellt, um die herum Sie planen. Innerhalb dieses /24-Subnetzes steht der Adressraum nicht vollständig zur freien Zuweisung zur Verfügung:

  • Die Adressen .2 bis .9 sind für verwaltete Dienste innerhalb des LAN /24 reserviert. Diese dürfen Sie Ihren eigenen VMs nicht zuweisen.
  • Der Bereich .10 bis .255 ist der Adressraum, aus dem VM-IPs zugewiesen werden.

Private LANs nutzen die RFC 1918-Bereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Die maximale Übertragungseinheit (MTU) im LAN beträgt 1500 Bytes. Die Planung unter Berücksichtigung dieser MTU vermeidet Fragmentierungsprobleme, wenn Sie in Einheit 3.6 später verschlüsselte Tunnel über derselben Infrastruktur betreiben.

Die Entscheidung zwischen statischer Adressierung und DHCP wird pro Ebene und pro Rolle getroffen. Die Anwendungsebene kann DHCP tolerieren, da ihre Mitglieder austauschbar und zustandslos sind. Die Datenebene und jeder Knoten, auf den andere Ressourcen per IP zugreifen, sollten eine statische Adresse verwenden. Ein Datenbank-Endpunkt oder ein Load-Balancer-Ziel, das bei der Verlängerung eines Leases seine Adresse wechselt, ist ein ausstehender Ausfall. Die praktische Schutzmaßnahme besteht darin, DHCP-zugewiesene und statisch zugewiesene Adressen in sich nicht überschneidenden Teilen des Bereichs .10-.255 zu halten, damit ein Lease niemals mit einer festgelegten Adresse kollidiert.

Der interne Datenverkehr zwischen LANs im selben VDC erreicht bis zu 6000 Mbps, und der Firewall-Pfad der Netzwerkkarte ist für eine Durchsatzrate von 6 Gbps ausgelegt. Daher stellt die Segmentierungsgrenze für den Ost-West-Verkehr zwischen der Anwendungsebene und der Datenebene keine Leistungsgrenze dar.

3. Reservierte öffentliche IPv4-Adressen und das IPv6-Modell

Eine öffentliche Kante benötigt eine stabile Adresse. Eine reservierte IPv4-Adresse ist an eine Region gebunden: Sie kann nur in der Rechenzentrumsregion verwendet werden, in der sie reserviert wurde. Obwohl verschiedene IPs aus einem reservierten Block unterschiedliche Netzwerke bedienen können, gilt dies weiterhin nur innerhalb derselben Region. Die Reservierung einer IP erfordert das Berechtigungsfeld Reserve IP Blocks. Daher können nur Vertragsinhaber, Administratoren oder Benutzer, denen diese Berechtigung erteilt wurde, eine solche Reservierung vornehmen. Alle anderen Benutzer haben nur Lesezugriff auf die IP-Verwaltung. Ein reservierter IPv4-Block wird mit 5,00 EUR pro 30 Tagen und pro Adresse abgerechnet. IPs können nicht einzeln zurückgegeben werden, sondern nur als Block und nur dann, wenn keine Adresse darin verwendet wird. Wenn Sie eine statische IP zurückgeben, können Sie dieselbe Adresse danach nicht erneut reservieren.

Sie reservieren die öffentliche IP, bevor Sie die Komponente erstellen, die sie verbraucht. Der Layer-7-Load Balancer in Einheit 3.3, das VPN Gateway und das NAT Gateway in Einheit 3.6 sowie die IP-Failover-Kante in Einheit 3.5 setzen voraus, dass eine reservierte öffentliche IPv4-Adresse bereits existiert. Zuerst die verbrauchende Komponente zu provisionieren und anschließend nach einer Adresse zu suchen, ist der häufigste vermeidbare Nacharbeit im Dashboard.

IPv6 folgt einer hierarchischen Zuweisung statt einer Reservierung pro Adresse. Ein VDC erhält eine öffentliche /56-Präfixlänge. Jedes IPv6-fähige LAN erhält eine /64-Präfixlänge (gewählt aus dieser /56 oder automatisch zugewiesen), und jede NIC erhält eine /80-Präfixlänge. Ein VDC kann bis zu 256 IPv6-fähige LANs haben, und die Plattform unterstützt den Dual-Stack-Betrieb. Eine Grenze ist auf der Topologie-Ebene relevant: Die verwalteten Netzwerkdienste (Application Load Balancer, Network Load Balancer, NAT Gateway, IP Failover und Managed Kubernetes) sind ausschließlich IPv4-fähig. Daher terminiert ein IPv6-ausgerichtetes Design seine verwaltete Kante weiterhin auf IPv4.

DCD-Implementierungsanleitung

Sie erstellen die Topologie mit drei LANs von FinCorp: ein öffentliches Edge-LAN, ein privates Anwendungslan und ein privates Daten-LAN, jeweils mit einer Server-NIC pro Ebene und einer reservierten öffentlichen IPv4-Adresse für das Edge. Damit wird die in Abschnitt 1 getroffene Entscheidung zur Segmentierung umgesetzt, bevor darauf Compute-, Sicherheits- oder Load-Balancer-Komponenten aufgebaut werden.

Bauprozess-Ziel: Erstellen der Topologie mit drei LANs, einschließlich NICs und einer reservierten öffentlichen IP.

Schritte (im Data Center Designer):

  1. Öffnen Sie den in Einheit 2.1 erstellten FinCorp-VDC (wiederverwenden Sie ihn; erstellen Sie keine neue Region). Die Region ist bereits festgelegt, und IP-Reservierungen werden an sie gebunden.
  2. Gehen Sie zu Menü > Netzwerk-Dienste > IP-Verwaltung und wählen Sie IP-Blöcke reservieren aus. Reservieren Sie einen öffentlichen IPv4-Block in derselben Region wie der VDC. Sie können keine bestimmte Adresse auswählen; Sie erhalten eine (oder mehrere) aus dem Pool. Dies ist die zukünftige Edge-Adresse, die zuerst reserviert wird.
  3. Platzieren Sie im Arbeitsbereich den Server der Anwendungsebene und den Server der Datenebene. Jeder Server erhält eine NIC, die Sie in den nächsten Schritten einem LAN zuweisen.
  4. Erstellen Sie das private Anwendungslan: Ziehen Sie ein LAN in den Arbeitsbereich (oder verbinden Sie die NIC des Anwendungsservers mit einem neuen LAN) und lassen Sie es unverbunden mit dem Internet, damit es privat bleibt. Behalten Sie die Standardkonfiguration /24 bei.
  5. Erstellen Sie das private Daten-LAN auf dieselbe Weise als zweites privates LAN und hängen Sie die NIC des Servers der Datenebene daran. Verbinden Sie es nicht mit dem Internet.
  6. Erstellen Sie das öffentliche Edge-LAN, indem Sie das Element Internetzugang an ein neues LAN anbinden. Dies ist das einzige LAN, das dem Internet gegenüberliegt; reservieren Sie es für den Edge-Load-Balancer und die NIC für IP-Failover, die in späteren Einheiten erstellt werden.
  7. Setzen Sie auf jeder NIC die Adressierung gemäß Ebene: eine statische Adresse aus dem Bereich .10-.255 für die NIC der Datenebene (damit der Datenbank-Endpunkt stabil bleibt), DHCP ist für die austauschbare Anwendungsnic akzeptabel. Halten Sie .2-.9 für verwaltete Dienste frei.
  8. Stellen Sie die Änderungen bereit. Die Topologie mit drei LANs existiert nun mit der reservierten öffentlichen IP und den segmentierten Ebenen.

Häufige Fehler:

  • Reservierung der öffentlichen IP nach dem Aufbau des Consumers. Reservieren Sie sie zuerst; der Load Balancer, das Gateway oder die Failover-Gruppe erwartet, dass sie existiert.
  • Zuweisung einer VM in den Bereich .2-.9 für verwaltete Dienste oder in den Gateway-Bereich .1/.2, was zu Konflikten mit der Plattformadressierung führt.
  • Verbindung des Daten-LANs mit dem Internet „nur zum Testen", was das gesamte Argument der Segmentierung untergräbt, auf dem die Compliance-Strategie basiert.
  • Platzierung eines IP-Failover-Edges oder eines Load Balancers auf demselben öffentlichen LAN und die Erwartung, dass eine NSG ihn schützt; verwaltete Load Balancer können nicht in eine Sicherheitsgruppe eingebettet werden, daher muss die Sicherheit der Datenebene daraus resultieren, dass sie sich auf einem privaten LAN befindet.
  • Reservierung der IP in der falschen Region; eine reservierte IPv4 ist an eine Region gebunden und kann nicht anderswo verwendet werden.

Unternehmensfallstudie (FinCorp)

Der regulierte, kundenorientierte Dienst von FinCorp ist die Arbeitslast, die dieses Modul verankert. Die Anforderung ist klar formuliert: Kunden erreichen einen öffentlichen HTTPS-Endpunkt, aber die Kontodaten dürfen niemals über das Internet erreichbar sein. Die Designentscheidung besteht darin, dies als Topologie und nicht als Regelsatz auszudrücken. Das öffentliche Edge-LAN trägt später den Layer-7-Load Balancer auf der reservierten IPv4-Adresse; die Anwendungsebene führt die Geschäftslogik auf einem privaten LAN mit per DHCP zugewiesenen, austauschbaren Netzwerkschnittstellen aus; und das relationale Cluster befindet sich auf einem privaten Daten-LAN mit einer statischen Adresse, das ausschließlich durch den internen Layer-4-Load Balancer aus Einheit 3.4 angesprochen wird. Da das Daten-LAN nie mit dem Internet verbunden ist, kann FinCorp gegenüber seinen Prüfern darlegen, dass die Datenbank per Konstruktion keine externe Verbindung annehmen kann, unabhängig davon, ob eine bestimmte Firewall-Regel an einem bestimmten Tag korrekt ist. Jeder spätere Aufbau in diesem Modul hängt an genau dieser Struktur.

Zusammenfassung

Die Netzwerkebene, auf der eine Ressource platziert ist, ist die primäre Steuerung für deren Erreichbarkeit in IONOS CLOUD, da ein LAN privat ist, bis es explizit mit dem Internet verbunden wird, und da die verwalteten Load Balancer und der Kubernetes-Cluster nicht in eine Firewall oder eine Security Group eingebettet werden können. Dadurch wird die Segmentierung, ausgedrückt als dreistufige Topologie (öffentliche Edge, private Anwendung, private Daten), zur tragenden Isolierungsentscheidung. Die Adressierung wird um das /24-Standardnetz geplant, wobei der Bereich .2-.9 für verwaltete Dienste reserviert ist und statische Adressen für jeden Knoten festgelegt werden, der per IP adressiert wird. Eine reservierte öffentliche IPv4-Adresse ist an eine Region gebunden, kostet 5,00 EUR pro 30 Tage, erfordert das Privileg Reserve IP Blocks und sollte vor dem Edge-Objekt reserviert werden, das sie verbraucht; IPv6 wird hierarchisch als /56 pro VDC, /64 pro LAN und /80 pro NIC zugewiesen.

Wichtige Punkte:

  • Ein LAN ist privat, bis ein Element mit Internetzugang angehängt wird, daher ist „privat als Standard“ der Standard und Erreichbarkeit wird bewusst hinzugefügt.
  • NIC-Firewalls und NSGs sind ausschließlich an Server-NICs gebunden, niemals an den verwalteten ALB/NLB oder die Kubernetes-Cluster-Abstraktion, daher ist die Topologie die eigentliche Isolierungssteuerung.
  • Das LAN /24 reserviert .2-.9 für verwaltete Dienste und weist VM-IPs aus .10-.255 zu; statische Adressierung gehört auf jeden Knoten, der per IP adressiert wird, DHCP auf austauschbare Ebenen.
  • Eine reservierte IPv4-Adresse ist an eine Region gebunden, wird mit 5,00 EUR pro 30 Tage abgerechnet, benötigt das Privileg Reserve IP Blocks und muss vor dem verbrauchenden Edge-Objekt reserviert werden.
  • IPv6 ist hierarchisch (/56 pro VDC, /64 pro LAN, /80 pro NIC, bis zu 256 IPv6-fähige LANs), aber die verwalteten Netzwerkdienste sind ausschließlich IPv4.

Wichtige Begriffe:

  • Reservierter IPv4-Block: ein an eine Region gebundener statischer öffentlicher Adressbereich (oder Block), der in IP Management reserviert wird, nur als ganzer Block zurückgebbar und nur, wenn er ungenutzt ist.
  • Verwalteter Dienstepreisbereich (.2-.9): die pro-LAN /24-Adressen, die für plattformverwaltete Dienste reserviert sind und niemals Kundenvm zugewiesen werden dürfen.
  • Dual Stack: gleichzeitiger IPv4- und IPv6-Betrieb in einem LAN; beachten Sie, dass die verwalteten Netzwerkdienste weiterhin ausschließlich IPv4 sind.

Weitere Lektüre

  • Einheit 3.2: Netzwerksicherheit: Firewall und Security Groups (die Regelschicht innerhalb dieser Topologie).
  • Einheit 3.4: Lastverteilung - Layer 4 (der interne Load Balancer vor dem Daten-LAN).
  • Einheit 3.6: Hybridverbindung (die Gateways, die an den Edge- und Egress-Pfaden angeschlossen werden).