Netzdesign & Konnektivität

Netzdesign beginnt mit erlaubten Verkehrsbeziehungen

Erreichbarkeitsvertrag — Eine überprüfbare Aussage darüber, welche Quelle welches Ziel über welchen Pfad, Port und Namensdienst erreichen darf und wo diese Beziehung beobachtet sowie unterbrochen wird.

Ein Diagramm mit VPCs, VNets und Pfeilen ist noch kein Betriebsvertrag. Für jede wichtige Beziehung werden Quelle, Ziel, Richtung, Protokoll, Port, DNS-Name, erwarteter Pfad, Autorisierungsgrenze und Owner benannt. Der Vertrag für eine API kann etwa lauten: Workloads aus dem Produktionsspoke erreichen den privaten Datenbankendpunkt über den regionalen Hub auf TCP 5432; andere Spokes und der öffentliche Endpunkt bleiben ausgeschlossen. Erst diese Präzision lässt sich testen.

Netz und Identität lösen dabei verschiedene Teile. Routing entscheidet, ob ein Paket einen Weg besitzt. Netzfilter entscheiden, ob der Fluss an ihrer Durchsetzungsstelle passieren darf. Die Ressourcen-Policy des Zieldienstes entscheidet, ob der authentifizierte Aufrufer die Datenhandlung ausführen darf. NIST SP 800-207 warnt vor implizitem Vertrauen allein durch Netzstandort. Eine private Route ist deshalb eine wichtige Begrenzung, aber kein Ersatz für Dienstautorisierung.

Adressraum ist eine langfristige Organisationsentscheidung

RFC 1918 reserviert private IPv4-Bereiche, macht ihre Nutzung zwischen Unternehmen aber nicht eindeutig. Zwei Organisationen dürfen denselben Bereich verwenden. Sobald Netze durch Fusion, VPN, Interconnect oder Partnerzugriff verbunden werden, wird Überlappung zum Routingproblem. RFC 1918 nennt Umnummerierung als möglichen Kostenpunkt. Deshalb beginnt Cloud-IPAM mit einer Bestandsaufnahme des Rechenzentrums, bestehender Clouds, Partnernetze und reservierter Zukunftsbereiche.

Ein hierarchischer Plan teilt einen bestätigten Supernet-Block nach Region, Umgebung und Workloadgrenze. Zusammenhängende Zuteilung erlaubt Route Summarization: Der Hub veröffentlicht beispielsweise einen Regionalblock statt hunderter einzelner Spokerouten. Reserve ist bewusst sichtbar und wird nicht nebenbei verbraucht. Der Plan dokumentiert cidr, parentPool, region, environment, Owner und Status. AWS VPC IPAM und vergleichbare Werkzeuge können Zuteilungen und Überlappungen verwalten; sie ersetzen jedoch nicht die organisationsweite Abstimmung.

Kollisionsfreiheit

Bestand und geplante Hybrid-, Partner- sowie Übernahmenetze sind abgeglichen

Hierarchie

Unterblöcke folgen stabilen Routing- und Betriebsgrenzen

Reserve

Wachstum, zweite Region und Migration besitzen ausgewiesenen Raum

Nachweis

Zuteilung, Owner, Status und letzte Prüfung sind zentral auffindbar

Rückweg

Bei unvermeidbarer Überlappung sind NAT oder Umnummerierung als Übergang geplant

IPv6 vergrößert den verfügbaren Adressraum und ermöglicht Ende-zu-Ende-Adressierung ohne den Zwang zu IPv4-NAT. Es hebt die übrigen Entwurfsaufgaben nicht auf: Präfixe müssen geplant, Routen begrenzt, Filter für beide Protokollfamilien gepflegt und DNS-Antworten geprüft werden. Dual Stack bedeutet zwei aktive Datenpfade. Eine Anwendung kann über IPv6 eine Regel umgehen, die nur für IPv4 umgesetzt wurde, oder bei einem fehlerhaften IPv6-Pfad verzögert auf IPv4 zurückfallen.

RFC 4193 beschreibt Unique Local IPv6 Unicast Addresses für lokale Kommunikation. Der zufällig erzeugte Global Identifier soll die Kollisionswahrscheinlichkeit bei später verbundenen Netzen reduzieren; ULA-Präfixe sind trotzdem nicht global geroutet. Global Unicast Addresses und ULA erfüllen unterschiedliche Zwecke. Der Plattformvertrag legt fest, welche Präfixtypen Workloads erhalten, wie ausgehend geroutet wird und ob Partner- oder Hybridnetze sie akzeptieren. IPAM führt IPv4 und IPv6 gemeinsam, damit Besitzer, Region, Umgebung und Lebenszyklus nicht in getrennten Tabellen auseinanderlaufen.

Topologie verteilt Kontrolle und Fehlerauswirkung

Hub-and-Spoke trennt Workloadnetze und bündelt gemeinsam benötigte Fähigkeiten wie Hybrid-Gateways, DNS-Resolver, Firewalls oder Bastionzugriff. Azure dokumentiert den Hub als Ort gemeinsamer Infrastruktur und empfiehlt, Anwendungsworkloads in den Spokes zu belassen. AWS Transit Gateway und Google Network Connectivity Center verwenden ebenfalls zentrale Hub- und Spoke-Konzepte. Die Produkte unterscheiden sich; die Entwurfsfrage bleibt: Welche Beziehungen brauchen Transit und welche sollen absichtlich isoliert bleiben?

Zentralisierung reduziert die Zahl individueller Verbindungen und ermöglicht konsistente Inspektion. Sie erzeugt zugleich gemeinsame Kapazitäts-, Kosten- und Fehlergrenzen. Ein Hub-Ausfall kann viele Spokes betreffen; eine falsch verteilte Default Route kann den gesamten Egress unterbrechen. Direkte Verbindungen können Latenz und Abhängigkeit reduzieren, wachsen aber mit den Beziehungen und umgehen leicht zentrale Kontrollen. Die Wahl wird pro Verkehrsklasse getroffen, nicht als universelles Architekturgesetz.

• Workloadspokes besitzen keine ungeplante Transitivität.
• Gemeinsame Dienste im Hub haben Owner, Kapazitätsziel und regionale Ausfallstrategie.
• Direkte Spoke-Verbindungen werden als Ausnahme mit Zweck und Ablaufdatum geführt.
• Routing und Filter für Ost-West- sowie Nord-Süd-Verkehr werden getrennt abgenommen.

Transit entsteht nur durch ein Element, das ihn wirklich leistet

Peering ist häufig nicht transitiv. Azure VNet Peering leitet Spoke-Verkehr nicht automatisch über einen anderen Peering-Link weiter; dokumentierte Hubmuster benötigen Gateway Transit, eine virtuelle Appliance, Virtual WAN oder passende Routen. In anderen Clouds gelten produktspezifische Regeln. Ein Diagramm, in dem zwei Pfeile am Hub zusammentreffen, beweist daher noch keine Ende-zu-Ende-Route.

Die Diagnose verwendet effektive Routen an Quelle, Transit und Ziel. Für 10.42.8.17 wird die längste passende Route bestimmt, ihr Next Hop geprüft und der Rückweg separat verfolgt. Asymmetrisches Routing kann zustandsbehaftete Firewalls brechen, obwohl beide Richtungen je eine Route besitzen. Route Propagation, statische Routen und Prioritäten müssen deshalb als gemeinsamer Zustand betrachtet werden.

Segmentierung braucht wenige verständliche Zonen

Ein Subnetz pro Dienst schafft noch keine wirksame Segmentierung. Die Grenze muss an einer Stelle durchgesetzt werden, die den Verkehr tatsächlich sieht. Sicherheitsgruppen, Firewallregeln und hierarchische Policies können unterschiedliche Reichweiten besitzen. Ein gutes Modell beginnt mit wenigen Zonen wie öffentlich, Anwendung, Daten, Management und gemeinsam genutzt. Beziehungen werden explizit erlaubt; Zonenbezeichnungen ersetzen keine Regel.

Zu feine Segmentierung erzeugt tausende Regeln, deren Zweck niemand mehr prüft. Zu grobe Segmentierung macht jeden kompromittierten Dienst zum Sprungbrett. Der passende Schnitt folgt Datenklasse, Administrationsweg, Fehlerauswirkung und gemeinsamem Lebenszyklus. Regeln referenzieren stabile Workload- oder Gruppenzugehörigkeit, wo der Anbieter dies unterstützt, und vermeiden flüchtige Einzeladressen. Jede Freigabe besitzt Owner, Begründung und beobachtete Nutzung.

Egress ist ein Produkt mit Beobachtungs- und Ausnahmeweg

Ausgehender Verkehr umfasst Paketquellen, Betriebssystemupdates, Telemetrie, Partner-APIs, Zertifikatsprüfungen und unbekannte Randpfade. Eine sofort aktivierte Allow-Liste auf Basis einer unvollständigen Tabelle erzeugt sporadische Timeouts. Der sichere Einführungsweg leitet Egress zuerst über eine messende Grenze, ordnet Ziele den Workloads zu und setzt danach schrittweise durch. NIST SP 800-53 SC-7 behandelt die Überwachung und Kontrolle von Kommunikation an externen und internen Grenzen.

Der Egressvertrag nennt sourceZone, Zieltyp, Port, Protokoll, Auflösungsweg, Owner und Gültigkeit. Domains sind bequemer als IP-Listen, benötigen aber einen Resolver- und Proxyentwurf, der DNS-Antwort und Verbindung konsistent bewertet. Ein zentraler Proxy oder eine Firewall wird selbst zur Verfügbarkeits- und Durchsatzgrenze. Regionale Instanzen, Kapazitätsalarme und ein kontrollierter Notfallweg gehören deshalb zum Produkt.

Private Endpunkte ändern Pfad, DNS und Dienstgrenze

Private Link, Private Endpoint und Private Service Connect stellen verwaltete Dienste über private Adressen oder anbieterseitige private Pfade bereit. Sie reduzieren öffentliche Netzexposition für die vorgesehenen Clients. Ob der öffentliche Endpunkt weiter existiert, welche Quellen der Dienst akzeptiert und welche Datenaktionen erlaubt sind, bestimmen zusätzliche Dienst- und Ressourcenrichtlinien. Die Abnahme prüft daher Netzpfad und Autorisierung getrennt.

Ein häufiger Fehler ist eine private Adresse bei unverändert öffentlicher Namensauflösung. Clients verwenden den FQDN des Dienstes; die private DNS-Sicht muss diesen Namen zur privaten Adresse führen. Azure beschreibt für Private Link in Virtual WAN ausdrücklich die Kopplung von DNS-Proxy, Private DNS Resolver und Zonenlinks. AWS Route 53 Resolver verwendet Inbound- und Outbound-Endpunkte für hybride Auflösung. Das konkrete Produkt variiert, doch jede Clientgruppe braucht einen definierten Resolverpfad.

Pfad

Traceroute, effektive Route oder Flow-Log zeigt den privaten Eintritt

Name

Der vorgesehene Resolver liefert für denselben FQDN die private Antwort

Dienstgrenze

Öffentliche oder fremde Quellen werden am Dienst abgewiesen

Identität

Nur der berechtigte Prinzipal darf die Datenaktion ausführen

Evidenz

Zielprotokoll nennt Endpunkt, Quelle, Prinzipal und Ergebnis

DNS ist Steuerungsebene für den verwendeten Pfad

Split-Horizon-DNS liefert für denselben Dienstnamen abhängig vom Resolverkontext verschiedene Antworten. Cloudworkloads benötigen private Zonen, Rechenzentrumsclients bedingte Weiterleitungen zu Cloudresolvern, und Cloudresolver brauchen gegebenenfalls Outbound-Regeln für interne Unternehmenszonen. Schleifen und widersprüchliche Zuständigkeiten entstehen, wenn beide Seiten dieselbe Zone weiterleiten oder eine private Zone nur in einem Spoke verknüpft ist.

Die Diagnose folgt der Anfrage: Welchen Resolver fragt der Client? Welche Zone ist dort autoritativ oder wohin wird weitergeleitet? Welche Antwort und TTL kommen zurück? Welchen Pfad erzeugt diese Adresse? Ein Ping auf den FQDN reicht nicht, weil der öffentliche Endpunkt weiterhin erfolgreich antworten kann. Zielseitige Access- oder Flow-Logs belegen den verwendeten Endpunkt. Nach Änderungen werden Caches und negative Antworten berücksichtigt.

Hybridverbindungen brauchen unabhängige Fehlerwege

Site-to-Site-VPN nutzt verschlüsselte Tunnel über IP-Netze und ist schnell bereitzustellen. Dedizierte Verbindungen bieten andere Kapazitäts- und Latenzeigenschaften, benötigen aber Provider- und Standortbereitstellung. Beides kann Teil eines Designs sein: dedizierte Leitungen für den Normalbetrieb, VPN als geübter Rückweg. Zwei logische Sessions auf derselben physischen Trasse bilden keine vollständige physische Redundanz.

Dynamisches Routing tauscht Präfixe und Pfade aus, entscheidet aber nicht automatisch nach Geschäftsabsicht. BGP-Attribute, Route Filtering und Präfixlängen beeinflussen die Wahl. Die Abnahme provoziert den Ausfall einer Verbindung und beobachtet Konvergenz, asymmetrische Flüsse, DNS-Erreichbarkeit und Anwendungssitzungen. Ein grüner Tunnelstatus beweist weder, dass Produktionspräfixe gelernt wurden, noch dass der Rückweg stimmt.

• Provider, Standort und physische Trasse der Wege sind dokumentiert.
• Erlaubte Präfixe werden in beide Richtungen gefiltert.
• Maximale Routenanzahl und angekündigte Summaries sind überwacht.
• Failoverzeit wird an Anwendung und nicht nur am Router gemessen.
• Notfall-NAT oder Umnummerierung ist bei bekannten Überlappungen vorbereitet.

Regionen sind eigene Netzfehlerdomänen

Ein globaler Hub kann Management vereinfachen, bindet aber mehrere Regionen an eine gemeinsame Steuerungs- oder Datenebene. Regionale Hubs begrenzen Fehler und halten lokalen Verkehr lokal, verlangen jedoch konsistente Policy-, DNS- und Routingverteilung. Azure Virtual WAN weist darauf hin, dass Inter-Hub, private und internetgerichtete Verkehrswege je nach Routing Policy unterschiedlich inspiziert werden. Annahmen über automatische Inter-Hub-Inspektion müssen am konkreten Produkt geprüft werden.

Der Multi-Region-Vertrag beschreibt Normal- und Störpfad. Welche Region kündigt welches Präfix an? Wo befindet sich die private DNS-Zone? Welche Egressgrenze bleibt verfügbar? Kann die Recovery-Workload Identität und Schlüssel erreichen? Ein Failover, das nur Compute startet, ist unvollständig, wenn DNS, Transit oder Firewallpolicy weiterhin von der ausgefallenen Region abhängen. Übungen müssen deshalb die gesamte Abhängigkeitskette enthalten.

Flow-Logs erklären Entscheidungen nur mit Kontext

Flow-Logs zeigen typischerweise Quelle, Ziel, Ports, Zeit und eine Annahme- oder Verwerfungsentscheidung. Sie kennen nicht automatisch den fachlichen Auftrag, den DNS-Namen oder den authentifizierten Benutzer des verwalteten Dienstes. Für Diagnose werden deshalb DNS-Logs, Firewall-Entscheide, effektive Routen, Proxylogs und Dienstzugriffsprotokolle zeitlich korreliert. Eine gemeinsame requestId auf Anwendungsebene hilft, den Netzfluss mit dem fachlichen Vorgang zu verbinden.

Beobachtbarkeit wird vor dem Störfall entworfen. Logs landen in einer vom Workloadkonto getrennten Ablage, besitzen definierte Aufbewahrung und enthalten die benötigten Felder. Metriken decken Paketverwerfungen, NAT-Portdruck, Tunnelfehler, BGP-Präfixänderungen, DNS-Fehler und Firewallkapazität ab. Sampling kann für Volumen nötig sein; kritische Steuerungs- und Änderungsereignisse sollten vollständig erfasst werden. Ein Dashboard ohne prüfbare Rohdaten bleibt eine momentane Sicht.

Abnahme prüft positive, negative und gestörte Pfade

Vor Freigabe werden IP-Pools, Zonen, Routingabsicht, Transit, DNS-Zuständigkeit, Egress, Hybridpfade und Owner als Code oder versionierter Vertrag festgehalten. Jede erlaubte Beziehung besitzt einen positiven Test. Jede Schutzgrenze besitzt einen Negativtest aus einer fremden Zone oder über den öffentlichen Pfad. Für zentrale Komponenten existieren Kapazitätsziel, Alarm und Wiederherstellungsverfahren.

Die Störprüfung unterbricht mindestens einen Transit- oder Hybridweg, beobachtet Konvergenz und misst die Anwendung. Private Endpunkte werden aus jeder Clientklasse aufgelöst und im Zielprotokoll nachgewiesen. Egressregeln werden mit einem erlaubten und einem gesperrten Ziel geprüft. Änderungen beginnen mit einer Vorschau effektiver Routen und Policies, laufen in begrenzten Wellen und behalten einen Rückweg. Damit wird das Cloudnetz von einer Sammlung von Komponenten zu einer laufend überprüfbaren Dienstgrenze.

Für jede zentrale Abhängigkeit wird außerdem festgelegt, wie das Team ihren Zustand ohne die ausgefallene Komponente prüfen kann. DNS braucht einen Testnamen und direkte Resolverabfragen, Routing eine lesbare Tabelle effektiver Präfixe, die Firewall einen separaten Administrations- und Logpfad. Der Runbook-Einstieg beginnt mit beobachtbaren Symptomen und führt zur zuständigen Grenze. Nach jeder Übung werden Zielzeit, tatsächlicher Pfad, fehlende Telemetrie und manuelle Sondergriffe erfasst. Diese Befunde fließen als versionierte Änderung in Netzvertrag, Automatisierung und nächste Übung ein.

Adressierung

Keine bekannte Überlappung, hierarchische Pools und Reserve

Routing

Hin- und Rückweg sowie Transit sind als effektiver Zustand belegt

DNS

Jede Clientklasse erhält die vorgesehene private oder öffentliche Antwort

Kontrolle

Erlaubte Flüsse funktionieren, benachbarte und öffentliche Pfade scheitern

Resilienz

Ausfall eines Wegs erfüllt gemessene Konvergenz- und Anwendungsziele

Evidenz

Flow, DNS, Firewall und Dienstzugriff lassen sich korrelieren