Azure Networking Deep Dive – Die Netzwerktechnik hinter der Cloud

Wenn Netzwerktechnik zur Cloud-Ressource wird

Wer sich mit klassischen Unternehmensnetzwerken beschäftigt, begegnet einer vergleichsweise greifbaren Infrastruktur. Switches verbinden Geräte innerhalb lokaler Netzwerke, Router vermitteln Datenpakete zwischen unterschiedlichen IP-Netzen und Firewalls kontrollieren die Kommunikation anhand definierter Sicherheitsrichtlinien. Die beteiligten Komponenten lassen sich identifizieren, konfigurieren und mit geeigneten Werkzeugen untersuchen.

Diese technischen Zusammenhänge stehen auch in meinen Cisco-Seminaren zur Vorbereitung auf die CCNA-Zertifizierung im Mittelpunkt. Dabei geht es mir weniger um das bloße Konfigurieren einzelner Netzwerkgeräte als vielmehr um das Verständnis ihrer Funktionsweise. Warum wählt ein Router einen bestimmten Weiterleitungspfad? Wie verarbeitet ein Switch Ethernet-Frames? Wer diese Mechanismen versteht, kann Netzwerkarchitekturen fundiert planen, ihre Funktionsweise nachvollziehen und Fehler systematisch analysieren.

Mit Microsoft Azure verändert sich die Perspektive. Administrator:innen erstellen virtuelle Netzwerke, definieren Subnetze und konfigurieren Routingtabellen, ohne unmittelbar auf die zugrunde liegenden physischen Netzwerkgeräte zuzugreifen. Stattdessen stellt Microsoft logisch abstrahierte Ressourcen bereit, die sich über das Azure-Portal, Programmierschnittstellen oder Infrastructure-as-Code-Werkzeuge verwalten lassen. Die technischen Grundlagen bleiben jedoch erhalten. Auch in der Cloud müssen Datenpakete weitergeleitet, gefiltert und gegebenenfalls übersetzt werden. Routingentscheidungen sind ebenso notwendig wie die Durchsetzung von Sicherheitsrichtlinien und die Abgrenzung unterschiedlicher Netzwerksegmente.

Der wesentliche Unterschied liegt daher weniger in den Netzwerkfunktionen als vielmehr in ihrer Bereitstellung, Steuerung und technischen Umsetzung. Während klassische Netzwerke häufig anhand konkreter Geräte nachvollziehbar sind, verbirgt Azure diese Funktionen hinter einer virtualisierten Infrastruktur. Die Netzwerktechnik verschwindet in der Cloud nicht. Sie wird abstrahiert – und gerade deshalb lohnt sich ein genauerer Blick auf die Mechanismen hinter den virtuellen Ressourcen.

Wenn die Konfiguration einfacher wird, die Architektur aber komplexer

Auf den ersten Blick erscheint die Bereitstellung eines Netzwerks in Microsoft Azure erstaunlich unkompliziert. Ein Virtual Network lässt sich mit wenigen Angaben erstellen, Subnetze werden durch IP-Adressbereiche definiert und Network Security Groups ermöglichen die Konfiguration von Zugriffsregeln. Die Bereitstellung und Verwaltung physischer Netzwerkgeräte übernimmt Microsoft. Diese Vereinfachung betrifft jedoch vor allem die Administration. Hinter den sichtbaren Ressourcen arbeitet eine hochgradig verteilte Infrastruktur, die zahlreiche Anforderungen gleichzeitig erfüllen muss. Virtuelle Netzwerke unterschiedlicher Kund:innen nutzen gemeinsame physische Ressourcen, müssen aber zuverlässig voneinander isoliert bleiben. Gleichzeitig muss Azure neue Ressourcen automatisiert bereitstellen, Sicherheitsrichtlinien durchsetzen und auch bei hoher Auslastung oder beim Ausfall einzelner Komponenten eine möglichst hohe Verfügbarkeit gewährleisten.

Damit verändert sich auch die Perspektive auf die Netzwerktopologie. In klassischen Unternehmensnetzwerken lässt sich der Weg eines Datenpakets häufig anhand physischer Verbindungen und bekannter Netzwerkgeräte nachvollziehen. In Azure beschreibt die sichtbare Konfiguration dagegen zunächst eine logische Topologie aus Adressräumen, Subnetzen, Routen und Sicherheitsregeln. Wie diese Vorgaben innerhalb der physischen Infrastruktur umgesetzt werden, bleibt für Administrator:innen weitgehend verborgen.

Daraus ergibt sich eine grundlegende technische Frage: Wenn virtuelle Maschinen über unterschiedliche Subnetze hinweg kommunizieren, ohne dass dafür ein eigener Router bereitgestellt werden muss, welche Komponenten übernehmen dann die Weiterleitung und Verarbeitung der Datenpakete? Die Antwort führt zu den Architekturprinzipien von Software-Defined Networking und damit zu den technischen Grundlagen, auf denen Azure seine virtuellen Netzwerkfunktionen bereitstellt.

Vom klassischen Netzwerk zur softwaregesteuerten Infrastruktur

Eine wesentliche Grundlage moderner Cloud-Netzwerke bildet das Software-Defined Networking (SDN). Dieser Architekturansatz ermöglicht es, Netzwerkfunktionen softwaregesteuert und weitgehend unabhängig von einzelnen physischen Geräten bereitzustellen. An die Stelle einer ausschließlich gerätebezogenen Konfiguration treten programmierbare Steuerungsmechanismen, mit denen sich auch umfangreiche und dynamische Netzwerkinfrastrukturen automatisiert verwalten lassen.

Microsoft setzt in Azure auf entsprechende Architekturprinzipien und Technologien. Dazu gehört die Virtual Filtering Platform (VFP), die Microsoft als programmierbare Plattform für die Verarbeitung von Netzwerkdatenverkehr auf Virtualisierungshosts beschrieben hat. Die zugrunde liegende Architektur ermöglicht es, unterschiedliche Netzwerkfunktionen innerhalb eines gemeinsamen Datenpfads umzusetzen. Ergänzend unterstützen Technologien wie Accelerated Networking und spezialisierte Netzwerkhardware die leistungsfähige Verarbeitung des Datenverkehrs.

Damit verändert sich nicht nur die Verwaltung virtueller Netzwerke, sondern auch die technische Umsetzung ihrer Funktionen. Aufgaben, die in klassischen Unternehmensnetzwerken häufig dedizierten Geräten zugeordnet sind, können innerhalb einer Cloud-Infrastruktur auf verschiedene Software- und Hardwarekomponenten verteilt werden. Entscheidend ist deshalb das Zusammenspiel zwischen der Steuerung des Netzwerks, den logisch bereitgestellten Funktionen und der tatsächlichen Verarbeitung der Datenpakete. Wie Microsoft diese Aufgaben organisiert und technisch umsetzt, betrachten wir in den folgenden Kapiteln genauer.

Die Perspektive aus der Praxis: Was geschieht mit einem Datenpaket?

In meinen Seminaren zu Azure-Netzwerktechnologien, insbesondere zur Vorbereitung auf die Microsoft-Zertifizierung AZ-700 (Designing and Implementing Microsoft Azure Networking Solutions), begegnet mir regelmäßig eine interessante Herausforderung: Die einzelnen Azure-Dienste und ihre Konfiguration lassen sich vergleichsweise gut vermitteln. Anspruchsvoller wird es, wenn wir hinter die abstrahierte Oberfläche blicken und die zugrunde liegenden Netzwerkmechanismen untersuchen.

Ein Beispiel verdeutlicht diese Fragestellung: Zwei virtuelle Maschinen befinden sich in unterschiedlichen Subnetzen desselben Azure Virtual Networks. Sofern keine Routing- oder Sicherheitsregeln die Kommunikation verhindern, können sie miteinander kommunizieren, ohne dass Administrator:innen dafür einen eigenen Router bereitstellen müssen. Aus Sicht der klassischen Netzwerktechnik ergeben sich daraus weiterführende Fragen: Wo wird die Routingentscheidung getroffen? Welche Komponenten verarbeiten das Datenpaket? Wie werden Sicherheitsrichtlinien durchgesetzt? Und welche Rolle spielt die physische Netzwerkinfrastruktur?

Ähnliche Fragen entstehen bei VNet Peering, Azure Load Balancer, Private Endpoints oder ExpressRoute. Zwar müssen Administrator:innen nicht sämtliche internen Implementierungsdetails kennen, um diese Dienste erfolgreich einzusetzen. Ein fundiertes Verständnis der zugrunde liegenden Mechanismen hilft jedoch, Architekturentscheidungen besser nachzuvollziehen, mögliche Fehlerquellen frühzeitig zu erkennen und Kommunikationsprobleme systematisch einzugrenzen.

Zielsetzung: Die Technik hinter den Azure-Netzwerkdiensten verstehen

Dieser Beitrag betrachtet Azure Networking nicht als Sammlung einzelner Cloud-Dienste, sondern aus einer architekturorientierten Perspektive. Im Mittelpunkt steht die Frage, wie Microsoft grundlegende Netzwerkfunktionen innerhalb einer global verteilten Cloud-Infrastruktur bereitstellt und welche technischen Mechanismen hinter den abstrahierten Ressourcen stehen. Dazu betrachten wir die verschiedenen Ebenen der Azure-Netzwerkarchitektur: von der sichtbaren Konfiguration virtueller Netzwerke über die softwaregesteuerte Steuerung und Bereitstellung bis zur tatsächlichen Verarbeitung und Weiterleitung von Datenpaketen. Wo es fachlich sinnvoll ist, stellen wir Verbindungen zur klassischen Netzwerktechnik her. Dazu gehören unter anderem VLANs und Overlay-Netzwerke, Routingtabellen, Network Address Translation (NAT), Stateful Inspection und das Border Gateway Protocol (BGP).

Dabei müssen wir eine wesentliche Einschränkung berücksichtigen: Microsoft legt nicht sämtliche Implementierungsdetails seiner internen Infrastruktur offen. Deshalb unterscheiden wir konsequent zwischen öffentlich dokumentierten Technologien, technisch begründbaren Architekturzusammenhängen und nicht ausreichend belegten Implementierungsdetails. Insbesondere wissenschaftliche Veröffentlichungen von Microsoft ermöglichen interessante Einblicke in die Entwicklung der Azure-Netzwerkarchitektur, bilden jedoch nicht zwangsläufig deren aktuellen technischen Stand vollständig ab.

Unser Ziel ist es daher nicht, eine vermeintlich vollständige Darstellung der internen Azure-Infrastruktur zu liefern. Vielmehr wollen wir die Abstraktion der Cloud dort auflösen, wo öffentlich verfügbare Informationen und grundlegende Netzwerkprinzipien eine fundierte technische Einordnung ermöglichen. Denn wer versteht, wie Netzwerkfunktionen hinter den virtuellen Ressourcen umgesetzt werden, kann auch die Möglichkeiten und Grenzen moderner Cloud-Netzwerke besser beurteilen.

Software-Defined Networking – Das architektonische Fundament von Azure

In klassischen Unternehmensnetzwerken sind Steuerungs- und Weiterleitungsfunktionen häufig eng mit den eingesetzten Netzwerkgeräten verbunden. Switches und Router verarbeiten Datenpakete auf Grundlage ihrer Konfigurationen und Weiterleitungsinformationen. Änderungen an Kommunikationswegen oder Sicherheitsrichtlinien können deshalb Anpassungen an mehreren Komponenten erfordern. In großen Rechenzentren mit zahlreichen virtuellen Maschinen und dynamischen Workloads stößt eine überwiegend gerätebezogene Administration jedoch an praktische Grenzen. Netzwerkverbindungen müssen automatisiert bereitgestellt, Richtlinien konsistent umgesetzt und Ressourcen unabhängig von ihrer physischen Platzierung miteinander verbunden werden.

Für eine Hyperscale-Plattform wie Microsoft Azure ist diese Flexibilität eine grundlegende Voraussetzung. Wenn Administrator:innen virtuelle Maschinen bereitstellen, Subnetze konfigurieren oder Netzwerkregeln verändern, darf die Umsetzung nicht von manuellen Eingriffen an den beteiligten physischen Netzwerkgeräten abhängen. Stattdessen muss die Infrastruktur logische Netzwerkvorgaben automatisiert in wirksame Konfigurationen und Weiterleitungsregeln überführen können.

Hier setzt Software-Defined Networking (SDN) an. Der Architekturansatz ermöglicht es, Netzwerkfunktionen programmatisch zu steuern und ihre Umsetzung von der Konfiguration einzelner physischer Geräte zu entkoppeln. Die grundlegenden Aufgaben eines Netzwerks bleiben dabei unverändert. Was sich verändert, ist die Organisation ihrer Steuerung und technischen Umsetzung.

Software-Defined Networking: Steuerung und Weiterleitung trennen

Das zentrale Architekturprinzip von Software-Defined Networking (SDN) besteht in der logischen Entkopplung von Netzwerksteuerung und Paketweiterleitung. Bereits klassische Switches und Router unterscheiden zwischen diesen Funktionen. Allerdings sind Steuerungs- und Weiterleitungsebene dort häufig innerhalb desselben Geräts implementiert. Die Steuerungsebene ermittelt beispielsweise erreichbare Netzwerke und geeignete Weiterleitungswege, während die Weiterleitungsebene eingehende Pakete anhand der daraus abgeleiteten Informationen verarbeitet.

SDN ermöglicht es, diese Funktionen über einzelne Geräte hinaus zu organisieren. Softwarebasierte Steuerungskomponenten verwalten Netzwerkzustände und Richtlinien und stellen den beteiligten Verarbeitungskomponenten die erforderlichen Informationen über programmierbare Schnittstellen bereit.

Die folgende Abbildung verdeutlicht diesen architektonischen Unterschied und zeigt die wesentlichen Funktionsebenen beider Ansätze.

Dabei unterscheiden wir drei funktionale Ebenen:

• Management Plane (Verwaltungsebene): Sie ermöglicht die Konfiguration, Überwachung und Automatisierung der Netzwerkinfrastruktur.
• Control Plane (Steuerungsebene): Sie verwaltet Netzwerkzustände und ermittelt beziehungsweise koordiniert die erforderlichen Weiterleitungsinformationen.
• Data Plane (Weiterleitungsebene): Sie verarbeitet den tatsächlichen Datenverkehr anhand der bereitgestellten Weiterleitungs- und Filterregeln.

Die logische Entkopplung bedeutet allerdings nicht, dass sämtliche Entscheidungen durch einen einzigen zentralen Controller getroffen werden müssen. Gerade Hyperscale-Infrastrukturen benötigen skalierbare und ausfallsichere Steuerungsarchitekturen, die auch verteilt implementiert sein können. Entscheidend ist somit nicht die Zentralisierung der Netzwerksteuerung, sondern die programmatische Verwaltung von Netzwerkfunktionen und ihre koordinierte Umsetzung innerhalb einer verteilten Infrastruktur.

Von der Azure-Konfiguration zur tatsächlichen Paketverarbeitung

Wie sich die Prinzipien von Software-Defined Networking in Microsoft Azure wiederfinden, lässt sich am Beispiel eines virtuellen Netzwerks nachvollziehen. Administrator:innen erstellen ein Virtual Network, definieren Subnetze und konfigurieren gegebenenfalls Network Security Groups oder benutzerdefinierte Routen. Diese Einstellungen beschreiben die gewünschte logische Netzwerkstruktur und legen fest, welche Adressräume, Weiterleitungswege und Kommunikationsregeln gelten sollen.

Die Konfiguration erfolgt über die Management Plane, beispielsweise mithilfe des Azure-Portals, der Azure CLI oder von Infrastructure-as-Code-Werkzeugen. Damit die definierten Vorgaben wirksam werden, muss Azure sie innerhalb seiner Netzwerkinfrastruktur umsetzen. Dazu übernehmen softwarebasierte Steuerungssysteme Aufgaben der Control Plane, indem sie Netzwerkzustände koordinieren und die erforderlichen Informationen für die beteiligten Verarbeitungskomponenten bereitstellen. Die eigentliche Kommunikation erfolgt anschließend über die Data Plane. Dort werden Datenpakete anhand der wirksamen Weiterleitungs- und Filterregeln verarbeitet. Entsprechende Funktionen können unter anderem auf den Virtualisierungshosts ausgeführt werden.

Einen Einblick in diese Architektur bietet die von Microsoft beschriebene Virtual Filtering Platform (VFP). Sie ermöglicht die programmierbare Verarbeitung unterschiedlicher Netzwerkfunktionen innerhalb eines gemeinsamen Datenpfads. Wie diese Funktionen technisch umgesetzt werden und welche Rolle hardwarebeschleunigte Verarbeitung übernimmt, untersuchen wir im folgenden Kapitel.

Warum SDN mehr als eine zentrale Verwaltung ist

Software-Defined Networking wird gelegentlich mit der zentralen Verwaltung von Netzwerkgeräten gleichgesetzt. Eine gemeinsame Konfigurationsoberfläche allein macht jedoch noch keine SDN-Architektur aus. Entscheidend ist vielmehr, dass Netzwerkzustände und Richtlinien programmatisch beschrieben und innerhalb einer verteilten Infrastruktur automatisiert umgesetzt werden können. Für Microsoft Azure bedeutet dies, dass logische Netzwerkfunktionen nicht unmittelbar an die physische Platzierung einzelner Workloads gebunden sein dürfen. Virtuelle Maschinen müssen entsprechend ihrer Netzwerkkonfiguration kommunizieren können, während Sicherheitsrichtlinien und Mandantengrenzen unabhängig von den gemeinsam genutzten Infrastrukturkomponenten wirksam bleiben. Änderungen an diesen Vorgaben müssen zuverlässig übernommen werden, ohne dass Administrator:innen die beteiligten physischen Geräte einzeln konfigurieren müssen.

Daraus ergeben sich Anforderungen an die Steuerung und Verarbeitung des Datenverkehrs. Netzwerkzustände müssen konsistent verwaltet, erforderliche Regeln an den jeweiligen Verarbeitungspunkten umgesetzt und Ausfälle einzelner Komponenten möglichst abgefangen werden. Dabei bleibt die physische Netzwerkinfrastruktur unverzichtbar: Sie stellt die Transportkapazität bereit und beeinflusst weiterhin Latenz, Durchsatz und Verfügbarkeit. Die eigentliche Besonderheit liegt somit im Zusammenspiel zwischen logisch definierten Netzwerkfunktionen und ihrer verteilten technischen Umsetzung. Wie dieses Zusammenspiel auf einem Azure-Virtualisierungshost aussieht, welche Aufgaben programmierbare Datenpfade übernehmen und welche Rolle hardwarebeschleunigte Netzwerkverarbeitung dabei spielt, untersuchen wir im folgenden Kapitel.

Der Azure-Host als Netzwerkknoten – Virtual Filtering Platform und Accelerated Networking

In klassischen Unternehmensnetzwerken übernehmen Switches, Router und Firewalls unterschiedliche Aufgaben bei der Verarbeitung und Weiterleitung von Datenpaketen. In virtualisierten Rechenzentren können entsprechende Netzwerkfunktionen jedoch auch auf den physischen Hosts ausgeführt werden, auf denen virtuelle Maschinen betrieben werden. Neben dem Hypervisor spielen dabei virtuelle Netzwerkschnittstellen, virtuelle Switches und weitere Komponenten des Host-Datenpfads eine wichtige Rolle. Dieses Architekturprinzip ist auch für Microsoft Azure von grundlegender Bedeutung. Die Netzwerkschnittstelle einer virtuellen Maschine ist in eine virtualisierte Infrastruktur eingebunden, deren technische Umsetzung Microsoft verwaltet. Netzwerkfunktionen müssen deshalb nicht ausschließlich auf dedizierten physischen Geräten ausgeführt werden. Bestimmte Verarbeitungsschritte können bereits auf dem Virtualisierungshost erfolgen, bevor ein Datenpaket über die physische Netzwerkinfrastruktur transportiert wird.

Dazu gehören beispielsweise die Durchsetzung von Sicherheitsrichtlinien, die Verarbeitung virtueller Netzwerkstrukturen und bestimmte Formen der Adressübersetzung. Welche Komponenten diese Aufgaben tatsächlich übernehmen, hängt von der jeweiligen Architektur und den eingesetzten Technologien ab. Für unser Verständnis sind insbesondere zwei Entwicklungen relevant: die programmierbare Paketverarbeitung innerhalb des Host-Datenpfads und die zunehmende Beschleunigung ausgewählter Netzwerkfunktionen durch spezialisierte Hardware. Beide Ansätze bilden die Grundlage für die nachfolgende Betrachtung der Virtual Filtering Platform und von Accelerated Networking.

Der virtuelle Switch als Schnittstelle zwischen virtueller Maschine und Netzwerk

Damit eine virtuelle Maschine mit anderen Systemen kommunizieren kann, benötigt sie eine virtuelle Netzwerkschnittstelle (Virtual Network Interface Card, vNIC). Diese stellt dem Gastbetriebssystem eine Netzwerkanbindung bereit, über die es Ethernet-Frames senden und empfangen kann. Die virtuelle Netzwerkschnittstelle ist dabei nicht unmittelbar mit einem physischen Switch verbunden, sondern in den Netzwerkdatenpfad des Virtualisierungshosts eingebunden.

In einer klassischen Hyper-V-Umgebung übernimmt der virtuelle Switch die Vermittlung zwischen den angeschlossenen virtuellen Netzwerkschnittstellen und gegebenenfalls der physischen Netzwerkanbindung. Er ermöglicht sowohl die Kommunikation zwischen virtuellen Maschinen als auch den Übergang zur weiteren Netzwerkinfrastruktur. Die von Microsoft veröffentlichten Forschungsarbeiten zur Azure-Netzwerkarchitektur beschreiben ebenfalls hostbasierte Netzwerkkomponenten. Deren konkrete Implementierung hat sich allerdings über verschiedene Plattform- und Hardwaregenerationen weiterentwickelt.

Entscheidend ist, dass der Host-Datenpfad weit mehr als eine einfache Verbindung zum physischen Netzwerk bereitstellen kann. Ein ausgehendes Datenpaket lässt sich bereits hier anhand von Sicherheitsrichtlinien prüfen, einer virtuellen Netzwerkstruktur zuordnen oder für die weitere Übertragung vorbereiten. Der Azure-Host wird damit selbst zu einem Verarbeitungspunkt innerhalb der Netzwerkarchitektur. Welche Funktionen dort softwarebasiert ausgeführt werden und wie sich unterschiedliche Verarbeitungsschritte miteinander kombinieren lassen, zeigt die von Microsoft beschriebene Virtual Filtering Platform.

Die Virtual Filtering Platform: Programmierbare Paketverarbeitung

Einen besonders aufschlussreichen Einblick in die Netzwerkarchitektur von Microsoft Azure bietet die Virtual Filtering Platform (VFP). Microsoft beschrieb diese Technologie 2017 in einer wissenschaftlichen Veröffentlichung. Ihr Ziel bestand darin, unterschiedliche virtuelle Netzwerkfunktionen innerhalb eines gemeinsamen, programmierbaren Datenpfads bereitzustellen. Dazu organisiert VFP die Paketverarbeitung in einer mehrstufigen Pipeline. Anstatt für jede Netzwerkfunktion einen eigenständigen Verarbeitungspfad vorzusehen, lassen sich unterschiedliche Aufgaben innerhalb einer gemeinsamen Architektur kombinieren. Dazu gehören beispielsweise Paketfilterung, Netzwerkvirtualisierung, Adressübersetzung und Lastverteilung.

Die einzelnen Verarbeitungsschritte basieren auf Regeln, die bestimmte Eigenschaften eines Datenpakets oder einer Verbindung auswerten und entsprechende Aktionen festlegen. Dieses Prinzip wird als Match-Action-Verarbeitung bezeichnet: Stimmen die Merkmale eines Pakets mit einer Regel überein, wird die zugehörige Aktion angewendet. Wie solche Regeln aufgebaut sind und innerhalb der Pipeline zusammenwirken, betrachten wir im nächsten Abschnitt.

Die Bedeutung von VFP liegt damit weniger in einer einzelnen Netzwerkfunktion als in der programmierbaren Kombination unterschiedlicher Funktionen innerhalb des Datenpfads. Allerdings beschreibt die Forschungsarbeit eine konkrete Entwicklungsstufe der Azure-Infrastruktur. Sie liefert wertvolle Einblicke in deren Architekturprinzipien, erlaubt jedoch keine vollständigen Aussagen über die Implementierung sämtlicher heutiger Azure-Netzwerkdatenpfade.

Flow Tables und Match-Action-Regeln

Wie die Virtual Filtering Platform Datenpakete verarbeitet, lässt sich anhand einer vereinfachten TCP-Verbindung zwischen zwei virtuellen Maschinen nachvollziehen. Ein ausgehendes Paket enthält Informationen, anhand derer der Datenpfad passende Verarbeitungsregeln bestimmen kann. Dazu gehören Quell- und Ziel-IP-Adresse, Transportprotokoll sowie Quell- und Zielport. Gemeinsam bilden diese fünf Merkmale das sogenannte 5-Tupel eines Datenflusses.

Die folgende Abbildung veranschaulicht diese Merkmale anhand einer konkreten Verbindung und zeigt, wie unterschiedliche Verarbeitungsschritte innerhalb eines programmierbaren Datenpfads zusammenwirken können.

Die VFP organisiert Verarbeitungsregeln in Tabellen, die innerhalb einer mehrstufigen Pipeline ausgewertet werden. Eine Match-Action-Regel besteht dabei aus zwei grundlegenden Elementen:

• Match: Welche Merkmale eines Pakets oder einer Verbindung müssen mit der Regel übereinstimmen?
• Action: Welche Verarbeitung wird bei einer Übereinstimmung ausgeführt?

Abhängig von der jeweiligen Netzwerkfunktion kann eine Aktion beispielsweise darin bestehen, ein Paket weiterzuleiten, zu verwerfen oder bestimmte Headerinformationen zu verändern. Die Verarbeitung kann dabei mehrere aufeinander abgestimmte Regelbereiche umfassen.

Für bereits bekannte Verbindungen können zudem zwischengespeicherte Verarbeitungsinformationen genutzt werden. Dadurch müssen nachfolgende Pakete nicht zwangsläufig sämtliche Regelprüfungen erneut durchlaufen. Welche Optimierungen tatsächlich greifen, hängt von der jeweiligen Implementierung und dem Verbindungszustand ab. Das Zusammenspiel aus programmierbaren Regeln und zustandsbezogener Verarbeitung ermöglicht es, unterschiedliche Netzwerkfunktionen flexibel bereitzustellen, ohne für jedes Paket sämtliche Entscheidungen vollständig neu treffen zu müssen.

Warum softwarebasierte Paketverarbeitung allein nicht ausreicht

Die softwarebasierte Verarbeitung von Netzwerkpaketen bietet eine hohe Flexibilität. Allerdings beanspruchen Paketklassifizierung, Filterung und weitere Verarbeitungsschritte Rechenressourcen des Virtualisierungshosts. Mit steigenden Netzwerkgeschwindigkeiten und einer wachsenden Anzahl paralleler Verbindungen kann daraus eine erhebliche Belastung entstehen. Prozessorzeit, die für Netzwerkfunktionen benötigt wird, steht nicht gleichzeitig für andere Aufgaben zur Verfügung.

Dabei ist zwischen Bandbreite und Paketverarbeitungsrate zu unterscheiden. Während die Bandbreite beschreibt, welche Datenmenge innerhalb einer bestimmten Zeit übertragen wird, gibt die Paketverarbeitungsrate an, wie viele einzelne Pakete pro Sekunde verarbeitet werden müssen. Viele kleine Pakete können bei identischem Datenvolumen einen deutlich höheren Verarbeitungsaufwand verursachen als wenige große Pakete. Für Hyperscale-Infrastrukturen entsteht daraus eine grundlegende Herausforderung: Netzwerkfunktionen müssen programmierbar bleiben, gleichzeitig aber mit möglichst geringem CPU-Aufwand und niedriger Latenz ausgeführt werden können.

Einen wichtigen Entwicklungsschritt dokumentierte Microsoft 2018 mit AccelNet in einer wissenschaftlichen Veröffentlichung. Die beschriebene Architektur kombiniert softwaredefinierte Netzwerkfunktionen mit hardwarebeschleunigter Paketverarbeitung. Ausgewählte Verarbeitungsschritte werden dabei auf programmierbare Netzwerkhardware ausgelagert, um die Host-Prozessoren zu entlasten. Das Ziel besteht somit nicht darin, Software durch Hardware zu ersetzen, sondern beide so zu kombinieren, dass Flexibilität und Leistungsfähigkeit erhalten bleiben.

Accelerated Networking und SR-IOV

Mit Accelerated Networking ermöglicht Microsoft Azure unterstützten virtuellen Maschinen eine leistungsfähigere Netzwerkanbindung. Eine wesentliche technische Grundlage bildet dabei Single Root I/O Virtualization (SR-IOV). Diese PCIe-Technologie erlaubt es geeigneten Netzwerkadaptern, neben einer physischen Funktion (Physical Function, PF) mehrere virtuelle Funktionen (Virtual Functions, VFs) bereitzustellen. Eine solche virtuelle Funktion kann einer virtuellen Maschine zugeordnet werden und ihr einen direkteren Zugriff auf die Netzwerkhardware ermöglichen. Dadurch lassen sich Teile des herkömmlichen softwarebasierten Netzwerkdatenpfads umgehen. Das kann die Latenz verringern, die Paketverarbeitungsleistung erhöhen und die CPU-Belastung reduzieren.

Entscheidend ist jedoch, dass ein beschleunigter Datenpfad nicht mit dem Verzicht auf virtuelle Netzwerkfunktionen gleichzusetzen ist. Auch bei aktiviertem Accelerated Networking müssen beispielsweise Sicherheitsrichtlinien und die logische Trennung virtueller Netzwerke weiterhin wirksam bleiben. In den von Microsoft dokumentierten Beschleunigungsarchitekturen können dafür ausgewählte Verarbeitungsschritte auf spezialisierte Netzwerkhardware ausgelagert werden. SR-IOV beschreibt somit zunächst den Mechanismus, mit dem virtuelle Maschinen effizienter auf Netzwerkhardware zugreifen können. Wie Netzwerkvirtualisierung, Paketfilterung und weitere Funktionen innerhalb dieses beschleunigten Datenpfads umgesetzt werden, hängt von der jeweiligen Azure-Plattformarchitektur ab.

SmartNICs, MANA und Azure Boost

Die Weiterentwicklung der Azure-Netzwerkarchitektur zeigt sich besonders deutlich am Einsatz spezialisierter Netzwerkhardware. SmartNICs erweitern klassische Netzwerkadapter um programmierbare Verarbeitungskapazitäten. Dadurch lassen sich ausgewählte Netzwerkfunktionen direkt auf der Netzwerkkarte ausführen, anstatt sämtliche Verarbeitungsschritte durch die allgemeinen Prozessoren des Virtualisierungshosts durchführen zu lassen. Microsoft dokumentierte diesen Ansatz bereits 2018 im Zusammenhang mit AccelNet.

Mit dem Microsoft Azure Network Adapter (MANA) hat Microsoft außerdem eine eigene Netzwerkadapterarchitektur entwickelt, die bei unterstützten Azure-VMs für die Netzwerkanbindung und hardwarebeschleunigte Datenübertragung eingesetzt wird. MANA umfasst dabei auch die Integration mit entsprechenden Treibern innerhalb des Gastbetriebssystems. Eine umfassendere Entwicklung stellt Azure Boost dar. Darunter fasst Microsoft Technologien zusammen, mit denen bestimmte Virtualisierungsaufgaben, insbesondere im Netzwerk- und Speicherbereich, durch spezialisierte Hardware und optimierte Softwarekomponenten übernommen werden.

Die Begriffe beschreiben somit unterschiedliche technische Ebenen: SmartNIC bezeichnet eine Klasse spezialisierter Netzwerkhardware, MANA eine Azure-spezifische Netzwerkadapterarchitektur und Azure Boost einen umfassenderen Ansatz zur Beschleunigung und Auslagerung von Infrastrukturaufgaben. Gemeinsam verdeutlichen diese Technologien, dass sich die Paketverarbeitung zunehmend auf Software und spezialisierte Hardware verteilt. Welche Komponenten im konkreten Datenpfad zusammenwirken, hängt von der eingesetzten Azure-Hostgeneration, dem VM-Typ und den unterstützten Plattformfunktionen ab.

Was diese Architektur für Azure Networking bedeutet

Die Betrachtung der Azure-Hostarchitektur zeigt, warum sich virtuelle Netzwerke nicht vollständig mit den klassischen Modellen physischer Switches und Router erklären lassen. Netzwerkfunktionen können innerhalb des softwarebasierten Host-Datenpfads, auf spezialisierter Netzwerkhardware oder durch weitere Komponenten der Infrastruktur umgesetzt werden. Welche Verarbeitungsschritte an welcher Stelle stattfinden, hängt von der jeweiligen Plattformarchitektur ab. Für Administrator:innen bleibt diese technische Verteilung weitgehend abstrahiert. Sie konfigurieren virtuelle Netzwerke, Routingvorgaben und Sicherheitsrichtlinien über die bereitgestellten Azure-Schnittstellen. Die Plattform sorgt anschließend dafür, dass diese Vorgaben innerhalb der beteiligten Infrastrukturkomponenten wirksam werden.

Gerade darin zeigt sich das Zusammenspiel von Software-Defined Networking und hardwarebeschleunigter Paketverarbeitung: Die logische Netzwerkarchitektur kann unabhängig davon verwaltet werden, welche konkreten Komponenten die erforderlichen Netzwerkfunktionen ausführen. Allerdings müssen wir zwischen öffentlich dokumentierten Architekturprinzipien und nicht offengelegten Implementierungsdetails unterscheiden. Die Forschungsarbeiten zu VFP und AccelNet ermöglichen wertvolle Einblicke in die technische Entwicklung von Azure. Sie beschreiben jedoch nicht zwangsläufig den vollständigen aktuellen Datenpfad jeder virtuellen Maschine.

Damit verfügen wir über eine wesentliche Grundlage für die weitere Betrachtung: Der Azure-Host ist nicht nur Ausführungsort virtueller Maschinen, sondern kann selbst wichtige Aufgaben der Netzwerkverarbeitung übernehmen. Im nächsten Kapitel untersuchen wir, wie Azure auf dieser Infrastruktur logisch voneinander getrennte virtuelle Netzwerke und Subnetze bereitstellt und welche Rolle die physische Transportinfrastruktur dabei spielt.

Virtuelle Netzwerke – Wie Azure logische Netzwerke auf physischer Infrastruktur bereitstellt

In klassischen Unternehmensnetzwerken ist die logische Netzwerkstruktur häufig eng mit der Konfiguration physischer Switches und Router verbunden. VLANs ermöglichen die Segmentierung auf der Sicherungsschicht, während Routingfunktionen die Kommunikation zwischen unterschiedlichen IP-Netzen übernehmen. Auch wenn moderne Rechenzentrumsarchitekturen diese Zusammenhänge zunehmend abstrahieren, bleibt die zugrunde liegende physische Infrastruktur für die Datenübertragung unverzichtbar.

Microsoft Azure verfolgt bei der Bereitstellung virtueller Netzwerke einen stärker abstrahierten Ansatz. Administrator:innen definieren mit einem Azure Virtual Network (VNet) einen logischen Netzwerkbereich, legen IP-Adressräume fest und unterteilen diese bei Bedarf in Subnetze. Die Plattform übernimmt anschließend die Umsetzung dieser Vorgaben innerhalb ihrer gemeinsam genutzten Infrastruktur. Ein VNet entspricht dabei nicht einfach einem VLAN oder einem einzelnen physischen Netzwerksegment. Es bildet vielmehr einen logisch isolierten Netzwerkbereich, dessen Adressierung und Kommunikationsbeziehungen unabhängig von der konkreten Platzierung der beteiligten virtuellen Maschinen verwaltet werden können.

Um diese Architektur zu verstehen, müssen wir zwischen zwei Perspektiven unterscheiden: dem Underlay, das den physischen Transport der Datenpakete ermöglicht, und dem Overlay, das die logischen Netzwerkstrukturen darüber bereitstellt. Diese Trennung bildet die Grundlage für die folgenden Betrachtungen. Wir untersuchen, wie virtuelle Netzwerke voneinander isoliert werden, welche Bedeutung Subnetze innerhalb eines VNets besitzen und warum die Kommunikation zwischen Azure-Ressourcen nicht zwangsläufig einen klassischen, für Administrator:innen sichtbaren Router benötigt.

Underlay und Overlay – Zwei Perspektiven auf dasselbe Netzwerk

Um die Funktionsweise virtueller Netzwerke zu verstehen, müssen wir zwischen der physischen Transportinfrastruktur und den darüber bereitgestellten logischen Netzwerkstrukturen unterscheiden. In der Netzwerkvirtualisierung werden diese beiden Perspektiven als Underlay und Overlay bezeichnet.

Das Underlay bildet die zugrunde liegende Netzwerkinfrastruktur. Dazu gehören physische Switches, Router, Übertragungsverbindungen und die erforderlichen Routingmechanismen. Seine Aufgabe besteht darin, Datenpakete zwischen den beteiligten Infrastrukturkomponenten zu transportieren.

Das Overlay stellt darüber logische Netzwerkstrukturen bereit. Virtuelle Maschinen können dadurch demselben virtuellen Netzwerk angehören, obwohl sie auf unterschiedlichen physischen Hosts ausgeführt werden. Die logische Netzwerkzugehörigkeit muss somit nicht der physischen Topologie entsprechen.

Die folgende Abbildung veranschaulicht dieses Zusammenspiel anhand mehrerer virtueller Netzwerke, die eine gemeinsame Transportinfrastruktur nutzen. Zusätzlich zeigt sie exemplarisch, wie ein Datenpaket für die Übertragung über das Underlay gekapselt werden kann.

Bei einer solchen Kapselung erhält das ursprüngliche Paket zusätzliche Headerinformationen, anhand derer es über die physische Infrastruktur zum vorgesehenen Ziel transportiert werden kann. Verfahren wie VXLAN, Geneve oder NVGRE verfolgen dieses grundlegende Prinzip, unterscheiden sich jedoch in ihrer technischen Umsetzung.

Für Microsoft Azure ist vor allem die architektonische Trennung entscheidend: Administrator:innen konfigurieren virtuelle Netzwerke, Subnetze und IP-Adressen, während die Plattform deren Umsetzung innerhalb ihrer Infrastruktur übernimmt. Die konkreten internen Transportmechanismen können dabei von der jeweiligen Azure-Architektur abhängen. Underlay und Overlay beschreiben somit keine konkurrierenden Netzwerke, sondern zwei miteinander verbundene Perspektiven derselben Infrastruktur.

Azure Virtual Networks – Logische Isolation statt physischer Segmentierung

Ein Azure Virtual Network (VNet) bildet einen logisch isolierten Netzwerkbereich innerhalb der Azure-Infrastruktur. Administrator:innen definieren dafür einen oder mehrere IP-Adressräume, aus denen anschließend Subnetze gebildet werden können. Ressourcen innerhalb des VNets erhalten eine entsprechende Netzwerkanbindung und können unter Berücksichtigung der geltenden Routing- und Sicherheitsregeln miteinander kommunizieren. Anders als bei einer klassischen VLAN-Segmentierung ist diese logische Netzwerkstruktur nicht unmittelbar an bestimmte physische Switchports oder eine einzelne Layer-2-Broadcast-Domäne gebunden. Die beteiligten virtuellen Maschinen können auf unterschiedlichen Virtualisierungshosts ausgeführt werden, ohne dass Administrator:innen deren physische Verbindungen konfigurieren müssen.

Ein weiterer wichtiger Aspekt ist die Mandantenisolation. Unterschiedliche virtuelle Netzwerke können unabhängig voneinander verwaltet werden und grundsätzlich auch überlappende private IP-Adressräume verwenden. Die Trennung ihrer Netzwerkzustände und Kommunikationsbeziehungen wird durch die Azure-Infrastruktur umgesetzt. Diese Isolation bedeutet allerdings nicht, dass zwischen virtuellen Netzwerken grundsätzlich keine Kommunikation möglich wäre. Über ausdrücklich konfigurierte Verbindungen, beispielsweise VNet-Peering oder geeignete Gateway-Architekturen, können unterschiedliche Netzwerkbereiche miteinander verbunden werden. Ein VNet ist damit weniger als virtuelles Abbild eines physischen Switches zu verstehen, sondern als logischer Netzwerkbereich, dessen Adressierung, Erreichbarkeit und Isolation durch die Plattform bereitgestellt werden.

Subnetze in Azure – Adressierung und logische Struktur

Innerhalb eines Azure Virtual Networks ermöglichen Subnetze die logische Unterteilung des definierten IP-Adressraums. Jedes Subnetz erhält einen eigenen, nicht überlappenden Adressbereich, der vollständig innerhalb des VNets liegen muss. Administrator:innen können dadurch unterschiedliche Ressourcen und Workloads strukturiert voneinander abgrenzen. Im Unterschied zu klassischen Unternehmensnetzwerken erfordert die Kommunikation zwischen Subnetzen desselben VNets nicht die Bereitstellung eines eigenen Routers. Azure stellt dafür standardmäßig entsprechende Systemrouten bereit. So können virtuelle Maschinen unterschiedlicher Subnetze grundsätzlich miteinander kommunizieren, sofern keine Sicherheitsrichtlinien oder abweichenden Routingvorgaben dies verhindern.

Subnetze dienen außerdem als Bezugspunkt für weitere Netzwerkkonfigurationen. Beispielsweise lassen sich Network Security Groups zuordnen oder benutzerdefinierte Routingtabellen mit einem Subnetz verknüpfen. Damit beeinflussen Administrator:innen, welche Kommunikationsbeziehungen zulässig sind und wie ausgehender Datenverkehr weitergeleitet werden soll.

Dabei ist eine wichtige Unterscheidung zu beachten: Ein Subnetz stellt für sich genommen keine Sicherheitsgrenze dar. Die gewünschte Segmentierung muss durch geeignete Sicherheitsrichtlinien und gegebenenfalls weitere Netzwerkfunktionen umgesetzt werden. Azure-Subnetze verbinden somit die logische Strukturierung eines IP-Adressraums mit den Möglichkeiten einer softwaregesteuerten Netzwerkarchitektur.

Wie Datenpakete zwischen virtuellen Maschinen transportiert werden

Betrachten wir zwei virtuelle Maschinen, die sich innerhalb desselben Azure Virtual Networks befinden, jedoch auf unterschiedlichen physischen Hosts ausgeführt werden. Eine Anwendung auf der ersten virtuellen Maschine sendet ein IP-Paket an die private Adresse der zweiten Maschine. Aus Sicht des Gastbetriebssystems handelt es sich zunächst um gewöhnliche IP-Kommunikation. Das Paket gelangt über die virtuelle Netzwerkschnittstelle in den Netzwerkdatenpfad der Azure-Infrastruktur. Dort können die geltenden Weiterleitungs- und Sicherheitsvorgaben ausgewertet werden. Anschließend muss die Plattform dafür sorgen, dass der Datenverkehr den zuständigen Zielhost erreicht.

Die physische Transportinfrastruktur benötigt dafür nicht zwangsläufig Kenntnis von sämtlichen privaten IP-Adressen der virtuellen Maschinen. In einer Overlay-Architektur kann die Zuordnung zwischen logischen Endpunkten und physischen Transportzielen durch zusätzliche Virtualisierungsinformationen erfolgen. Wie Azure diese Zuordnung im Einzelnen umsetzt, hängt von der jeweiligen Plattformarchitektur ab. Am Zielhost wird das Paket dem vorgesehenen virtuellen Netzwerkendpunkt zugeführt und schließlich über die virtuelle Netzwerkschnittstelle an die empfangende Maschine übergeben. Für die beteiligten Gastbetriebssysteme bleibt die physische Platzierung weitgehend transparent. Die Kommunikation richtet sich nach der logischen Netzwerkkonfiguration, während Azure den erforderlichen Transport innerhalb seiner Infrastruktur realisiert.

Vom klassischen Netzwerkmodell zur Azure-Netzwerkarchitektur

Wer aus der klassischen Netzwerkadministration kommt, versucht häufig, vertraute Komponenten wie Switches, VLANs und Router unmittelbar in der Azure-Architektur wiederzufinden. Diese Denkweise hilft beim Einstieg, stößt jedoch dort an Grenzen, wo die Cloud physische Netzwerkfunktionen abstrahiert.

Die folgende Abbildung stellt deshalb vergleichbare Aufgaben klassischer Netzwerke und der Azure-Netzwerkarchitektur gegenüber. Dabei handelt es sich nicht um technisch identische Komponenten, sondern um unterschiedliche Ansätze zur Umsetzung grundlegender Netzwerkfunktionen.

Während VLANs beispielsweise eine Segmentierung auf Layer 2 ermöglichen, bildet ein Azure Virtual Network einen logisch isolierten Netzwerkbereich, der mehrere IP-Subnetze umfassen kann. Auch die Weiterleitung zwischen Subnetzen erfordert in Azure nicht zwangsläufig einen eigenen Router: Die Plattform stellt entsprechende Routingfunktionen bereit.

Die logische Netzwerktopologie lässt dabei keine unmittelbaren Rückschlüsse auf die physische Platzierung der beteiligten Ressourcen oder den tatsächlichen Paketweg zu. Für Administrator:innen verändert dies insbesondere die Fehlersuche. Statt physische Switchports und Routerverbindungen nachzuvollziehen, untersuchen sie beispielsweise Azure-Routen, Sicherheitsregeln und die bereitgestellten Diagnoseinformationen.

Die physische Infrastruktur bleibt dennoch unverzichtbar. Ihre Kapazität und Verfügbarkeit beeinflussen weiterhin die Netzwerkkommunikation. Die klassischen Netzwerkprinzipien gelten somit auch in Azure. Was sich verändert, ist die Art, wie ihre Funktionen organisiert, bereitgestellt und von der zugrunde liegenden physischen Infrastruktur abstrahiert werden.

Routing ohne sichtbare Router – Wie Azure Weiterleitungsentscheidungen trifft

In klassischen IP-Netzwerken übernehmen Router und Layer-3-Switches die Weiterleitung von Datenpaketen zwischen unterschiedlichen Netzwerken. Ihre Routingtabellen enthalten Informationen darüber, welche Zielnetze über welche Weiterleitungswege erreichbar sind. Anhand dieser Informationen bestimmen die Geräte, wie eingehende Pakete verarbeitet werden sollen. Auch Microsoft Azure benötigt entsprechende Routingmechanismen. Virtuelle Maschinen kommunizieren über Subnetzgrenzen hinweg, erreichen Ressourcen in anderen virtuellen Netzwerken oder tauschen Daten mit lokalen Unternehmensnetzen aus. Dafür muss die Plattform entscheiden, an welchen nächsten Verarbeitungspunkt ein Paket weitergeleitet werden soll.

Der Unterschied zur klassischen Netzwerkadministration liegt darin, dass die beteiligten Routingfunktionen nicht zwangsläufig als eigenständige Netzwerkgeräte sichtbar sind. Azure stellt grundlegende Weiterleitungsinformationen automatisch bereit und ermöglicht Administrator:innen, bestimmte Routingentscheidungen durch eigene Konfigurationen zu beeinflussen. Damit begegnen uns vertraute Konzepte in einer anderen technischen Umgebung: IP-Präfixe, Routingtabellen, Next Hops und die Auswahl passender Weiterleitungsregeln bleiben relevant. Ihre Umsetzung erfolgt jedoch innerhalb einer softwaregesteuerten und verteilten Infrastruktur. Routing verschwindet in Azure also nicht. Es wird als Plattformfunktion bereitgestellt, deren logische Konfiguration von der konkreten physischen Paketweiterleitung abstrahiert ist.

Systemrouten – Welche Weiterleitungsinformationen Azure automatisch bereitstellt

Bereits bei der Erstellung eines Azure Virtual Networks richtet die Plattform grundlegende Systemrouten ein. Diese ermöglichen die Weiterleitung von Datenverkehr, ohne dass Administrator:innen zunächst eigene Routingtabellen konfigurieren müssen. Eine wichtige Systemroute umfasst den Adressraum des jeweiligen VNets. Sie verwendet den Next-Hop-Typ Virtual Network und ermöglicht damit grundsätzlich die Kommunikation zwischen den zugehörigen Subnetzen. Voraussetzung ist, dass keine abweichenden Routingvorgaben oder Sicherheitsrichtlinien den Datenverkehr verhindern.

Azure stellt außerdem weitere Standardrouten bereit. Dazu gehören eine Route für Ziele außerhalb spezifischerer Adressbereiche sowie Routen, über die bestimmte private Adressbereiche standardmäßig verworfen werden. Werden zusätzliche Netzwerkfunktionen wie VNet-Peering oder ein Virtual Network Gateway eingerichtet, können weitere Systemrouten hinzukommen. Jede dieser Routen beschreibt einen Zieladressbereich und einen Next-Hop-Typ. Dieser legt fest, wie Azure den entsprechenden Datenverkehr behandeln soll. Dabei muss der nächste Weiterleitungspunkt nicht als eigenständiges Netzwerkgerät sichtbar sein.

Systemrouten lassen sich nicht unmittelbar bearbeiten oder löschen. Bestimmte Weiterleitungsentscheidungen können Administrator:innen jedoch durch benutzerdefinierte Routen beeinflussen. Azure stellt damit bereits eine funktionsfähige Routinggrundlage bereit, bevor Administrator:innen eigene Routingregeln definieren.

User Defined Routes – Wenn Administrator:innen den Paketweg beeinflussen

Nicht jede Netzwerkarchitektur lässt sich allein mit den automatisch bereitgestellten Systemrouten umsetzen. In komplexeren Umgebungen kann es beispielsweise erforderlich sein, Datenverkehr gezielt über eine Firewall oder eine andere Netzwerkkomponente zu führen. Dafür stellt Azure User Defined Routes (UDRs) bereit. Administrator:innen erstellen eigene Routingtabellen, definieren darin Zieladressbereiche und legen fest, welcher Next-Hop-Typ für den entsprechenden Datenverkehr verwendet werden soll.

Eine solche Routingtabelle wird einem oder mehreren Subnetzen zugeordnet. Für den ausgehenden Datenverkehr der dort angebundenen Ressourcen berücksichtigt Azure anschließend die wirksamen Routen. Dabei können benutzerdefinierte Einträge bestimmte Systemrouten übersteuern. Ein typisches Beispiel ist die Weiterleitung des Datenverkehrs aus einem Anwendungssubnetz an eine zentrale Firewall. Dazu kann eine UDR mit dem Next-Hop-Typ Virtual Appliance und der privaten IP-Adresse der Firewall eingerichtet werden. Auch eine Standardroute für 0.0.0.0/0 lässt sich entsprechend konfigurieren, um geeigneten ausgehenden Datenverkehr über einen festgelegten Verarbeitungspunkt zu führen. Dieses Prinzip wird häufig als Forced Tunneling bezeichnet. UDRs verändern somit nicht die physische Netzwerktopologie, sondern beeinflussen die logischen Weiterleitungsentscheidungen der Azure-Infrastruktur.

Wie Azure die passende Route auswählt

Sobald mehrere Routen für eine Zieladresse infrage kommen, muss Azure entscheiden, welche davon verwendet wird. Das grundlegende Auswahlverfahren kennen wir bereits aus klassischen IP-Netzwerken: Longest Prefix Match. Dabei wird zunächst die Route mit dem spezifischsten passenden Zielpräfix bevorzugt. Existieren beispielsweise Routen für 10.0.0.0/16 und 10.0.1.0/24, wird für ein Paket an 10.0.1.20 die spezifischere /24-Route ausgewählt. Sie beschreibt einen kleineren Adressbereich und besitzt deshalb Vorrang vor der allgemeineren Route.

Die folgende Abbildung veranschaulicht diesen Auswahlprozess anhand einer Verbindung zwischen zwei virtuellen Maschinen. Sie zeigt außerdem, wie Azure Routinginformationen unterschiedlicher Herkunft berücksichtigt und die ausgewählte Route anschließend im Datenpfad umsetzt.

Neben automatisch bereitgestellten Systemrouten berücksichtigt Azure auch benutzerdefinierte Routen (User Defined Routes, UDRs) sowie gegebenenfalls dynamisch über BGP bereitgestellte Routinginformationen.

Existieren mehrere passende Routen mit identischem Zielpräfix, gilt grundsätzlich folgende Prioritätsreihenfolge:

1. User Defined Route (UDR): Benutzerdefinierte Routingvorgabe
2. BGP-Route: Dynamisch bereitgestellte Routinginformation
3. Systemroute: Automatisch von Azure eingerichtete Route

Diese Reihenfolge gilt allerdings nicht uneingeschränkt. Insbesondere für bestimmte Systemrouten, beispielsweise im Zusammenhang mit Service Endpoints, bestehen besondere Auswahlregeln. Im dargestellten Beispiel wird die benutzerdefinierte Route 10.0.1.0/24 ausgewählt, weil sie das spezifischste passende Zielpräfix besitzt. Ihre Herkunft als UDR ist für diese Entscheidung zunächst nicht ausschlaggebend. Erst bei konkurrierenden Routen mit identischem Präfix würde die Priorität der Routenquelle relevant.

Entscheidend bleibt die Unterscheidung zwischen logischer Routenauswahl und tatsächlicher Paketweiterleitung. Azure ermittelt anhand der wirksamen Routinginformationen den vorgesehenen Next Hop. Die technische Umsetzung erfolgt anschließend innerhalb des Azure-Datenpfads, dessen konkrete Verarbeitungskomponenten für Administrator:innen weitgehend abstrahiert bleiben.

Network Virtual Appliances – Wenn virtuelle Netzwerkgeräte in den Datenpfad eingreifen

Obwohl Azure grundlegende Routingfunktionen automatisch bereitstellt, können Netzwerkarchitekturen zusätzliche Verarbeitungskomponenten benötigen. Dazu gehören beispielsweise virtuelle Firewalls, Router oder andere spezialisierte Netzwerkdienste. Solche Systeme werden als Network Virtual Appliances (NVAs) bezeichnet. Sie übernehmen Aufgaben, die über die standardmäßige Weiterleitung innerhalb eines VNets hinausgehen oder eine gezielte Kontrolle des Datenverkehrs erfordern.

Ein typisches Einsatzszenario ist eine Hub-and-Spoke-Architektur. Mehrere virtuelle Netzwerke sind mit einem zentralen Hub verbunden, in dem eine NVA den Datenverkehr zwischen unterschiedlichen Netzwerkbereichen kontrolliert. Benutzerdefinierte Routen können dafür sorgen, dass bestimmte Pakete zunächst an diese Komponente weitergeleitet werden. Dabei ist die korrekte Konfiguration entscheidend. Eine NVA muss den vorgesehenen Datenverkehr tatsächlich weiterleiten können. Neben den Azure-Routingvorgaben sind deshalb gegebenenfalls IP-Forwarding, Routingfunktionen des Gastbetriebssystems und die Sicherheitskonfiguration der Appliance zu berücksichtigen.

Besondere Aufmerksamkeit erfordert außerdem der Rückweg. Verlaufen Hin- und Rückverkehr über unterschiedliche Verarbeitungspunkte, kann dies insbesondere bei zustandsbehafteten Firewalls zu Kommunikationsproblemen führen. Eine NVA macht Routingfunktionen wieder als eigenständige Ressource sichtbar, bleibt jedoch Bestandteil der übergeordneten softwaregesteuerten Azure-Netzwerkarchitektur.

Effektive Routen und Next Hops – Routingentscheidungen nachvollziehen

Die Abstraktion physischer Netzwerkkomponenten verändert auch die Fehlersuche. Während Administrator:innen bei klassischen Routern unmittelbar Routingtabellen und Schnittstelleninformationen auswerten können, stellt Azure dafür eigene Diagnosemöglichkeiten bereit. Besonders hilfreich sind die effektiven Routen einer virtuellen Netzwerkschnittstelle. Sie zeigen, welche Routinginformationen für die betreffende Netzwerkanbindung tatsächlich wirksam sind. Dazu können Systemrouten, benutzerdefinierte Routen und über BGP bereitgestellte Einträge gehören. Ergänzend bietet Azure Network Watcher die Funktion Next Hop. Administrator:innen geben eine Quell-VM und eine Ziel-IP-Adresse an und können damit überprüfen, welcher logische nächste Weiterleitungspunkt für diese Verbindung ermittelt wird.

Beide Werkzeuge beantworten unterschiedliche Fragen: Die effektiven Routen zeigen den verfügbaren Routingzustand, während die Next-Hop-Analyse eine konkrete Zieladresse betrachtet. Allerdings lassen sich daraus nicht sämtliche physischen Verarbeitungsschritte ableiten. Die Diagnose beschreibt die von Azure bereitgestellte Routingperspektive, nicht zwangsläufig den vollständigen Weg eines Pakets durch die interne Transportinfrastruktur. Für die Fehlersuche ist deshalb entscheidend, die logische Routingentscheidung zu verstehen, bevor weitere Ursachen wie Sicherheitsrichtlinien oder Probleme am Zielsystem untersucht werden.

Vom Unternehmensnetzwerk in die Cloud – Wie Azure hybride Netzwerkverbindungen realisiert

In klassischen Unternehmensnetzwerken endet die eigene Netzwerkinfrastruktur häufig an einem definierten Übergabepunkt zum Provider. Router, Firewalls und WAN-Verbindungen stellen die Kommunikation zwischen Standorten, Rechenzentren und externen Netzwerken bereit. Die beteiligten Systeme verwenden Routinginformationen, um Datenpakete über unterschiedliche administrative und technische Netzwerkbereiche hinweg weiterzuleiten.

Mit Microsoft Azure erweitert sich diese Architektur um eine zusätzliche Infrastruktur, deren physische Komponenten nicht unmittelbar durch das Unternehmen verwaltet werden. Anwendungen und Daten befinden sich teilweise im eigenen Rechenzentrum, teilweise in virtuellen Azure-Netzwerken. Trotzdem müssen beide Umgebungen zuverlässig miteinander kommunizieren können. Dafür stellt Azure unterschiedliche Konnektivitätsmodelle bereit. Site-to-Site-VPN-Verbindungen ermöglichen verschlüsselte Kommunikation über IP-Netzwerke, während ExpressRoute private Verbindungen über die Infrastruktur unterstützter Konnektivitätsanbieter bereitstellt. Dynamische Routingverfahren wie BGP können dabei helfen, erreichbare Netzwerkpräfixe zwischen den beteiligten Umgebungen auszutauschen.

Die eigentliche Herausforderung besteht jedoch nicht allein darin, eine Verbindung herzustellen. Ebenso wichtig sind die Weiterleitung zwischen den Netzwerkbereichen, die Kontrolle der Kommunikationswege und die Verfügbarkeit der gesamten Architektur. Hybrides Azure Networking verbindet deshalb klassische WAN-Technologien mit den softwaregesteuerten Netzwerkfunktionen der Cloud.

Site-to-Site-VPN – Verschlüsselte Kommunikation über IP-Netzwerke

Eine verbreitete Möglichkeit zur Anbindung lokaler Unternehmensnetzwerke an Microsoft Azure ist ein Site-to-Site-VPN. Dabei wird zwischen einem VPN-Gerät im Unternehmensnetzwerk und einem Azure VPN Gateway eine verschlüsselte Verbindung aufgebaut. Die technische Grundlage bildet üblicherweise IPsec in Verbindung mit IKE. IKE dient unter anderem dazu, die beteiligten Gegenstellen zu authentifizieren und die für die verschlüsselte Kommunikation benötigten Sicherheitsparameter auszuhandeln. IPsec schützt anschließend den übertragenen Datenverkehr.

Die Verbindung wird über eine IP-basierte Transportinfrastruktur hergestellt, häufig über das öffentliche Internet. Die übertragenen Daten sind dabei durch den VPN-Tunnel geschützt. Das bedeutet allerdings nicht, dass der zugrunde liegende Transportweg privat oder hinsichtlich Latenz und Verfügbarkeit vollständig kontrollierbar wäre. Für die Weiterleitung müssen beide Seiten wissen, welche IP-Adressbereiche über den Tunnel erreichbar sind. Diese Informationen können abhängig von der Konfiguration statisch vorgegeben oder mithilfe von BGP dynamisch ausgetauscht werden.

Ein Site-to-Site-VPN erweitert somit die logische Erreichbarkeit zwischen Unternehmensnetzwerk und Azure, ohne dass beide Umgebungen zu einem gemeinsamen physischen Netzwerk werden. Die Verschlüsselung schützt den Datenverkehr während der Übertragung. Die eigentliche Routingentscheidung bleibt davon jedoch eine eigenständige Netzwerkfunktion.

ExpressRoute – Private Konnektivität über Providernetzwerke

Während ein Site-to-Site-VPN typischerweise eine verschlüsselte Verbindung über das Internet bereitstellt, verfolgt Azure ExpressRoute einen anderen Ansatz. Der Dienst ermöglicht die Anbindung lokaler Netzwerke an Microsofts Cloud-Infrastruktur über private Konnektivitätswege unterstützter Anbieter. Die Verbindung wird über einen ExpressRoute Circuit und die zugehörige Provideranbindung bereitgestellt. Je nach gewähltem Modell erfolgt die Übergabe beispielsweise über einen Konnektivitätsprovider oder eine direkte Anbindung seitens Microsoft an geeigneten Standorten. Der Circuit beschreibt dabei eine logische Konnektivitätsressource und ist nicht mit einer einzelnen physischen Leitung gleichzusetzen.

Wer bereits mit klassischen Unternehmens-WANs gearbeitet hat, kennt ein vergleichbares Prinzip aus MPLS-basierten Providernetzwerken. Dort können unterschiedliche Unternehmensstandorte über logisch getrennte VPN-Strukturen innerhalb einer gemeinsam genutzten Providerinfrastruktur miteinander verbunden werden. Auch ExpressRoute nutzt das Prinzip einer vom öffentlichen Internet getrennten Konnektivität. Allerdings ist ExpressRoute selbst kein MPLS-Dienst. Die zugrunde liegende Provideranbindung kann MPLS verwenden, muss dies aber nicht.

Für die Erreichbarkeit privater Azure-Netzwerke wird typischerweise Azure Private Peering verwendet. Dabei tauschen die beteiligten Routingkomponenten mithilfe von BGP Informationen über erreichbare IP-Präfixe aus. Im Unterschied zu einem klassischen Internet-VPN erfolgt der Transport über die entsprechende private Konnektivitätsinfrastruktur. Daraus können Vorteile hinsichtlich planbarer Konnektivität und definierter Dienstmerkmale entstehen. Eine private Verbindung bedeutet allerdings nicht automatisch eine verschlüsselte Verbindung. ExpressRoute stellt für sich genommen keine generelle Ende-zu-Ende-Verschlüsselung bereit. Falls diese erforderlich ist, müssen geeignete zusätzliche Schutzmechanismen berücksichtigt werden.

BGP – Wie Unternehmensnetzwerk und Azure Routinginformationen austauschen

Sobald Unternehmensnetzwerke und Azure miteinander verbunden sind, müssen die beteiligten Routingkomponenten wissen, welche IP-Adressbereiche über die jeweilige Verbindung erreichbar sind. Gerade in größeren Umgebungen wäre es aufwendig, sämtliche Änderungen dauerhaft über statische Routen nachzuführen. Hier kommt das Border Gateway Protocol (BGP) ins Spiel. BGP ermöglicht den Austausch von Erreichbarkeitsinformationen zwischen Routinginstanzen. Dabei werden IP-Präfixe zusammen mit weiteren Attributen übertragen, die für die Auswahl und Steuerung von Routingwegen relevant sein können. Wer sich ausführlicher mit den technischen Grundlagen, der Entwicklung und der Bedeutung dieses Routingprotokolls beschäftigen möchte, findet in meinem Beitrag Externes Routing im Internet und WAN – Architektur, Historie und Bedeutung von BGP eine vertiefende Betrachtung.

In Azure wird BGP unter anderem bei unterstützten VPN-Gateway-Konfigurationen und bei ExpressRoute eingesetzt. Lokale Router können damit Informationen über Unternehmensnetzwerke bereitstellen, während Azure entsprechende Erreichbarkeitsinformationen für die Cloud-Umgebung bekannt gibt. Die ausgetauschten Routen können anschließend die wirksamen Weiterleitungsinformationen innerhalb der beteiligten Netzwerke beeinflussen. Welche Route tatsächlich bevorzugt wird, hängt von den jeweiligen Routingregeln und der konkreten Architektur ab.

BGP stellt dabei weder selbst einen VPN-Tunnel bereit noch verschlüsselt es den übertragenen Anwendungsverkehr. Seine Aufgabe liegt im Austausch und in der Verarbeitung von Routinginformationen. Damit ergänzt BGP die physische beziehungsweise logische Verbindung um eine dynamische Steuerung der Erreichbarkeit. Gerade bei redundanten Verbindungen und komplexeren hybriden Netzwerkarchitekturen wird diese Trennung zwischen Konnektivität und Routing besonders wichtig.

Hub-and-Spoke – Zentrale Netzwerkfunktionen für mehrere virtuelle Netzwerke

Mit zunehmender Anzahl virtueller Netzwerke entsteht die Frage, wie unterschiedliche Anwendungen und Netzwerkbereiche miteinander verbunden werden sollen. Eine direkte Verbindung sämtlicher VNets untereinander kann die Verwaltung erschweren und zu einer unübersichtlichen Routing- und Sicherheitsarchitektur führen. Ein verbreiteter Ansatz ist deshalb die Hub-and-Spoke-Architektur. Dabei übernimmt ein zentrales Hub-VNet gemeinsame Netzwerkfunktionen, während die angebundenen Spoke-VNets beispielsweise unterschiedliche Anwendungen, Abteilungen oder Umgebungen aufnehmen. Im Hub können unter anderem VPN- oder ExpressRoute-Gateways, zentrale Firewalls, DNS-Komponenten und Network Virtual Appliances bereitgestellt werden. Die Verbindung zu den Spokes erfolgt typischerweise über VNet-Peering.

Allerdings entsteht durch die Verbindung mit dem Hub nicht automatisch eine vollständige Kommunikation zwischen sämtlichen Spokes. VNet-Peering ist grundsätzlich nicht transitiv. Sollen Pakete zwischen unterschiedlichen Spokes über zentrale Netzwerkkomponenten transportiert werden, müssen die erforderlichen Routing- und Weiterleitungsmechanismen ausdrücklich berücksichtigt werden. Dazu können beispielsweise User Defined Routes gehören, die bestimmte Verbindungen über eine Firewall oder NVA führen. Ebenso müssen die notwendigen Weiterleitungsberechtigungen und Sicherheitsregeln vorhanden sein. Hub-and-Spoke ist damit mehr als eine logische Anordnung virtueller Netzwerke. Die Architektur definiert, wo gemeinsame Netzwerkfunktionen bereitgestellt und welche Kommunikationswege gezielt kontrolliert werden.

Azure Virtual WAN – Wenn hybride Konnektivität zur Plattformfunktion wird

Hub-and-Spoke-Architekturen ermöglichen eine weitgehend individuelle Gestaltung zentraler Netzwerkfunktionen. Mit steigender Anzahl von Standorten, Azure-Regionen und Verbindungen wächst jedoch auch der Aufwand für die Bereitstellung und Verwaltung der beteiligten Netzwerkressourcen. Mit Azure Virtual WAN stellt Microsoft einen stärker verwalteten Ansatz für umfangreiche Netzwerkarchitekturen bereit. Der Dienst kombiniert unterschiedliche Konnektivitätsfunktionen innerhalb einer gemeinsamen Plattformarchitektur. Dazu gehören unter anderem Standortverbindungen über VPN, ExpressRoute-Anbindungen und die Verbindung virtueller Azure-Netzwerke.

Eine zentrale Rolle übernehmen dabei virtuelle Hubs. Diese stellen verwaltete Routing- und Konnektivitätsfunktionen bereit und können über die Azure-Infrastruktur miteinander verbunden werden. Administrator:innen konfigurieren die gewünschten Verbindungen und Routingvorgaben, während Azure wesentliche Teile der technischen Umsetzung übernimmt. Im Unterschied zu einem selbst aufgebauten Hub-VNet müssen die zugrunde liegenden Routingkomponenten nicht in gleicher Weise als eigenständige virtuelle Maschinen oder Netzwerkgeräte bereitgestellt werden.

Allerdings bedeutet diese Abstraktion nicht, dass sämtliche Kommunikationsbeziehungen automatisch zulässig sind. Routingtabellen, Verbindungszuordnungen und gegebenenfalls Sicherheitsfunktionen bestimmen weiterhin, welche Netzwerkbereiche miteinander kommunizieren können. Azure Virtual WAN führt damit den SDN-Gedanken auf die Ebene hybrider und regionsübergreifender Netzwerkarchitekturen weiter: Die gewünschte Konnektivität wird logisch definiert, während die Plattform einen wesentlichen Teil ihrer Umsetzung übernimmt.

Lastverteilung in Azure – Wie Netzwerkverkehr auf mehrere Ziele verteilt wird

In klassischen Unternehmensnetzwerken übernehmen Load Balancer die Aufgabe, eingehende Verbindungen auf mehrere Server zu verteilen. Sie stellen dafür häufig eine gemeinsame virtuelle IP-Adresse bereit und entscheiden anhand definierter Regeln, welcher Backend-Server eine Verbindung verarbeitet. Für die anfragenden Clients erscheint die Anwendung dabei zunächst als einheitlicher Dienst. Auch Microsoft Azure stellt unterschiedliche Verfahren zur Lastverteilung bereit. Die technische Umsetzung unterscheidet sich jedoch abhängig davon, auf welcher Ebene des Netzwerkmodells die Entscheidung getroffen wird. Während Azure Load Balancer Verbindungen anhand von Informationen der Netzwerk- und Transportschicht verarbeitet, berücksichtigt Application Gateway zusätzlich Eigenschaften des HTTP-Datenverkehrs. Andere Dienste treffen ihre Auswahl bereits vor dem eigentlichen Verbindungsaufbau.

Diese Unterschiede sind wesentlich, weil sie bestimmen, welche Informationen für eine Weiterleitungsentscheidung zur Verfügung stehen und an welcher Stelle der Kommunikationsweg beeinflusst wird. Aus architektonischer Sicht stellt sich außerdem die Frage, wie solche Funktionen in einer softwaregesteuerten Netzwerkinfrastruktur umgesetzt werden. Schließlich muss nicht jede Lastverteilungsentscheidung zwangsläufig durch ein eigenständiges, physisches Netzwerkgerät erfolgen. Lastverteilung in Azure ist deshalb nicht nur eine Frage der Verteilung von Anfragen, sondern auch der technischen Verarbeitung von Verbindungen, der Zustandsinformationen und der Integration in den Netzwerkdatenpfad.

Warum Lastverteilung mehr als die Verteilung von Anfragen ist

Wenn mehrere Server dieselbe Anwendung bereitstellen, erscheint die Verteilung eingehender Anfragen zunächst einfach: Ein Load Balancer wählt einen geeigneten Server aus und leitet den Datenverkehr dorthin weiter. Tatsächlich müssen dabei jedoch mehrere technische Anforderungen berücksichtigt werden. Eine TCP-Verbindung besteht nicht aus einer einzelnen Anfrage, sondern aus einer Folge zusammengehöriger Pakete. Diese müssen so verarbeitet werden, dass die Verbindung aus Sicht der beteiligten Systeme konsistent bleibt. Eine Lastverteilung, die bei jedem Paket unabhängig einen anderen Backend-Server auswählt, würde die Kommunikation in vielen Fällen unterbrechen. Deshalb verwenden entsprechende Verfahren Mechanismen zur stabilen Zuordnung von Verbindungen oder Datenflüssen. Hinzu kommt die Überwachung der Backend-Systeme. Ein Server, der zwar eingeschaltet ist, aber keine neuen Verbindungen mehr verarbeiten kann, sollte möglichst nicht weiterhin als reguläres Ziel ausgewählt werden. Dafür werden beispielsweise Health Probes eingesetzt, die den Zustand der verfügbaren Ziele überprüfen.

Allerdings greifen nicht alle Verfahren zur Lastverteilung an derselben Stelle in den Kommunikationsablauf ein. Manche beeinflussen bereits die Zielauswahl während der DNS-Auflösung. Andere nehmen HTTP-Verbindungen entgegen und leiten Anfragen als Reverse-Proxy weiter. Wieder andere arbeiten unmittelbar mit Informationen der Netzwerk- und Transportschicht. Entscheidend ist daher nicht allein, welcher Server ausgewählt wird, sondern auch, wann diese Entscheidung erfolgt, welche Informationen dafür verfügbar sind und wie die anschließende Kommunikation technisch umgesetzt wird.

Die folgende Abbildung stellt vier unterschiedliche Ansätze in Microsoft Azure gegenüber. Sie verdeutlicht, an welchen Stellen die jeweiligen Dienste in den Kommunikationsablauf eingreifen und ob sie selbst Bestandteil des Anwendungsdatenpfads sind.

Azure Load Balancer – Lastverteilung auf Layer 4

Beginnen wir mit dem Verfahren, das dem klassischen Verständnis eines netzwerkbasierten Load Balancers besonders nahekommt. In der vierten Ebene unserer Abbildung sehen wir, wie eine eingehende Verbindung anhand ihrer Netzwerk- und Transportinformationen einer Backend-Instanz zugeordnet wird. Der Azure Load Balancer arbeitet als Layer-4-Lastverteiler für TCP- und UDP-Verkehr. Er ermöglicht es, eingehende Verbindungen über eine gemeinsame Frontend-IP-Adresse auf mehrere Backend-Instanzen zu verteilen. Dabei kann es sich um einen öffentlichen oder internen Load Balancer handeln. Während die öffentliche Variante eine öffentlich erreichbare Frontend-IP-Adresse verwendet, stellt die interne Variante eine private Frontend-Adresse innerhalb eines virtuellen Netzwerks bereit.

Die eigentliche Zuordnung erfolgt anhand von Lastverteilungsregeln. Diese definieren unter anderem das Frontend, den Backend-Pool, das Transportprotokoll und die beteiligten Ports. Die Auswahl einer Backend-Instanz erfolgt auf Grundlage der Informationen eines Netzwerkflows und nicht anhand des Inhalts einer HTTP-Anfrage. Anders als ein HTTP-Reverse-Proxy terminiert Azure Load Balancer dafür keine Anwendungsverbindung, sondern setzt die erforderliche Weiterleitung auf Transportebene um.

Wie ebenfalls in der Abbildung dargestellt, berücksichtigt Azure den Zustand der Backend-Instanzen. Mithilfe konfigurierter Health Probes werden geeignete Ziele für neue Verbindungen ermittelt. Als fehlerhaft erkannte Instanzen werden dabei grundsätzlich nicht mehr für neue Flows ausgewählt. Azure Load Balancer stellt somit eine skalierbare Layer-4-Funktion bereit, deren Konfiguration als Cloud-Ressource erfolgt, während die technische Weiterleitung in die Azure-Netzwerkinfrastruktur integriert ist.

Verbindungszuordnung, Hash-Verfahren und Health Probes

Damit ein Layer-4-Load-Balancer zusammengehörige Pakete konsistent verarbeitet, benötigt er ein Verfahren zur Zuordnung von Netzwerkflüssen zu Backend-Instanzen. Azure Load Balancer verwendet hierfür standardmäßig ein hashbasiertes Verteilungsverfahren. Die Grundlage bildet ein 5-Tuple, bestehend aus Quell-IP-Adresse, Quellport, Ziel-IP-Adresse, Zielport und Transportprotokoll. Aus diesen Informationen wird eine Zuordnung zu einer Backend-Instanz abgeleitet. Pakete desselben Flows erhalten dadurch unter unveränderten Bedingungen dieselbe Backend-Zuordnung. Über die sogenannte Session Persistence lässt sich das Verfahren anpassen. Beispielsweise kann eine Zuordnung anhand der Quell- und Ziel-IP-Adresse erfolgen, sodass mehrere Verbindungen desselben Clients bevorzugt dieselbe Backend-Instanz erreichen. Das ist allerdings nicht mit einer anwendungsbezogenen Sitzung gleichzusetzen, wie sie beispielsweise durch HTTP-Cookies verwaltet wird.

Die Backend-Auswahl hängt außerdem vom Zustand der beteiligten Systeme ab. Hierzu verwendet Azure konfigurierte Health Probes, die beispielsweise TCP-Verbindungen oder HTTP-Anfragen zur Überprüfung der Erreichbarkeit einsetzen. Wird eine Backend-Instanz als fehlerhaft erkannt, kann sie aus der Auswahl für neue Verbindungen ausgeschlossen werden. Bestehende Verbindungen werden dadurch jedoch nicht automatisch auf eine andere Instanz übertragen. Ein zustandsbehafteter Anwendungsprozess kann seinen Zustand nicht allein durch eine neue Netzwerkzuordnung fortsetzen. Die Lastverteilung verbindet somit eine möglichst stabile Flow-Zuordnung mit der fortlaufenden Bewertung der verfügbaren Backend-Ziele.

Application Gateway – Anwendungsorientierte Verarbeitung auf Layer 7

Nicht jede Anwendung lässt sich allein anhand von IP-Adressen und Transportports sinnvoll verteilen. Insbesondere bei webbasierten Anwendungen kann es erforderlich sein, unterschiedliche HTTP-Anfragen abhängig von ihrem Inhalt oder ihrer Zieladresse zu verarbeiten. Hier setzt Azure Application Gateway an. Der Dienst arbeitet als anwendungsorientierter Load Balancer auf Layer 7 und kann HTTP- sowie HTTPS-Verkehr anhand entsprechender Routingregeln an unterschiedliche Backend-Ziele weiterleiten. Anders als ein reiner Layer-4-Load-Balancer kann Application Gateway beispielsweise den angeforderten Hostnamen oder URL-Pfad berücksichtigen. Dadurch lassen sich unterschiedliche Anwendungen oder Anwendungsbereiche über einen gemeinsamen Einstiegspunkt bereitstellen.

Technisch übernimmt Application Gateway dabei die Rolle eines Reverse-Proxys. Es nimmt die clientseitige Verbindung entgegen und stellt für die Kommunikation mit dem ausgewählten Backend eine separate Verbindung her. Bei HTTPS-Verbindungen kann die TLS-Verarbeitung am Gateway erfolgen; abhängig von der Konfiguration lässt sich die Verbindung zum Backend ebenfalls verschlüsseln. Durch diese Architektur stehen zusätzliche Funktionen zur Verfügung. Dazu gehören beispielsweise die Verarbeitung von HTTP-Headern, anwendungsbezogene Integritätsprüfungen und die optionale Einbindung einer Web Application Firewall. Diese Möglichkeiten haben allerdings ihren Preis: Die Verarbeitung ist komplexer als eine reine Layer-4-Weiterleitung, weil das Gateway Eigenschaften des Anwendungsprotokolls berücksichtigen muss. Application Gateway verteilt somit nicht lediglich Netzwerkflüsse, sondern kann die Weiterleitung anhand der tatsächlich angeforderten Webressourcen steuern.

Globale Verkehrssteuerung – Front Door und Traffic Manager

Bisher haben wir Lastverteilung regional innerhalb einer Azure-Umgebung betrachtet. Sobald Anwendungen jedoch über mehrere Regionen bereitgestellt werden, entsteht eine zusätzliche Herausforderung: Wie wird entschieden, welcher Standort eine Anfrage verarbeitet?

Microsoft Azure bietet dafür unterschiedliche Ansätze. Azure Traffic Manager arbeitet auf DNS-Ebene. Der Dienst beantwortet DNS-Anfragen anhand einer konfigurierten Routingmethode und des ermittelten Zustands der Endpunkte. Abhängig von der Konfiguration können beispielsweise Prioritäten, Gewichtungen oder geografische Kriterien berücksichtigt werden. Die eigentliche Anwendungsverbindung wird anschließend direkt zum aufgelösten Ziel aufgebaut. Traffic Manager befindet sich deshalb nicht als Proxy im Datenpfad der nachfolgenden Kommunikation. Auch DNS-Caching und die Gültigkeitsdauer der DNS-Antworten beeinflussen, wie schnell Änderungen bei Clients wirksam werden.

Azure Front Door verfolgt einen anderen Ansatz. Als global verteilter Reverse-Proxy für HTTP- und HTTPS-Anwendungen nimmt der Dienst Clientverbindungen an Microsofts Edge-Standorten entgegen. Anschließend wird der Datenverkehr anhand konfigurierter Regeln, Endpunktzustände und weiterer Auswahlkriterien zu geeigneten Ursprungsservern (Origins) weitergeleitet. Front Door kann damit unmittelbar in die Verarbeitung der Anwendungsverbindung eingreifen, während Traffic Manager die Zielauswahl über die Namensauflösung beeinflusst.

Beide Dienste unterstützen die Verteilung von Anwendungen über mehrere Standorte, greifen jedoch an unterschiedlichen Stellen in den Kommunikationsablauf ein. Gerade dieser Unterschied ist für das Verständnis globaler Azure-Netzwerkarchitekturen entscheidend.

Wie Lastverteilung in den Azure-Datenpfad eingebunden wird

Aus der Perspektive klassischer Netzwerktechnik verbinden wir Load Balancing häufig mit einer eigenständigen Appliance, die zwischen Clients und Servern installiert wird. Sie besitzt eigene Netzwerkschnittstellen, verarbeitet eingehende Verbindungen und leitet den Datenverkehr an geeignete Backend-Systeme weiter. In Azure müssen wir diese Vorstellung differenzieren. Ein Azure Load Balancer wird zwar als eigenständige Ressource konfiguriert, seine Weiterleitungsfunktion ist jedoch in die softwaregesteuerte Netzwerkinfrastruktur der Plattform integriert. Administrator:innen verwalten Frontend-Adressen, Backend-Pools, Regeln und Health Probes, ohne dafür eine klassische Load-Balancer-Appliance bereitstellen zu müssen. Hier schließt sich der Kreis zu unserer früheren Betrachtung der Virtual Filtering Platform und der programmierbaren Paketverarbeitung. Die grundlegende Idee besteht darin, Netzwerkfunktionen durch geeignete Regeln und Zustandsinformationen innerhalb eines verteilten Datenpfads umzusetzen.

Allerdings dürfen wir daraus nicht ableiten, dass sämtliche Azure-Lastverteilungsdienste dieselbe technische Architektur verwenden. Während Azure Load Balancer eine integrierte Layer-4-Funktion bereitstellt, arbeiten Application Gateway und Front Door mit anwendungsorientierten Proxy-Architekturen. Traffic Manager wiederum beeinflusst die Zielauswahl über DNS, ohne den eigentlichen Anwendungsverkehr weiterzuleiten. Der Begriff Lastverteilung beschreibt in Azure somit keine einheitliche Paketverarbeitungstechnologie, sondern unterschiedliche Verfahren zur Steuerung von Netzwerk- und Anwendungsverkehr. Welche Architektur geeignet ist, hängt deshalb nicht allein von der Anzahl der Backend-Systeme ab, sondern insbesondere von den benötigten Protokollinformationen, dem gewünschten Kontrollpunkt und den Anforderungen an die Verfügbarkeit.

Netzwerksicherheit im Azure-Datenpfad – Wie Sicherheitsrichtlinien technisch durchgesetzt werden

In klassischen Unternehmensnetzwerken werden Sicherheitsrichtlinien häufig durch dedizierte Firewalls, Access Control Lists auf Routern oder Switches und eine gezielte Segmentierung der Netzwerkinfrastruktur umgesetzt. Die Position eines Sicherheitsgeräts im Kommunikationsweg bestimmt dabei wesentlich, welcher Datenverkehr von ihm kontrolliert werden kann. In Microsoft Azure verändert sich dieses Modell. Sicherheitsfunktionen müssen nicht zwangsläufig an ein eigenständiges Netzwerkgerät gebunden sein. Stattdessen können Filterregeln innerhalb der softwaregesteuerten Netzwerkinfrastruktur durchgesetzt werden, während andere Sicherheitsfunktionen weiterhin über zentrale Kontrollpunkte realisiert werden. Für Administrator:innen entsteht daraus eine wichtige Unterscheidung: Eine Sicherheitsrichtlinie wird als logische Konfiguration definiert, ihre tatsächliche Wirkung ergibt sich jedoch erst aus der Verarbeitung der betreffenden Netzwerkpakete.

Dabei spielen mehrere Fragen eine Rolle. Welche Informationen werden zur Bewertung eines Pakets herangezogen? Wie werden zusammengehörige Verbindungen erkannt? Welche Bedeutung besitzen die Reihenfolge von Sicherheitsregeln und die Position einer Firewall im Datenpfad? Und wie wirken sich Routingentscheidungen auf die tatsächliche Sicherheitskontrolle aus? Netzwerksicherheit in Azure entsteht nicht durch einen einzelnen Dienst, sondern durch das Zusammenspiel verteilter Filtermechanismen, zustandsbehafteter Verarbeitung und zentraler Sicherheitsfunktionen. Um diese Architektur zu verstehen, beginnen wir mit den Network Security Groups und ihrer Rolle innerhalb des Azure-Datenpfads.

Network Security Groups – Verteilte Filterregeln statt zentraler Firewall

Eine grundlegende Sicherheitsfunktion innerhalb virtueller Azure-Netzwerke stellen die Network Security Groups (NSGs) bereit. Sie enthalten Regeln, mit denen eingehender und ausgehender Netzwerkverkehr anhand definierter Kriterien zugelassen oder blockiert werden kann. Zu diesen Kriterien gehören insbesondere Quell- und Ziel-IP-Adressen, Transportprotokolle sowie Quell- und Zielports. Damit erinnert das Regelmodell zunächst an klassische Access Control Lists, wie wir sie von Routern und Switches kennen.

Eine NSG kann einem Subnetz oder einer Netzwerkschnittstelle zugeordnet werden. Werden beide Ebenen verwendet, müssen die jeweils relevanten Regeln berücksichtigt werden. Eine erfolgreiche Prüfung auf einer Ebene bedeutet deshalb nicht automatisch, dass der Datenverkehr auch auf der anderen Ebene zugelassen wird. Die Regeln besitzen numerische Prioritäten. Azure verarbeitet sie in aufsteigender Reihenfolge ihrer Prioritätswerte, wobei die erste passende Regel die Entscheidung bestimmt. Zusätzlich existieren Standardregeln, die beispielsweise bestimmte Kommunikation innerhalb virtueller Netzwerke ermöglichen und anderen eingehenden Verkehr standardmäßig blockieren.

Anders als eine klassische Firewall-Appliance muss eine NSG nicht als eigenständiges Gerät in den Paketweg eingefügt werden. Ihre Regeln werden innerhalb der Azure-Netzwerkinfrastruktur durchgesetzt. Hier erkennen wir das bereits vorab beschriebene Prinzip wieder: Die Sicherheitsrichtlinie wird logisch definiert, während die tatsächliche Filterentscheidung innerhalb eines programmierbaren Datenpfads erfolgt. Eine NSG ist deshalb eher mit einer verteilten, zustandsbehafteten Paketfilterfunktion vergleichbar als mit einer zentralen Firewall-Appliance.

Stateful Inspection – Warum Azure Verbindungen statt nur einzelne Pakete betrachtet

Würden Sicherheitsregeln jedes Paket vollständig unabhängig von seiner bisherigen Kommunikation bewerten, müssten Administrator:innen für zahlreiche Verbindungen ausdrücklich auch den zugehörigen Rückverkehr berücksichtigen. In der Praxis verwenden viele Sicherheitsfunktionen deshalb eine zustandsbehaftete Paketverarbeitung, häufig als Stateful Inspection bezeichnet. Dabei werden Informationen über bereits erkannte Kommunikationsflüsse gespeichert und bei der Bewertung nachfolgender Pakete berücksichtigt.

Auch Azure Network Security Groups arbeiten zustandsbehaftet. Wird beispielsweise eine ausgehende TCP-Verbindung durch eine NSG-Regel zugelassen, kann der zugehörige Antwortverkehr aufgrund des erfassten Verbindungszustands passieren, ohne dass dafür eine eigenständige eingehende Freigaberegel erforderlich ist. Technisch knüpft dieses Prinzip an das bereits mehrfach betrachtete 5-Tuple an. Quell- und Zieladresse, beteiligte Ports und Transportprotokoll helfen dabei, zusammengehörige Pakete einem Kommunikationsfluss zuzuordnen.

Wichtig ist allerdings die Unterscheidung zwischen einer Regelentscheidung und einem bereits bestehenden Flow-Zustand. Werden NSG-Regeln geändert, bedeutet das nicht zwangsläufig, dass sämtliche zuvor zugelassenen Verbindungen unmittelbar unterbrochen werden. Bestehende Flows können weiterhin bestehen bleiben, während neue Verbindungen bereits anhand der geänderten Regeln bewertet werden. Stateful Inspection erweitert die reine Paketfilterung somit um Informationen über den Kommunikationszusammenhang. Dadurch lassen sich Sicherheitsrichtlinien praxisgerecht durchsetzen, ohne für jede zulässige Verbindung sämtliche Rückrichtungen separat freigeben zu müssen.

Azure Firewall – Zentrale Sicherheitsfunktionen im virtuellen Netzwerk

Während Network Security Groups Filterregeln unmittelbar an Subnetzen und Netzwerkschnittstellen durchsetzen, verfolgt Azure Firewall einen zentralisierten Ansatz. Der verwaltete Firewall-Dienst kann als gemeinsamer Sicherheitskontrollpunkt für mehrere virtuelle Netzwerke und unterschiedliche Kommunikationsrichtungen eingesetzt werden. Typischerweise wird Azure Firewall innerhalb einer Hub-and-Spoke-Architektur bereitgestellt. Die angebundenen Spoke-VNets verwenden dann geeignete Routingvorgaben, um ausgewählten Datenverkehr über die zentrale Firewall zu führen. Damit entsteht eine direkte Verbindung zu unserer Betrachtung der User Defined Routes im Kapitel ‚Routing ohne sichtbare Router‘: Eine Firewall kann nur den Datenverkehr kontrollieren, der sie tatsächlich durchläuft. Ihre bloße Existenz innerhalb eines virtuellen Netzwerks sorgt noch nicht dafür, dass sämtliche Kommunikationsbeziehungen automatisch über sie geführt werden.

Azure Firewall unterstützt unterschiedliche Regeltypen. Netzwerkregeln ermöglichen beispielsweise die Kontrolle von IP-basiertem Verkehr anhand von Adressen, Ports und Protokollen. Anwendungsregeln bieten zusätzliche Möglichkeiten zur Steuerung bestimmter ausgehender Verbindungen anhand unterstützter Anwendungsinformationen. Abhängig von der gewählten Dienstvariante stehen weitere Funktionen zur Verfügung, etwa Intrusion Detection and Prevention sowie zusätzliche TLS-Inspektionsmöglichkeiten. Der wesentliche architektonische Unterschied zu einer NSG liegt im Kontrollpunkt: Während NSG-Regeln verteilt durchgesetzt werden, bündelt Azure Firewall ausgewählte Sicherheitsfunktionen in einem zentralen, durch Routing erreichbaren Datenpfad.

Web Application Firewall – Anwendungsschutz auf Layer 7

Während Network Security Groups und klassische Netzwerkfilter Verbindungen vor allem anhand von IP-Adressen, Ports und Transportprotokollen kontrollieren, setzt eine Web Application Firewall (WAF) auf der Anwendungsebene an. Sie untersucht HTTP- und HTTPS-Anfragen und kann dabei Eigenschaften berücksichtigen, die einem reinen Layer-4-Paketfilter nicht zur Verfügung stehen. In Microsoft Azure lässt sich diese Funktion insbesondere mit Application Gateway und Azure Front Door kombinieren. Beide Dienste haben wir bereits im vorherigen Kapitel als Layer-7-Reverse-Proxys kennengelernt. Da sie HTTP-Anfragen verarbeiten, können entsprechende WAF-Richtlinien unmittelbar an diesen Kontrollpunkten durchgesetzt werden. Die Prüfung erfolgt anhand konfigurierter Sicherheitsregeln. Verwaltete Regelsätze erkennen beispielsweise typische Angriffsmuster wie SQL Injection oder Cross-Site Scripting (XSS). Ergänzend können Administrator:innen eigene Regeln definieren, um bestimmte Anfragen anhand ihrer Eigenschaften gezielt zuzulassen oder zu blockieren.

Abhängig vom Betriebsmodus kann die WAF verdächtige Anfragen zunächst protokollieren oder aktiv blockieren. Dabei bleibt die Abgrenzung zur Netzwerksicherheit wichtig: Eine WAF ersetzt weder Network Security Groups noch eine zentrale Firewall. Sie ergänzt diese um die inhaltliche Bewertung des HTTP-Datenverkehrs. Die entscheidende Besonderheit liegt somit im Verarbeitungspunkt: Während Netzwerkfilter Kommunikationsbeziehungen kontrollieren, kann eine WAF die Eigenschaften einzelner HTTP-Anfragen untersuchen und daraus Sicherheitsentscheidungen ableiten.

Azure DDoS Protection – Schutz vor Angriffen auf die Netzwerkverfügbarkeit

Nicht jeder Angriff auf eine Netzwerkinfrastruktur versucht, eine unzulässige Verbindung aufzubauen oder eine Schwachstelle innerhalb einer Anwendung auszunutzen. Bei einem Distributed Denial of Service (DDoS) besteht das Ziel vielmehr darin, die Verfügbarkeit eines Dienstes durch eine große Anzahl verteilter Anfragen oder gezielt erzeugten Netzwerkverkehr zu beeinträchtigen. Solche Angriffe können bereits auf der Netzwerk- und Transportschicht ansetzen. Beispielsweise können große UDP-Datenströme die verfügbare Übertragungskapazität beanspruchen oder massenhaft erzeugte TCP-SYN-Pakete die Verarbeitung neuer Verbindungen belasten. Eine klassische Firewall allein ist für die Abwehr solcher Angriffe nicht zwangsläufig ausreichend, da der schädliche Datenverkehr bereits vor dem eigentlichen Sicherheitskontrollpunkt erhebliche Ressourcen beanspruchen kann.

Microsoft Azure verfügt deshalb über Schutzmechanismen innerhalb seiner globalen Netzwerkinfrastruktur. Neben einem grundlegenden, plattformseitigen DDoS-Schutz bietet Azure DDoS Protection erweiterte Schutzfunktionen für unterstützte Ressourcen mit öffentlichen IP-Adressen. Dazu gehören die Analyse von Verkehrsmustern, die Erkennung ungewöhnlicher Belastungen und die automatische Abwehr bestimmter Angriffe auf Layer 3 und Layer 4. Anders als eine Web Application Firewall bewertet DDoS Protection dabei nicht primär den Inhalt einzelner HTTP-Anfragen. Im Vordergrund stehen die Eigenschaften und das Volumen des Netzwerkverkehrs sowie die Aufrechterhaltung der Erreichbarkeit geschützter Ressourcen. Angriffe auf der Anwendungsebene erfordern gegebenenfalls zusätzliche Schutzmechanismen, beispielsweise eine WAF. Azure DDoS Protection ergänzt damit die klassischen Sicherheitskontrollen um eine vorgelagerte Schutzfunktion, die darauf ausgerichtet ist, schädlichen Netzwerkverkehr möglichst frühzeitig abzuwehren und die Verfügbarkeit öffentlich erreichbarer Dienste zu erhalten.

Segmentierung und Zero Trust – Warum ein Subnetz keine Sicherheitsgrenze garantiert

In klassischen Netzwerken wird Segmentierung häufig mit VLANs, IP-Subnetzen und dazwischenliegenden Routern oder Firewalls verbunden. Unterschiedliche Netzwerkbereiche werden voneinander getrennt und ihre Kommunikation über definierte Übergänge kontrolliert. In Azure müssen wir diese Vorstellung differenzieren. Wie bereits im Kapitel ‚Virtuelle Netzwerke‘ erläutert, beschreibt ein Azure-Subnetz zunächst einen logischen IP-Adressbereich innerhalb eines Virtual Networks. Es stellt nicht automatisch eine eigenständige Sicherheitszone dar.

Innerhalb eines virtuellen Netzwerks ermöglicht Azure grundsätzlich die Kommunikation zwischen erreichbaren Subnetzen, sofern keine entsprechenden Sicherheits- oder Routingvorgaben entgegenstehen. Eine wirksame Segmentierung entsteht deshalb erst durch die gezielte Kombination geeigneter Netzwerk- und Sicherheitsrichtlinien. Network Security Groups können beispielsweise den zulässigen Verkehr zwischen unterschiedlichen Anwendungsbereichen einschränken. Zentrale Firewalls ermöglichen darüber hinaus eine kontrollierte Kommunikation zwischen Netzwerksegmenten, wenn die zugehörigen Datenpfade entsprechend geführt werden. Ergänzende Sicherheitsmechanismen wie Web Application Firewalls und Azure DDoS Protection übernehmen andere Aufgaben, indem sie Anwendungen vor bestimmten Angriffsmustern schützen beziehungsweise zur Verfügbarkeit öffentlich erreichbarer Dienste beitragen. Sie ersetzen jedoch keine gezielte Netzwerksegmentierung.

Dieser mehrschichtige Ansatz lässt sich mit den Grundprinzipien von Zero Trust verbinden. Die Zugehörigkeit zu einem bestimmten Netzwerkbereich sollte nicht automatisch als ausreichender Vertrauensnachweis betrachtet werden. Stattdessen müssen Kommunikationsbeziehungen anhand ihrer tatsächlichen Anforderungen bewertet und möglichst gezielt freigegeben werden. Dabei ist Netzwerksicherheit allerdings nur eine Ebene. Identitätsprüfung, Gerätezustand, Anwendungsschutz und weitere Kontrollen bleiben ebenfalls relevant. Ein Subnetz strukturiert die Adressierung. Eine Sicherheitsgrenze entsteht erst durch die wirksame Durchsetzung entsprechender Richtlinien.

Routing und Sicherheitsrichtlinien – Warum der tatsächliche Paketweg entscheidend ist

Eine Sicherheitsarchitektur kann noch so sorgfältig geplant sein: Ihre Wirksamkeit hängt davon ab, ob die vorgesehenen Kontrollmechanismen den betreffenden Datenverkehr tatsächlich erfassen. Besonders deutlich wird dies bei zentralen Firewalls und Network Virtual Appliances. Soll beispielsweise die Kommunikation zwischen zwei Spoke-VNets über eine Firewall im Hub erfolgen, müssen die entsprechenden Routinginformationen diesen Datenpfad ermöglichen und die erforderlichen Weiterleitungseinstellungen vorhanden sein. Fehlerhafte oder unvollständige Routingvorgaben können dazu führen, dass Verbindungen nicht zustande kommen oder einen anderen Weg als vorgesehen nehmen. Ebenso kann asymmetrisches Routing problematisch werden, wenn Hin- und Rückverkehr unterschiedliche zustandsbehaftete Kontrollpunkte durchlaufen.

Hier treffen mehrere Konzepte unserer bisherigen Betrachtung unmittelbar aufeinander: Longest Prefix Match bestimmt die Auswahl geeigneter Routen, User Defined Routes können den vorgesehenen Next Hop beeinflussen und zustandsbehaftete Sicherheitsfunktionen bewerten den Kommunikationsverlauf. Hinzu kommt, dass verteilte und zentrale Filtermechanismen gleichzeitig wirksam sein können. Eine Verbindung, die von Azure Firewall zugelassen wird, kann beispielsweise anschließend noch durch eine NSG blockiert werden. Umgekehrt ersetzt eine zulässige NSG-Regel nicht die Freigabe durch eine Firewall, die sich im Datenpfad befindet. Routing entscheidet, welchen Weg ein Paket nehmen soll. Sicherheitsrichtlinien bestimmen, ob es diesen Weg unter den jeweiligen Bedingungen passieren darf. Erst das Zusammenspiel beider Funktionen ergibt die tatsächlich wirksame Kommunikationsbeziehung.

Private Konnektivität – Wie Azure-Dienste über private Netzwerkpfade erreichbar werden

In klassischen Unternehmensnetzwerken ist die Erreichbarkeit eines Dienstes häufig eng mit seiner Position innerhalb der Netzwerktopologie verbunden. Ein Datenbankserver besitzt beispielsweise eine private IP-Adresse in einem definierten Subnetz. Router und Firewalls bestimmen, aus welchen Netzwerkbereichen er erreichbar ist und welche Kommunikationsbeziehungen zugelassen werden. Bei Microsoft Azure ist diese Vorstellung nicht ohne Weiteres auf sämtliche Dienste übertragbar. Während virtuelle Maschinen über Netzwerkschnittstellen unmittelbar in Azure Virtual Networks eingebunden werden, stellen viele verwaltete Plattformdienste ihre Funktionen über eigene Dienstendpunkte bereit. Die zugrunde liegende Infrastruktur wird von Microsoft betrieben und gehört nicht zum kundenseitig verwalteten VNet.

Daraus entsteht eine architektonische Herausforderung: Anwendungen sollen auf Dienste wie Azure Storage oder Azure SQL Database zugreifen können, ohne dass dafür zwangsläufig eine allgemein erreichbare öffentliche Verbindung erforderlich ist. Azure stellt hierfür unterschiedliche Mechanismen bereit. Service Endpoints erweitern die Netzwerkanbindung ausgewählter Azure-Dienste um eine VNet-bezogene Zugriffskontrolle. Private Link ermöglicht dagegen den Zugriff auf unterstützte Dienste über private Endpunkte innerhalb eines virtuellen Netzwerks. Private Konnektivität bedeutet in Azure deshalb nicht automatisch, dass sich ein Dienst physisch oder logisch vollständig innerhalb des eigenen VNets befindet. Entscheidend ist vielmehr, wie der Dienst adressiert, über welchen Netzwerkpfad er erreicht und an welcher Stelle der Zugriff kontrolliert wird.

Öffentliche und private Erreichbarkeit von Azure-Diensten

Viele Azure-Plattformdienste stellen standardmäßig öffentliche Dienstendpunkte bereit. Eine Anwendung kann beispielsweise einen Azure-Storage-Dienst über einen DNS-Namen ansprechen, der auf eine öffentlich routbare IP-Adresse verweist. Eine öffentliche Zieladresse bedeutet allerdings nicht zwangsläufig, dass der gesamte Datenverkehr über das öffentliche Internet transportiert wird. Erfolgt die Kommunikation aus Azure heraus, kann sie innerhalb der Microsoft-Netzwerkinfrastruktur geführt werden. Die öffentliche Adressierung des Dienstes und der tatsächlich verwendete Transportweg sind daher getrennt zu betrachten.

Gleichzeitig ist eine öffentliche IP-Adresse nicht mit uneingeschränkter Erreichbarkeit gleichzusetzen. Viele Azure-Dienste bieten eigene Netzwerkzugriffsregeln, mit denen sich zulässige Quellnetze oder Verbindungen einschränken lassen. Authentifizierung und Autorisierung bleiben davon unabhängige Sicherheitsmechanismen.

Für Anwendungen, die ausschließlich innerhalb definierter Unternehmens- und Cloud-Netzwerke kommunizieren sollen, kann eine private Adressierung dennoch erhebliche architektonische Vorteile bieten. Sie ermöglicht es, den Zugriff über private IP-Routen, zentrale Sicherheitskontrollen und geeignete DNS-Konfigurationen zu gestalten. Dabei dürfen wir allerdings nicht annehmen, dass jede private IP-Adresse automatisch einen vollständig privaten Ende-zu-Ende-Transport garantiert. Die entscheidende Frage lautet deshalb nicht allein, ob ein Azure-Dienst eine öffentliche oder private Adresse verwendet, sondern welche Netzwerkanbindung und welche Zugriffskontrollen tatsächlich wirksam sind.

Service Endpoints – VNet-bezogener Zugriff auf Azure-Dienste

Mit Virtual Network Service Endpoints stellt Azure einen Mechanismus bereit, über den ausgewählte Plattformdienste den Zugriff aus bestimmten VNet-Subnetzen erkennen und entsprechend einschränken können. Ein Service Endpoint wird für einen unterstützten Azure-Dienst auf einem Subnetz aktiviert. Dadurch erweitert Azure die Netzwerkanbindung dieses Subnetzes um dienstspezifische Routinginformationen. Der Datenverkehr zum betreffenden Dienst wird über das Microsoft-Netzwerk geführt und kann auf Dienstseite anhand der Herkunft aus dem autorisierten virtuellen Netzwerk beziehungsweise Subnetz kontrolliert werden.

Wichtig ist dabei die Adressierung: Ein Service Endpoint stellt dem Azure-Dienst keine private IP-Adresse innerhalb des kundenseitigen VNets bereit. Die Anwendung verwendet weiterhin den regulären Dienstendpunkt, der typischerweise über eine öffentliche IP-Adresse erreichbar ist. Die eigentliche Zugriffsbeschränkung entsteht durch die entsprechende Netzwerkkonfiguration des unterstützten Azure-Dienstes. Die Aktivierung eines Service Endpoints allein bedeutet daher noch nicht, dass der Dienst ausschließlich aus dem betreffenden Subnetz erreichbar ist.

Service Endpoints beeinflussen außerdem das Routing. Azure kann für unterstützte Dienstpräfixe spezifische Systemrouten bereitstellen, deren Auswahlregeln sich von der allgemeinen Priorisierung benutzerdefinierter Routen unterscheiden. Damit begegnet uns eine Besonderheit wieder, die wir bereits im Kapitel ‚Routing ohne sichtbare Router‘ angesprochen haben. Service Endpoints verbinden somit öffentliche Dienstadressierung mit einer VNet-bezogenen Zugriffskontrolle und einem entsprechend gesteuerten Netzwerkpfad.

Private Link und Private Endpoints – Private IP-Adressen für verwaltete Dienste

Einen anderen Ansatz verfolgt Azure Private Link. Die Technologie ermöglicht es, unterstützte Azure-Dienste und bestimmte kundenseitig bereitgestellte Dienste über private Netzwerkverbindungen erreichbar zu machen. Eine zentrale Rolle übernimmt dabei der sogenannte Private Endpoint. Ein Private Endpoint ist eine Netzwerkschnittstelle mit einer privaten IP-Adresse aus einem Subnetz des kundenseitigen Azure Virtual Networks. Diese Adresse dient als Einstiegspunkt für die Verbindung zu einer bestimmten Dienstressource. Der eigentliche Dienst wird dadurch jedoch nicht in das VNet verschoben, sondern verbleibt innerhalb der von Microsoft beziehungsweise dem jeweiligen Anbieter verwalteten Infrastruktur.

Aus Sicht einer Anwendung kann der Dienst nun über eine private Zieladresse angesprochen werden. Der Netzwerkverkehr wird über den Private Endpoint an die zugeordnete Ressource vermittelt, ohne dass für diesen Zugriff deren öffentlicher Dienstendpunkt verwendet werden muss. Damit unterscheidet sich Private Link grundlegend von Service Endpoints. Während Service Endpoints weiterhin mit der regulären, typischerweise öffentlichen Dienstadressierung arbeiten, stellt ein Private Endpoint eine private IP-Adresse innerhalb des VNets bereit.

Die Verbindung kann auch aus angebundenen Unternehmensnetzwerken erreichbar sein, sofern Routing und Namensauflösung entsprechend eingerichtet sind. Ein Private Endpoint schafft somit einen privaten Netzwerkzugang zu einer Dienstressource, ohne deren eigentliche Infrastruktur zum Bestandteil des kundenseitigen VNets zu machen.

Private Link Service – Eigene Dienste über private Endpunkte bereitstellen

Bisher haben wir Azure Private Link vor allem aus der Perspektive einer Anwendung betrachtet, die einen verwalteten Plattformdienst über eine private IP-Adresse erreichen möchte. Die zugrunde liegende Technologie lässt sich jedoch auch nutzen, um eigene Dienste für andere virtuelle Netzwerke oder Kundenumgebungen bereitzustellen. Hierfür stellt Microsoft Azure den Private Link Service bereit. Er ermöglicht es, einen selbst betriebenen Dienst über Azure Private Link zugänglich zu machen, ohne dessen Anwendungsschnittstelle dafür unmittelbar über einen öffentlichen Endpunkt anbieten zu müssen.

Technisch wird der bereitgestellte Dienst über das Frontend eines internen Azure Standard Load Balancers angebunden. Der Private Link Service bildet den Zugang zu dieser Dienstinfrastruktur. Auf der konsumierenden Seite erstellen Administrator:innen einen Private Endpoint, der eine private IP-Adresse aus dem jeweiligen VNet erhält und mit dem angebotenen Dienst verbunden wird. Die beteiligten virtuellen Netzwerke müssen dafür weder identische Adressräume verwenden noch unmittelbar über VNet Peering miteinander verbunden sein. Die Kommunikation erfolgt über die Private-Link-Infrastruktur von Azure. Der Zugriff auf den angebotenen Dienst kann dabei durch Genehmigungsmechanismen des Dienstanbieters kontrolliert werden.

Damit entsteht eine klare Trennung zwischen zwei Rollen: Der Private Link Service stellt einen Dienst für private Verbindungen bereit, während der Private Endpoint auf der konsumierenden Seite den privaten Zugang zu diesem Dienst ermöglicht. Private Link ist somit nicht auf den Zugriff auf Microsoft-Plattformdienste beschränkt. Die Technologie ermöglicht auch die kontrollierte Bereitstellung eigener Anwendungen über private Netzwerkzugänge, ohne die beteiligten VNets unmittelbar miteinander verbinden zu müssen.

DNS und Routing – Wie Anwendungen den privaten Dienstendpunkt erreichen

Die Bereitstellung eines Private Endpoints allein genügt noch nicht, damit Anwendungen einen Azure-Dienst automatisch über dessen private IP-Adresse erreichen. Entscheidend ist auch die DNS-Namensauflösung. Viele Anwendungen verwenden weiterhin den regulären DNS-Namen ihres Azure-Dienstes. Bei einer geeigneten Private-Link-Konfiguration wird dieser Name über die entsprechenden DNS-Einträge letztlich auf die private IP-Adresse des zugeordneten Private Endpoints aufgelöst.

Azure unterstützt dafür private DNS-Zonen, beispielsweise für Azure Storage oder Azure SQL Database. Diese können mit den betreffenden virtuellen Netzwerken verknüpft werden. In hybriden Umgebungen müssen gegebenenfalls zusätzlich lokale DNS-Server, bedingte Weiterleitungen oder Azure DNS Private Resolver berücksichtigt werden. Die DNS-Konfiguration bestimmt dabei zunächst nur, welche Zieladresse eine Anwendung verwendet. Ob diese Adresse tatsächlich erreichbar ist, entscheidet anschließend die Netzwerkarchitektur. Ein Client in einem anderen VNet oder im lokalen Unternehmensnetzwerk benötigt einen geeigneten Routingweg zur privaten IP-Adresse des Endpoints. Außerdem müssen gegebenenfalls vorhandene Sicherheitsregeln die Kommunikation zulassen.

Hier wird erneut die Trennung zwischen Namensauflösung, Routing und Paketverarbeitung deutlich: DNS bestimmt, welche Adresse angesprochen wird. Das Routing legt den vorgesehenen Netzwerkpfad fest, während Sicherheitsrichtlinien die zulässige Kommunikation kontrollieren. Gerade bei hybriden Private-Link-Architekturen gehören DNS-Fehlkonfigurationen deshalb zu den wichtigen Ursachen für Verbindungsprobleme.

Private Endpoints und Netzwerksicherheit – Wo die Grenzen der Isolation liegen

Die Verwendung eines Private Endpoints reduziert die Notwendigkeit, einen Azure-Dienst über seinen öffentlichen Endpunkt anzusprechen. Daraus folgt allerdings nicht automatisch, dass sämtliche anderen Zugriffswege deaktiviert oder sämtliche Sicherheitsanforderungen erfüllt sind. Bei vielen unterstützten Azure-Diensten muss der öffentliche Netzwerkzugriff gesondert eingeschränkt oder deaktiviert werden, wenn ausschließlich private Verbindungen zugelassen werden sollen. Ebenso bleiben die Authentifizierung und Autorisierung der zugreifenden Anwendungen erforderlich.

Private Endpoints können zudem in die Sicherheitsarchitektur eines VNets eingebunden werden. Für ihre Subnetze sind dabei besondere Netzwerkrichtlinien zu berücksichtigen. Insbesondere müssen entsprechende Private Endpoint Network Policies aktiviert sein, wenn Network Security Groups oder User Defined Routes für Private Endpoints wirksam werden sollen. Das ist für zentralisierte Sicherheitsarchitekturen relevant. Soll der Datenverkehr zu einem Private Endpoint beispielsweise über eine Firewall geführt werden, reicht es nicht aus, lediglich eine entsprechende UDR zu konfigurieren. Auch die besonderen Routingregeln für Private Endpoints und die erforderlichen Netzwerkrichtlinien müssen berücksichtigt werden.

Ein weiterer Punkt betrifft die Reichweite des privaten Zugangs. Ein Private Endpoint ist einer bestimmten Dienstressource beziehungsweise einem unterstützten Dienstunterbereich zugeordnet. Er bedeutet nicht, dass automatisch sämtliche Funktionen, Abhängigkeiten oder weiteren Endpunkte dieses Dienstes privat erreichbar werden. Private Link stellt einen privaten Zugangsmechanismus bereit. Eine vollständige Sicherheitsarchitektur entsteht erst durch zusätzliche Zugriffsbeschränkungen, Identitätskontrollen und korrekt konfigurierte Netzwerkpfade.

Network Security Perimeter – Netzwerkkontrolle über einzelne VNets hinaus

Mit zunehmender Nutzung verwalteter Plattformdienste entsteht eine weitere Herausforderung: Nicht sämtliche Sicherheitsanforderungen lassen sich allein über Subnetze, Private Endpoints und zentrale Firewalls abbilden. Schließlich befinden sich viele Azure-Dienste außerhalb der kundenseitig verwalteten virtuellen Netzwerke. Mit Azure Network Security Perimeter stellt Microsoft für unterstützte Plattformdienste einen zusätzlichen Mechanismus zur netzwerkbezogenen Zugriffskontrolle bereit. Dabei können geeignete Ressourcen einem gemeinsamen logischen Sicherheitsperimeter zugeordnet und Regeln für bestimmte Kommunikationsbeziehungen definiert werden.

Der Ansatz unterscheidet sich von der klassischen Segmentierung innerhalb eines VNets. Während Network Security Groups die Paketfilterung an Subnetzen oder Netzwerkschnittstellen beeinflussen, setzt Network Security Perimeter an den unterstützten Plattformressourcen und ihren öffentlichen Netzwerkzugriffen an. Damit lassen sich Sicherheitsrichtlinien über einzelne Dienstressourcen hinaus koordinieren. Die konkrete Wirkung hängt allerdings von den unterstützten Ressourcentypen, den konfigurierten Zugriffsregeln und dem jeweiligen Betriebsmodus ab.

Network Security Perimeter ersetzt weder Private Link noch die Authentifizierung und Autorisierung einer Anwendung. Auch private Verbindungen über Private Endpoints unterliegen nicht einfach denselben Zugriffsregeln wie der öffentliche Netzwerkverkehr eines Dienstes. Die Architektur verdeutlicht vielmehr, dass Azure Netzwerksicherheit auf mehreren Ebenen durchsetzt: innerhalb virtueller Netzwerke, an privaten Dienstzugängen und unmittelbar an den unterstützten Plattformressourcen. Damit erweitert sich unser Verständnis von Netzwerksegmentierung über die Grenzen klassischer IP-Subnetze hinaus.

Netzwerkdiagnose in Azure – Wenn der physische Paketweg verborgen bleibt

In klassischen Unternehmensnetzwerken beginnt die Fehlersuche häufig mit einem Blick auf die beteiligten Netzwerkgeräte. Administrator:innen überprüfen Routingtabellen, untersuchen Switch-Ports, analysieren Firewall-Regeln oder zeichnen den Datenverkehr an geeigneten Schnittstellen auf. Je nach Infrastruktur lassen sich einzelne Weiterleitungsentscheidungen bis zu den beteiligten Routern und Switches nachvollziehen. In Microsoft Azure stehen viele dieser direkten Einblicke nicht zur Verfügung. Die physische Netzwerkinfrastruktur wird von Microsoft betrieben und verwaltet. Virtuelle Netzwerke, Routinginformationen und Sicherheitsrichtlinien sind zwar konfigurierbar, ihre technische Umsetzung erfolgt jedoch innerhalb einer weitgehend abstrahierten Plattform.

Das bedeutet allerdings nicht, dass Netzwerkdiagnose in Azure zwangsläufig ungenauer sein muss. Vielmehr verändert sich die Art der verfügbaren Informationen. An die Stelle physischer Schnittstellen und einzelner Router treten beispielsweise effektive Routingtabellen, Verbindungsanalysen, Sicherheitsregeln und Diagnosefunktionen, die ausgewählte Entscheidungen der Azure-Netzwerkinfrastruktur sichtbar machen. Damit stellt sich eine grundlegende Frage: Wie lässt sich der Weg eines Datenpakets nachvollziehen, wenn die zugrunde liegenden Netzwerkgeräte nicht unmittelbar zugänglich sind? Die entscheidende Aufgabe besteht darin, zwischen der konfigurierten Netzwerktopologie, den tatsächlich wirksamen Weiterleitungs- und Sicherheitsentscheidungen und dem beobachtbaren Kommunikationsverhalten zu unterscheiden. Genau an dieser Stelle setzen die Diagnosemöglichkeiten von Microsoft Azure an.

Vom physischen Netzwerkgerät zur logischen Diagnose

Ein wesentlicher Unterschied zwischen klassischen Netzwerken und Azure liegt darin, welche Informationen bei der Fehlersuche unmittelbar verfügbar sind. In einer selbst betriebenen Netzwerkinfrastruktur können Administrator:innen beispielsweise die Forwarding Information Base eines Routers untersuchen, Interface-Zähler auslesen oder mithilfe von Paketmitschnitten überprüfen, ob ein bestimmtes Paket an einer Schnittstelle eintrifft und über welche andere Schnittstelle es weitergeleitet wird. In Azure sind solche Einblicke in die physische Infrastruktur normalerweise nicht möglich. Stattdessen stellt die Plattform Informationen über die logische Netzwerkkonfiguration und ausgewählte Ergebnisse ihrer Verarbeitung bereit.

Dabei müssen wir drei Ebenen unterscheiden: die konfigurierte Absicht, den tatsächlich wirksamen Zustand und das beobachtbare Ergebnis. Eine User Defined Route beschreibt beispielsweise einen gewünschten Weiterleitungsweg. Erst die effektive Routingtabelle zeigt, welche Routen für eine bestimmte Netzwerkschnittstelle tatsächlich berücksichtigt werden. Ob die anschließende Verbindung erfolgreich ist, hängt zusätzlich von Sicherheitsrichtlinien, der Erreichbarkeit des Zielsystems und gegebenenfalls weiteren Netzwerkfunktionen ab. Diese Trennung entspricht den Architekturprinzipien, die wir bereits in den ersten Kapiteln kennengelernt haben. Die Control Plane verwaltet Konfigurationen und verteilt die daraus abgeleiteten Vorgaben. Der Data Plane übernimmt die eigentliche Paketverarbeitung. Netzwerkdiagnose in Azure bedeutet deshalb vor allem, die wirksamen Ergebnisse der softwaredefinierten Steuerung zu überprüfen und mit dem tatsächlichen Kommunikationsverhalten abzugleichen.

Effektive Routen und Next Hop – Weiterleitungsentscheidungen nachvollziehen

Wenn eine virtuelle Maschine ein bestimmtes Ziel nicht erreichen kann, gehört die Überprüfung des Routings zu den ersten sinnvollen Diagnoseschritten. Wie wir in Kapitel ‚Routing ohne sichtbare Router‘ gesehen haben, verwendet Azure unterschiedliche Quellen für Routinginformationen. Dazu gehören Systemrouten, User Defined Routes und über BGP erlernte Routen. Die tatsächlich wirksame Routingtabelle ergibt sich aus dem Zusammenspiel dieser Informationen und den jeweiligen Auswahlregeln.

Über die Diagnosefunktion Effective Routes können Administrator:innen die effektiven Routen einer unterstützten Netzwerkschnittstelle anzeigen lassen. Dadurch wird sichtbar, welche Zielpräfixe bekannt sind, aus welchen Quellen die Routen stammen und welche Next-Hop-Typen für die Weiterleitung vorgesehen sind. Die Funktion Next Hop in Azure Network Watcher ergänzt diese Betrachtung. Für eine angegebene Quell- und Zieladresse lässt sich ermitteln, welchen nächsten logischen Weiterleitungspunkt Azure aus Sicht der untersuchten virtuellen Maschine auswählen würde.

Das ist besonders hilfreich bei komplexeren Architekturen mit Hub-and-Spoke-Vernetzung, zentralen Firewalls oder benutzerdefinierten Routen. Zeigt die Diagnose beispielsweise eine virtuelle Appliance als Next Hop, lässt sich überprüfen, ob der Datenverkehr tatsächlich über den vorgesehenen Sicherheitskontrollpunkt geführt werden soll. Allerdings zeigt ein Next-Hop-Ergebnis nicht den vollständigen physischen Paketweg durch das Microsoft-Netzwerk. Es beschreibt eine Weiterleitungsentscheidung innerhalb des Azure-Routingmodells. Effective Routes und Next Hop beantworten somit nicht die Frage, welche physischen Router ein Paket passiert, sondern welche Weiterleitungsentscheidung Azure für den untersuchten Netzwerkverkehr vorsieht.

Effektive Sicherheitsregeln – Warum eine konfigurierte Freigabe nicht genügt

Eine korrekte Route bedeutet noch nicht, dass eine Netzwerkverbindung tatsächlich zugelassen wird. Wie wir im Kapitel ‚Netzwerksicherheit im Azure-Datenpfad‘ untersucht haben, können Network Security Groups und weitere Sicherheitsfunktionen die Kommunikation unabhängig von der grundlegenden Erreichbarkeit einschränken. Besonders bei Network Security Groups kann die Fehlersuche anspruchsvoll werden, wenn Sicherheitsregeln sowohl auf Subnetzebene als auch an der Netzwerkschnittstelle einer virtuellen Maschine definiert sind.

Mit Effective Security Rules stellt Azure eine Möglichkeit bereit, die für eine unterstützte Netzwerkschnittstelle wirksamen NSG-Regeln zusammenzuführen. Administrator:innen können damit untersuchen, welche Regeln aus den beteiligten Network Security Groups stammen und welche Prioritäten beziehungsweise Filterbedingungen gelten. Für die gezielte Analyse einer Kommunikationsbeziehung eignet sich zusätzlich die IP Flow Verify-Funktion von Azure Network Watcher. Sie bewertet eine angegebene Kombination aus Richtung, Protokoll, Quell- und Zieladresse sowie Ports anhand der relevanten NSG-Regeln und liefert eine entsprechende Zulassungs- oder Blockierungsentscheidung. Damit lässt sich beispielsweise überprüfen, ob eine eingehende TCP-Verbindung zu einem bestimmten Anwendungsport durch eine NSG blockiert würde.

Wichtig ist allerdings die Reichweite dieser Aussage. Eine erfolgreiche NSG-Prüfung garantiert noch keine funktionierende Ende-zu-Ende-Verbindung. Eine zentrale Azure Firewall, eine Network Virtual Appliance oder eine Sicherheitsfunktion auf Anwendungsebene kann den Datenverkehr weiterhin beeinflussen. Die effektiven Sicherheitsregeln zeigen, welche Filterrichtlinien innerhalb ihres jeweiligen Geltungsbereichs wirksam sind. Sie ersetzen jedoch keine vollständige Analyse sämtlicher Sicherheitskontrollpunkte im Kommunikationsweg.

Azure Network Watcher – Diagnosefunktionen für virtuelle Netzwerke

Für die Analyse von Netzwerkverbindungen stellt Microsoft mit Azure Network Watcher eine Sammlung unterschiedlicher Diagnose- und Überwachungsfunktionen bereit. Der Dienst ermöglicht es, ausgewählte Eigenschaften der Azure-Netzwerkinfrastruktur zu untersuchen, ohne direkten Zugriff auf die zugrunde liegenden physischen Netzwerkgeräte zu benötigen. Dabei handelt es sich nicht um ein einzelnes Werkzeug, das den vollständigen Kommunikationsweg eines Pakets sichtbar macht. Vielmehr kombiniert Network Watcher verschiedene Diagnoseverfahren, die jeweils bestimmte Fragestellungen beantworten.

Mit Next Hop und Effective Routes lassen sich Routingentscheidungen nachvollziehen. IP Flow Verify und Effective Security Rules unterstützen die Analyse von Netzwerkfilterregeln. Weitere Funktionen ermöglichen Verbindungstests, die kontinuierliche Überwachung bestimmter Kommunikationsbeziehungen und die Aufzeichnung ausgewählter Netzwerkpakete. Besonders interessant ist Connection Troubleshoot. Diese Funktion kann die Erreichbarkeit eines angegebenen Ziels untersuchen und Hinweise auf mögliche Ursachen von Verbindungsproblemen liefern. Dazu gehören beispielsweise fehlerhafte Routinginformationen, blockierende Sicherheitsregeln oder Probleme bei der Namensauflösung. Die verfügbaren Prüfungen und Ergebnisse hängen dabei von den beteiligten Ressourcen und dem verwendeten Diagnoseverfahren ab.

Network Watcher verbindet somit unterschiedliche Perspektiven auf dieselbe Netzwerkverbindung: Konfiguration, Weiterleitung, Filterung und beobachtbares Kommunikationsverhalten. Die Stärke dieser Diagnosefunktionen liegt nicht darin, die gesamte physische Azure-Netzwerkinfrastruktur offenzulegen, sondern darin, die für Administrator:innen relevanten Entscheidungen der logischen Netzwerkarchitektur überprüfbar zu machen.

Flow Logs – Netzwerkkommunikation anhand von Verbindungsdaten analysieren

Während Routing- und Sicherheitsdiagnosen vor allem die wirksame Konfiguration untersuchen, liefern Flow Logs Informationen über beobachteten Netzwerkverkehr. Sie ermöglichen damit einen anderen Blick auf die Kommunikation innerhalb einer Azure-Umgebung. Mit Virtual Network Flow Logs können Administrator:innen Informationen über IP-Kommunikationsflüsse in unterstützten virtuellen Netzwerken erfassen. Dazu gehören unter anderem Quell- und Zieladressen, beteiligte Ports, Transportprotokolle und weitere Angaben zur jeweiligen Kommunikation.

Die aufgezeichneten Daten können beispielsweise dabei helfen, unerwartete Kommunikationsbeziehungen zu erkennen, die Nutzung bestimmter Dienste zu untersuchen oder Verkehrsmuster über einen längeren Zeitraum auszuwerten. In Verbindung mit Traffic Analytics lassen sich solche Informationen aggregieren und visualisieren. Flow Logs sind allerdings keine vollständigen Paketmitschnitte. Sie dokumentieren ausgewählte Metadaten und Zustandsinformationen zu Kommunikationsflüssen, nicht den gesamten Inhalt der übertragenen Pakete. Daraus lassen sich beispielsweise Kommunikationsbeziehungen erkennen, aber nicht ohne Weiteres einzelne HTTP-Anfragen oder vollständige TCP-Verbindungsabläufe rekonstruieren.

Historisch stellte Azure hierfür auch NSG Flow Logs bereit. Microsoft hat jedoch die Ablösung dieser Funktion durch Virtual Network Flow Logs angekündigt. Neue NSG Flow Logs können seit dem 30. Juni 2025 nicht mehr erstellt werden; die endgültige Einstellung ist für den 30. September 2027 vorgesehen. Flow Logs schließen damit eine wichtige Lücke zwischen der konfigurierten Netzwerktopologie und dem tatsächlich beobachteten Datenverkehr. Sie machen Kommunikationsmuster sichtbar, ohne die vollständige Paketverarbeitung innerhalb der Azure-Infrastruktur offenzulegen.

Packet Capture – Wenn die Analyse einzelner Pakete erforderlich wird

Nicht jedes Netzwerkproblem lässt sich anhand von Routinginformationen, Sicherheitsregeln oder Flow Logs erklären. Insbesondere bei Verbindungsabbrüchen, Protokollfehlern oder unerwartetem Anwendungsverhalten kann es notwendig werden, die tatsächlich übertragenen Pakete zu untersuchen. Azure Network Watcher stellt hierfür eine Packet-Capture-Funktion bereit. Sie ermöglicht es, den Netzwerkverkehr unterstützter virtueller Maschinen aufzuzeichnen und die Ergebnisse anschließend mit geeigneten Analysewerkzeugen auszuwerten. Ein Paketmitschnitt kann beispielsweise zeigen, ob ein TCP-Verbindungsaufbau stattfindet, ob auf ein SYN-Paket eine entsprechende Antwort folgt oder ob wiederholte Übertragungen auf Kommunikationsprobleme hinweisen. Auch DNS-Anfragen und Antworten lassen sich untersuchen, sofern sie am gewählten Erfassungspunkt sichtbar sind.

Dabei ist die Position des Mitschnitts entscheidend. Eine Aufzeichnung an einer virtuellen Maschine zeigt nur den Verkehr, der an diesem Beobachtungspunkt erfasst werden kann. Sie liefert keinen unmittelbaren Einblick in sämtliche internen Verarbeitungsschritte der Azure-Netzwerkinfrastruktur. Wird ein Paket beispielsweise bereits durch eine vorgelagerte Sicherheitsfunktion verworfen, muss es nicht zwangsläufig im Mitschnitt des Zielsystems erscheinen. Umgekehrt beweist ein erfolgreich versendetes Paket noch nicht, dass es sein Ziel erreicht hat. Ein Paketmitschnitt zeigt das tatsächliche Kommunikationsverhalten an einem bestimmten Beobachtungspunkt. Die Ursache eines Problems ergibt sich häufig erst durch den Abgleich mit Routinginformationen, Sicherheitsregeln und weiteren Diagnoseergebnissen.

DNS, Routing und Sicherheit – Ein systematischer Diagnoseansatz

Die bisherigen Diagnosemöglichkeiten lassen sich zu einem systematischen Vorgehen verbinden. Dabei greifen wir eine Unterscheidung auf, die wir bereits im vorherigen Kapitel bei der privaten Konnektivität kennengelernt haben: Namensauflösung, Routing und Sicherheitsrichtlinien erfüllen unterschiedliche Aufgaben und müssen deshalb auch getrennt untersucht werden.

Am Anfang steht die DNS-Auflösung. Verwendet eine Anwendung einen DNS-Namen, muss zunächst geklärt werden, welche Zieladresse der Client tatsächlich erhält. Gerade bei Azure Private Link kann eine fehlerhafte DNS-Konfiguration dazu führen, dass ein Dienst über seinen öffentlichen Endpunkt angesprochen wird, obwohl ein privater Zugang vorgesehen ist. Anschließend folgt die Routinganalyse. Die effektiven Routen und die Next-Hop-Diagnose helfen dabei, den vorgesehenen Weiterleitungsweg zur ermittelten Zieladresse nachzuvollziehen. Dabei muss insbesondere geprüft werden, ob der Datenverkehr über die erwarteten virtuellen Netzwerkverbindungen, Gateways oder Sicherheitskontrollpunkte geführt wird. Im dritten Schritt werden die Sicherheitsrichtlinien betrachtet. Hierzu gehören beispielsweise NSG-Regeln, zentrale Firewalls und gegebenenfalls weitere Sicherheitsmechanismen im Kommunikationsweg. Eine zulässige NSG-Verbindung bedeutet nicht automatisch, dass auch eine nachgelagerte Firewall den Verkehr passieren lässt.

Erst danach lässt sich sinnvoll untersuchen, ob das Zielsystem die Verbindung tatsächlich annimmt und die betreffende Anwendung ordnungsgemäß antwortet. Betriebssystem-Firewalls, nicht erreichbare Dienste oder fehlerhafte Anwendungskonfigurationen können schließlich auch bei korrekter Azure-Netzwerkkonfiguration zu Verbindungsproblemen führen. Eine erfolgreiche Netzwerkdiagnose folgt damit nicht allein dem vermuteten Paketweg, sondern überprüft nacheinander die Voraussetzungen, die eine funktionierende Kommunikation überhaupt ermöglichen.

Grenzen der Beobachtbarkeit – Was Azure über den Paketweg nicht offenlegt

Auch mit den verfügbaren Diagnosefunktionen bleibt ein wesentlicher Teil der Azure-Netzwerkinfrastruktur für Administrator:innen verborgen. Das betrifft insbesondere die physische Topologie des Microsoft-Netzwerks und die internen Verarbeitungsschritte, mit denen die Plattform logische Netzwerkfunktionen technisch umsetzt. Wie wir im Kapitel ‚Der Azure-Host als Netzwerkknoten‘ gesehen haben, können Weiterleitungs- und Filterfunktionen bereits auf dem Azure-Host beziehungsweise innerhalb der zugrunde liegenden Netzwerkinfrastruktur ausgeführt werden. Eine virtuelle Maschine sieht deshalb nicht zwangsläufig sämtliche Verarbeitungsschritte, die ihre Pakete vor dem Erreichen eines anderen Systems durchlaufen.

Klassische Diagnosewerkzeuge wie traceroute oder tracert stoßen hier an Grenzen. Sie basieren auf der Auswertung von Antworten, die durch die schrittweise Begrenzung der IP-Paketlebensdauer ausgelöst werden können. In virtualisierten und softwaredefinierten Netzwerken müssen die dabei sichtbaren Zwischenstationen jedoch nicht mit den tatsächlichen physischen Weiterleitungskomponenten übereinstimmen. Auch ein fehlender Zwischenhop beweist nicht, dass an dieser Stelle keine Weiterleitungsfunktion existiert. Bestimmte Komponenten können entsprechende Diagnosepakete anders behandeln oder keine auswertbare Antwort liefern.

Für die Fehlersuche bedeutet das, dass unterschiedliche Beobachtungsverfahren unterschiedliche Aussagen ermöglichen. Effektive Routen beschreiben logische Weiterleitungsinformationen, Flow Logs dokumentieren ausgewählte Kommunikationsmetadaten und Paketmitschnitte zeigen Verkehr an bestimmten Erfassungspunkten. Keine dieser Perspektiven bildet für sich genommen den vollständigen physischen Paketweg ab. Erst ihre Kombination ermöglicht eine belastbare Analyse der für Administrator:innen sichtbaren Netzwerkfunktionen.

Die Reise eines Datenpakets – Eine Azure-Netzwerkarchitektur im technischen Detail

In den bisherigen Kapiteln haben wir die unterschiedlichen Bestandteile der Azure-Netzwerkarchitektur einzeln betrachtet. Wir haben untersucht, wie virtuelle Netzwerke auf einer physischen Infrastruktur realisiert werden, wie Azure Weiterleitungsentscheidungen trifft und wie Sicherheitsrichtlinien innerhalb des Datenpfads durchgesetzt werden. Hinzu kamen hybride Netzwerkverbindungen, Lastverteilung, private Dienstendpunkte und die Möglichkeiten zur Netzwerkdiagnose. Doch wie greifen diese Mechanismen ineinander, wenn eine Anwendung tatsächlich mit einem Dienst in Azure kommuniziert?

Um diese Frage zu beantworten, verfolgen wir eine beispielhafte Kommunikation aus einem lokalen Unternehmensnetzwerk in eine Azure-Umgebung. Dabei begegnen uns viele der zuvor erläuterten Technologien erneut – diesmal jedoch nicht als eigenständige Funktionen, sondern als Bestandteile einer zusammenhängenden Netzwerkarchitektur. Der Begriff Reise eines Datenpakets ist dabei bewusst vereinfacht. Moderne Anwendungen kommunizieren häufig über mehrere aufeinanderfolgende Verbindungen. Ein Reverse Proxy kann beispielsweise eine eingehende HTTPS-Verbindung entgegennehmen und anschließend eine neue Verbindung zum eigentlichen Anwendungsserver aufbauen. Greift dieser Server wiederum auf einen Datenbank- oder Speicherdienst zu, entsteht ein weiterer Kommunikationsfluss. Wir betrachten deshalb nicht nur den Weg einzelner Pakete, sondern auch die Stellen, an denen Weiterleitungsentscheidungen getroffen, Sicherheitsrichtlinien angewendet oder neue Kommunikationsverbindungen aufgebaut werden. Das Ziel besteht darin, die zuvor beschriebenen Architekturprinzipien in ihrem tatsächlichen Zusammenspiel nachvollziehbar zu machen – und zugleich zu unterscheiden, welche Vorgänge wir technisch erklären können und welche Details innerhalb der Microsoft-Infrastruktur verborgen bleiben.

Unsere Beispielarchitektur – Vom Unternehmensnetzwerk zum Azure-Plattformdienst

Als Ausgangspunkt dient ein Unternehmen, dessen lokales Netzwerk über ExpressRoute mit Microsoft Azure verbunden ist. Ein Arbeitsplatzrechner soll eine intern bereitgestellte Webanwendung innerhalb einer Azure-Hub-and-Spoke-Architektur erreichen. Die nachfolgende Abbildung zeigt die beteiligten Netzwerkkomponenten und drei eigenständige Kommunikationsflüsse. Das Unternehmensnetzwerk verwendet den Adressbereich 10.1.0.0/16. Der Client 10.1.0.25 ist über einen Customer-Edge-Router mit ExpressRoute Private Peering verbunden. Die Routinginformationen werden über BGP ausgetauscht. Alternativ wäre eine entsprechend konfigurierte Site-to-Site-VPN-Verbindung möglich.

Auf der Azure-Seite stellt das Hub-VNet 10.0.0.0/16 die zentrale Netzwerkanbindung bereit. Es enthält das ExpressRoute Virtual Network Gateway und eine Azure Firewall in jeweils eigenen Subnetzen. Die Firewall kontrolliert den eingehenden Anwendungsverkehr, sofern dieser durch entsprechende Routingvorgaben gezielt über sie geführt wird. Über VNet Peering ist das Spoke-VNet 10.10.0.0/16 angebunden. Dort stellt ein internes Azure Application Gateway unter 10.10.1.4 den HTTPS-Zugang bereit. Als Layer-7-Reverse-Proxy vermittelt es Anfragen an zwei Backend-VMs mit den Adressen 10.10.2.10 und 10.10.2.11. Eine optionale Web Application Firewall untersucht HTTP-Anfragen auf Anwendungsebene. Network Security Groups ergänzen die Sicherheitskontrollen durch verteilte Filterregeln. Die Backend-Anwendung benötigt außerdem Zugriff auf Azure Storage. Dafür steht im Spoke-VNet ein Private Endpoint mit der Adresse 10.10.3.5 bereit. Über Azure Private Link ermöglicht er den privaten Zugriff auf den verwalteten Plattformdienst. Das Storage-Konto selbst verbleibt außerhalb des kundenseitigen VNets.

Drei Kommunikationsflüsse innerhalb eines Anwendungsvorgangs

Aus dieser Architektur ergeben sich die drei in der Abbildung farblich gekennzeichneten Kommunikationsflüsse. Flow A beschreibt die HTTPS-Verbindung vom lokalen Client über ExpressRoute und die zentrale Azure Firewall zum Application Gateway. Flow B beginnt am Application Gateway, das nach der Verarbeitung der eingehenden Anfrage eine neue Verbindung zur ausgewählten Backend-VM aufbaut. Flow C entsteht schließlich, wenn die Backend-Anwendung selbst als Client auf das Azure Storage-Konto zugreift.

Routing- und Sicherheitsvoraussetzungen der Beispielarchitektur

Für unsere weitere Analyse setzen wir voraus, dass die erforderlichen Routinginformationen, Sicherheitsrichtlinien und DNS-Einträge entsprechend eingerichtet sind. Insbesondere soll der Verkehr zwischen dem lokalen Client und dem Application Gateway in beiden Richtungen über die zentrale Azure Firewall geführt werden, während die Backend-Anwendung den Private Endpoint über den dafür vorgesehenen Netzwerkpfad erreicht. Die Architektur verdeutlicht damit einen grundlegenden Unterschied zwischen einem Anwendungsvorgang und einer Netzwerkverbindung: Was aus Sicht der Benutzer:innen wie eine einzige Anfrage erscheint, kann innerhalb der Azure-Infrastruktur aus mehreren unabhängigen Kommunikationsflüssen bestehen. Jeder dieser Flüsse besitzt eigene Quell- und Zieladressen, Routingentscheidungen, Sicherheitskontrollen und Verbindungszustände. Anhand dieser drei Kommunikationsabschnitte untersuchen wir nun Schritt für Schritt, wie Azure die Kommunikation verarbeitet und welche Teile des logischen Datenpfads für Administrator:innen nachvollziehbar bleiben.

Schritt 1: Namensauflösung – Welche Zieladresse kennt der Client?

Bevor der lokale Client eine Verbindung zur Azure-Anwendung aufbauen kann, muss er zunächst deren Netzwerkadresse ermitteln. In unserer Beispielarchitektur verwendet der Arbeitsplatzrechner mit der IP-Adresse 10.1.0.25 den internen Anwendungsnamen app.contoso.local. Die DNS-Infrastruktur des Unternehmens löst diesen Namen auf die private Frontend-Adresse 10.10.1.4 des Azure Application Gateways auf. Die Namensauflösung erfolgt zunächst über den internen DNS-Server des Unternehmens. Dieser verwaltet in unserem Beispiel den entsprechenden DNS-Eintrag selbst. In anderen Architekturen können bestimmte DNS-Anfragen auch an geeignete Resolver in Azure weitergeleitet werden. Entscheidend ist nicht, wo die Namensauflösung technisch stattfindet, sondern welche Zieladresse der Client als Ergebnis erhält. Mit der Adresse 10.10.1.4 kennt der Client nun das Ziel seiner HTTPS-Verbindung. Er kann anschließend versuchen, eine TCP-Verbindung zu Port 443 aufzubauen. Ob die entsprechenden Pakete das Application Gateway tatsächlich erreichen, hängt jedoch von weiteren Voraussetzungen ab.

Warum DNS-Auflösung und IP-Routing unterschiedliche Aufgaben erfüllen

Hier müssen wir zwischen Namensauflösung und Weiterleitung unterscheiden. DNS bestimmt zunächst, welche IP-Adresse für einen Namen verwendet wird. Es entscheidet dagegen nicht, über welche Router, Gateways oder Sicherheitskontrollpunkte die anschließenden Pakete transportiert werden. Diese Aufgabe übernimmt die Routinginfrastruktur anhand ihrer jeweils wirksamen Weiterleitungsinformationen. In unserem Beispiel befindet sich die Zieladresse im Spoke-VNet 10.10.0.0/16, während der Client Teil des lokalen Unternehmensnetzwerks 10.1.0.0/16 ist. Der Datenverkehr muss deshalb das lokale Netzwerk verlassen und über die hybride Verbindung in Richtung Azure weitergeleitet werden. Die entsprechenden Routen führen ihn zunächst über ExpressRoute und anschließend durch die vorgesehene Sicherheitsarchitektur im Hub.

Fehlerhafte DNS-Einträge und ihre Auswirkungen auf die Kommunikation

Bereits bei der Namensauflösung können allerdings Fehler entstehen, die sich später wie Routing- oder Firewall-Probleme darstellen. Würde app.contoso.local beispielsweise auf eine falsche oder nicht erreichbare IP-Adresse aufgelöst, könnte der Client die vorgesehene Anwendung nicht erreichen – selbst wenn die Routing- und Sicherheitskonfiguration für 10.10.1.4 vollständig korrekt wäre. Eine erfolgreiche DNS-Auflösung beweist umgekehrt noch nicht, dass eine Netzwerkverbindung zustande kommt. Sie bestätigt zunächst lediglich, welche Zieladresse der Client für seine Kommunikation verwenden kann.

Dieser Zusammenhang wird beim späteren Zugriff der Backend-Anwendung auf Azure Storage erneut relevant. Dort muss die DNS-Infrastruktur den Storage-Dienstnamen auf die private Adresse 10.10.3.5 des zugeordneten Private Endpoints auflösen. Obwohl beide Vorgänge auf demselben Grundprinzip beruhen, entstehen daraus unterschiedliche Kommunikationsflüsse mit jeweils eigenem Ziel und eigener Routingentscheidung. Die Reise beginnt deshalb nicht mit der Weiterleitung eines Pakets, sondern mit der Frage, welche Zieladresse der jeweilige Kommunikationspartner tatsächlich verwendet. Erst auf dieser Grundlage lässt sich untersuchen, welchen logischen Weg Azure für die anschließende Kommunikation auswählt.

Schritt 2: Vom lokalen Netzwerk über ExpressRoute zum Azure-Hub

Nachdem der Client den internen Anwendungsnamen app.contoso.local auf die private IP-Adresse 10.10.1.4 aufgelöst hat, beginnt der eigentliche IP-Datenverkehr. Der Arbeitsplatzrechner mit der Adresse 10.1.0.25 möchte eine HTTPS-Verbindung zum Application Gateway aufbauen und erzeugt dazu zunächst ein TCP-SYN-Paket. Dieses besitzt die Quelladresse 10.1.0.25, die Zieladresse 10.10.1.4 und den TCP-Zielport 443. Der Quellport wird vom Betriebssystem aus dem verfügbaren Bereich dynamisch ausgewählt. Da sich die Zieladresse nicht im lokalen Netzwerk des Clients befindet, übergibt dieser das Paket an sein zuständiges Standardgateway. Von dort gelangt es über die interne Routinginfrastruktur zum Customer-Edge-Router, der die Verbindung zur ExpressRoute-Anbindung herstellt.

Die Auswahl dieses Weges basiert auf den Routinginformationen des Unternehmensnetzwerks. In unserer Beispielarchitektur ist das Azure-Spoke-Netz 10.10.0.0/16 über die hybride Verbindung erreichbar. Der Customer-Edge-Router erhält die entsprechenden Azure-Routinginformationen über BGP im Rahmen des ExpressRoute Private Peerings und kann sie innerhalb des Unternehmensnetzwerks entsprechend der dortigen Routingarchitektur verfügbar machen. Die beteiligten Router wählen anhand ihrer Routingtabellen und Routingrichtlinien den vorgesehenen nächsten Weiterleitungspunkt.

Hier zeigt sich bereits ein wesentlicher Unterschied zwischen der Namensauflösung und der eigentlichen Paketweiterleitung. DNS hat dem Client die Zieladresse 10.10.1.4 geliefert. Die Routinginfrastruktur entscheidet nun, wie das Paket in Richtung dieses Ziels transportiert wird. Der Client selbst benötigt dafür keine Kenntnis über die interne Hub-and-Spoke-Struktur von Azure oder die später beteiligte Azure Firewall.

ExpressRoute Private Peering und die Übergabe an das Azure Virtual Network Gateway

Wie wir im Kapitel ‚Vom Unternehmensnetzwerk in die Cloud‘ untersucht haben, ermöglicht ExpressRoute eine private Konnektivität zwischen dem Unternehmensnetzwerk und dem Microsoft-Netzwerk. In unserer Architektur wird das Paket zunächst über die Infrastruktur des Konnektivitätsanbieters transportiert und anschließend an das Microsoft-Netzwerk übergeben. Die beteiligten Netze tauschen über BGP die für die Erreichbarkeit relevanten Routinginformationen aus. Auf der Azure-Seite ist die ExpressRoute-Verbindung mit einem Virtual Network Gateway verknüpft, das sich im GatewaySubnet des Hub-VNets 10.0.0.0/16 befindet. Dieses Gateway stellt die logische Anbindung zwischen der hybriden Verbindung und der Azure-VNet-Architektur bereit. Der eingehende Datenverkehr kann von dort entsprechend den wirksamen Azure-Routinginformationen weitergeleitet werden.

Dabei müssen wir erneut zwischen dem logisch nachvollziehbaren Kommunikationsweg und seiner physischen Umsetzung unterscheiden. Die Abbildung zeigt die Verbindung vom Customer-Edge-Router über ExpressRoute zum Azure Virtual Network Gateway. Sie beschreibt damit die funktionalen Übergabepunkte, nicht jedoch sämtliche physischen Router, Switches oder internen Transportmechanismen innerhalb der Provider- und Microsoft-Infrastruktur. Ebenso bedeutet die private Anbindung über ExpressRoute nicht automatisch, dass die übertragenen Daten Ende-zu-Ende verschlüsselt sind. Die Vertraulichkeit der eigentlichen Anwendungskommunikation wird in unserem Beispiel durch HTTPS beziehungsweise TLS gewährleistet. Eine zusätzliche Verschlüsselung auf der Netzwerkebene wäre eine eigenständige Architekturentscheidung.

Ankunft im Azure-Hub und weitere Verkehrslenkung

Mit dem Erreichen der Azure-Seite ist die Verbindung zum Application Gateway allerdings noch nicht hergestellt. Das Paket besitzt weiterhin die Zieladresse 10.10.1.4 und muss nun innerhalb der Azure-Netzwerkarchitektur zum Spoke-VNet weitergeleitet werden. In unserer Beispielumgebung soll dieser Verkehr zunächst die zentrale Azure Firewall im Hub durchlaufen. Der Übergang über ExpressRoute verändert somit die beteiligte Netzwerkinfrastruktur und die administrativen Zuständigkeiten, nicht jedoch die grundlegenden Prinzipien der IP-Weiterleitung. Auch innerhalb von Azure bestimmen wirksame Routinginformationen, welchen logischen Weg das Paket als Nächstes nimmt. Warum dieser Weg in unserem Beispiel zunächst zur Azure Firewall führt, untersuchen wir im folgenden Schritt.

Schritt 3: Routing im Hub – Warum der Datenverkehr zur Azure Firewall gelangt

Nachdem der Datenverkehr über ExpressRoute die Azure-Seite erreicht hat, beginnt die nächste Phase unserer Betrachtung. Das TCP-SYN-Paket des lokalen Clients 10.1.0.25 besitzt weiterhin die Zieladresse 10.10.1.4, die private Frontend-IP des Application Gateways. Dieses befindet sich jedoch nicht im Hub-VNet 10.0.0.0/16, sondern im angebundenen Spoke-VNet 10.10.0.0/16. Zwischen beiden virtuellen Netzwerken besteht eine Peering-Verbindung. Damit ist grundsätzlich eine private IP-Konnektivität zwischen Hub und Spoke möglich. Ohne zusätzliche Verkehrslenkung könnte der Datenverkehr entsprechend den wirksamen Azure-Routen direkt in Richtung des Spokes weitergeleitet werden. In unserer Beispielarchitektur soll er jedoch zunächst die zentrale Azure Firewall passieren, bevor er das Application Gateway erreicht.

Benutzerdefinierte Routen und die Verkehrslenkung zur Azure Firewall

Hier kommt die Routingarchitektur ins Spiel. Wie wir im Kapitel ‚Routing ohne sichtbare Router‘ untersucht haben, verwendet Azure für die Weiterleitung eine Kombination aus Systemrouten, benutzerdefinierten Routen und gegebenenfalls über BGP erlernten Routinginformationen. Welche Route für eine bestimmte Zieladresse tatsächlich verwendet wird, hängt von den wirksamen Routeneinträgen und den Regeln zur Routenauswahl ab. In unserer Abbildung befindet sich die Azure Firewall im AzureFirewallSubnet des Hubs. Sie übernimmt die Funktion eines zentralen Sicherheitskontrollpunkts. Damit das aus dem Unternehmensnetzwerk eintreffende Paket diesen Kontrollpunkt tatsächlich durchläuft, muss die Routingkonfiguration den entsprechenden Weg vorgeben.

Für unsere Beispielarchitektur nehmen wir deshalb an, dass eine geeignete Routentabelle mit dem GatewaySubnet des ExpressRoute Virtual Network Gateways verknüpft ist. Eine benutzerdefinierte Route für das Spoke-Adresspräfix 10.10.0.0/16 verweist dabei auf die private IP-Adresse der Azure Firewall als nächsten logischen Weiterleitungspunkt. Die Routenkonfiguration muss den Anforderungen und Einschränkungen des eingesetzten ExpressRoute-Gateways entsprechen.

Damit wird das Paket nicht unmittelbar über die Peering-Verbindung zum Application Gateway weitergeleitet, sondern zunächst zur Azure Firewall gelenkt. Die Firewall ist in diesem Zusammenhang als Virtual Appliance der vorgesehene Next Hop. Erst nach der dortigen Sicherheitsverarbeitung kann die weitere Zustellung in Richtung des Spoke-VNets erfolgen. Eine entsprechende Routingkonfiguration muss auch für den Rückverkehr berücksichtigt werden. Da die Azure Firewall zustandsbehaftet arbeitet, soll die Antwort des Application Gateways an den lokalen Client ebenfalls über diesen Sicherheitskontrollpunkt geführt werden. Dafür benötigen die beteiligten Subnetze geeignete Routen zu den lokalen Unternehmensnetzen. Andernfalls könnte der Rückverkehr einen anderen Weg nehmen und die zustandsbehaftete Verarbeitung beeinträchtigen.

Logische Weiterleitung und Sicherheitsentscheidung als getrennte Funktionen

An dieser Stelle wird deutlich, dass VNet Peering und zentrale Verkehrslenkung unterschiedliche Aufgaben erfüllen. Das Peering stellt die logische Konnektivität zwischen Hub und Spoke bereit. Die benutzerdefinierten Routen bestimmen dagegen, ob bestimmte Kommunikationsbeziehungen zunächst über eine zentrale Netzwerkfunktion geführt werden. Die bloße Existenz einer Azure Firewall im Hub bewirkt noch nicht, dass sämtlicher Verkehr zwischen dem Unternehmensnetzwerk und den Spokes automatisch durch diese Firewall fließt. Zugleich zeigt sich eine Besonderheit softwaredefinierter Netzwerke: Der nächste logische Weiterleitungspunkt muss nicht einem unmittelbar sichtbaren physischen Router entsprechen. Azure setzt die wirksamen Routinginformationen innerhalb seiner Netzwerkinfrastruktur um. Für Administrator:innen sind die konfigurierten Routen und bestimmte daraus resultierende Weiterleitungsentscheidungen nachvollziehbar, nicht jedoch sämtliche internen Verarbeitungsschritte des physischen Datenpfads.

Mit der Weiterleitung zur Azure Firewall ist die Kommunikation allerdings noch nicht zugelassen. Die Routenauswahl hat zunächst lediglich bestimmt, welchen logischen Kontrollpunkt das Paket erreichen soll. Ob die Verbindung vom lokalen Client 10.1.0.25 zum Application Gateway 10.10.1.4 auf TCP-Port 443 tatsächlich erlaubt wird, entscheidet die dort konfigurierte Sicherheitsrichtlinie. Routing bestimmt, über welchen logischen Weg ein Paket weitergeleitet werden soll. Die Sicherheitskontrolle entscheidet anschließend, ob die betreffende Kommunikation diesen Weg nutzen darf. In unserem Beispiel führt die Routingentscheidung das Paket zunächst zur Azure Firewall, deren konkrete Verarbeitung wir im nächsten Schritt untersuchen.

Schritt 4: Azure Firewall – Sicherheitsentscheidung und Verbindungszustand

Das TCP-SYN-Paket des lokalen Clients 10.1.0.25 erreicht nun die zentrale Azure Firewall im Hub-VNet 10.0.0.0/16. Es besitzt weiterhin die Zieladresse 10.10.1.4, die private Frontend-IP des Application Gateways im Spoke-VNet. Der TCP-Zielport lautet 443. Die in Schritt 3 erläuterte Routingkonfiguration hat dafür gesorgt, dass das Paket zunächst diesen zentralen Sicherheitskontrollpunkt erreicht, anstatt unmittelbar in Richtung des Application Gateways weitergeleitet zu werden.

Die Azure Firewall untersucht die Kommunikation anhand der für den betreffenden Verkehr geltenden Sicherheitsrichtlinien. In unserer Beispielarchitektur nehmen wir an, dass eine passende Netzwerkregel die Verbindung vom lokalen Unternehmensnetzwerk 10.1.0.0/16 zur privaten Frontend-Adresse 10.10.1.4 auf TCP-Port 443 erlaubt. Die Firewall kann den Verbindungsaufbau damit als zulässig einordnen und die weitere Verarbeitung des Pakets ermöglichen.

Stateful Inspection und die Bedeutung des Rückverkehrs

An dieser Stelle begegnet uns erneut das Prinzip der Stateful Inspection, das wir im Kapitel ‚Netzwerksicherheit im Azure-Datenpfad‘ untersucht haben. Die Firewall bewertet nicht ausschließlich einzelne Pakete unabhängig voneinander, sondern berücksichtigt den Zustand der zugehörigen Kommunikationsverbindung. Das erste TCP-SYN-Paket kennzeichnet den Beginn eines Verbindungsaufbaus. Die Firewall kann dafür entsprechende Zustandsinformationen anlegen und nachfolgende Pakete derselben Verbindung zuordnen.

Das ist insbesondere für den Rückverkehr relevant. Wenn das Application Gateway auf den Verbindungsaufbau antwortet, muss die Firewall die Antwortpakete der bereits zugelassenen Kommunikation zuordnen können. Bei einer zustandsbehafteten Firewall ist dafür grundsätzlich keine separate Freigaberegel für jede Antwort in Gegenrichtung erforderlich. Voraussetzung ist allerdings, dass der Rückverkehr den vorgesehenen Sicherheitskontrollpunkt tatsächlich passiert und dem bestehenden Verbindungszustand zugeordnet werden kann.

Source NAT und die Sichtbarkeit der ursprünglichen Clientadresse

Neben der Sicherheitsentscheidung müssen wir mögliche Änderungen der IP-Adressierung berücksichtigen. Azure Firewall unterstützt unterschiedliche Formen der Netzwerkadressübersetzung. Welche davon zur Anwendung kommen, hängt unter anderem von der Art der Firewall-Regel, der Zieladresse und der jeweiligen Konfiguration ab. Für unser Beispiel verwenden wir eine Netzwerkregel für die private Kommunikation zwischen dem lokalen Client und dem Application Gateway.

Wir nehmen an, dass die Azure Firewall für diese Verbindung keine Source Network Address Translation (SNAT) durchführt. Damit bleiben die ursprüngliche Quelladresse 10.1.0.25 und die Zieladresse 10.10.1.4 bei der Weiterleitung erhalten. Diese Annahme entspricht dem üblichen Verhalten von Azure-Firewall-Netzwerkregeln für Zieladressen, die als private Adressbereiche behandelt werden. Sie ist dennoch nicht mit einer grundsätzlichen Aussage gleichzusetzen, dass Azure Firewall bei privater Kommunikation niemals Adressen übersetzt. Insbesondere angepasste SNAT-Konfigurationen und andere Regeltypen können zu einem abweichenden Verhalten führen.

Weiterleitung zum Spoke-VNet und Zusammenspiel der Sicherheitsfunktionen

Für die weitere Analyse ist diese Unterscheidung wichtig: Ohne SNAT kann das Application Gateway die ursprüngliche IP-Quelladresse des lokalen Clients auf der eingehenden Netzwerkverbindung erkennen. Würde die Firewall dagegen eine Quelladressübersetzung durchführen, erschiene an dieser Stelle die übersetzte Adresse als IP-Quelle. Die spätere Proxy-Verarbeitung des Application Gateways ist davon unabhängig zu betrachten. Nachdem die Azure Firewall den Verbindungsaufbau zugelassen hat, wird das Paket entsprechend den wirksamen Routinginformationen in Richtung des Spoke-VNets 10.10.0.0/16 weitergeleitet. Die Firewall übernimmt damit eine doppelte Funktion: Sie bildet einen zentralen Kontrollpunkt für die Sicherheitsentscheidung und ist zugleich ein bewusst in den logischen Weiterleitungsweg eingebundener Netzwerkdienst. Damit die zustandsbehaftete Verarbeitung zuverlässig funktioniert, muss auch der relevante Rückverkehr über die Azure Firewall geführt werden. In unserer Beispielarchitektur setzen wir deshalb voraus, dass die Routingvorgaben für die Kommunikation zwischen dem Application Gateway und dem lokalen Unternehmensnetzwerk entsprechend abgestimmt sind. Eine asymmetrische Verkehrsführung könnte andernfalls dazu führen, dass Antwortpakete die Firewall umgehen oder nicht dem erwarteten Verbindungszustand zugeordnet werden können.

Die erfolgreiche Verarbeitung an der Azure Firewall bedeutet allerdings noch nicht, dass die HTTPS-Verbindung zum Application Gateway bereits vollständig hergestellt wurde. Das Paket muss zunächst das Spoke-VNet und die dort wirksamen Sicherheitskontrollen passieren. Anschließend muss das Application Gateway den TCP-Verbindungsaufbau und die nachfolgende TLS-Kommunikation erfolgreich verarbeiten. Die Azure Firewall ist somit kein automatisch durchlaufener Bestandteil des virtuellen Netzwerks. Ihre Wirksamkeit ergibt sich aus dem Zusammenspiel von Routing, Sicherheitsrichtlinien, zustandsbehafteter Verbindungsverarbeitung und gegebenenfalls Netzwerkadressübersetzung. In unserem Beispiel hat die Firewall den Verbindungsaufbau zugelassen und das Paket für die weitere Zustellung zum Application Gateway freigegeben.

Schritt 5: Das Spoke-VNet – Logische Weiterleitung und verteilte Filterung

Nachdem die Azure Firewall den Verbindungsaufbau zugelassen hat, wird das TCP-SYN-Paket entsprechend den wirksamen Routinginformationen in Richtung des Spoke-VNets 10.10.0.0/16 weitergeleitet. Die Zieladresse bleibt weiterhin 10.10.1.4, die private Frontend-IP des Application Gateways. Da wir in unserer Beispielarchitektur von einer Weiterleitung ohne zusätzliche Quelladressübersetzung ausgehen, besitzt das Paket auch weiterhin die ursprüngliche Quelladresse 10.1.0.25 des lokalen Clients. Die Verbindung zwischen dem Hub-VNet 10.0.0.0/16 und dem Spoke-VNet wird durch VNet Peering bereitgestellt. Wie wir im Kapitel ‚Virtuelle Netzwerke‘ untersucht haben, entsteht dadurch keine klassische Layer-2-Verbindung zwischen zwei physischen Netzwerksegmenten. Azure ermöglicht vielmehr eine private IP-Konnektivität zwischen den virtuellen Netzwerken, deren technische Umsetzung innerhalb der softwaredefinierten Netzwerkinfrastruktur erfolgt.

Dabei übernimmt das Peering eine andere Aufgabe als die zuvor betrachteten benutzerdefinierten Routen. Das Peering stellt die grundsätzliche Konnektivität zwischen den beteiligten VNets her. Die wirksamen Routinginformationen bestimmen dagegen, wie der Datenverkehr zu seinem jeweiligen Ziel weitergeleitet wird. In unserer Architektur ist die Azure Firewall bewusst als zentraler Sicherheitskontrollpunkt in den Kommunikationsweg eingebunden. Damit diese Verkehrsführung funktioniert, müssen auch die Peering-Einstellungen und die Routingvorgaben aufeinander abgestimmt sein. Insbesondere muss die Weiterleitung über die zentrale Netzwerkfunktion durch die entsprechenden Konfigurationen ermöglicht werden. Das Paket erreicht schließlich den Netzwerkbereich des Application Gateways. Dieses befindet sich in unserer Abbildung in einem eigenen Subnetz mit dem Adressbereich 10.10.1.0/27. Die private Frontend-Adresse 10.10.1.4 gehört zu diesem Subnetz und bildet den vorgesehenen Zielendpunkt der eingehenden HTTPS-Verbindung.

Network Security Groups als verteilte Sicherheitskontrolle

An dieser Stelle kann eine weitere Sicherheitskontrolle wirksam werden. In unserer Beispielarchitektur ist dem Application-Gateway-Subnetz eine Network Security Group zugeordnet. Sie enthält Regeln, die den vorgesehenen eingehenden HTTPS-Verkehr zulassen und gleichzeitig die für den Betrieb des Application Gateways erforderliche Kommunikation berücksichtigen. Wie ich im Kapitel ‚Netzwerksicherheit im Azure-Datenpfad‘ erläutert habe, arbeiten Network Security Groups als zustandsbehaftete Netzwerkfilter. Sie bewerten den Verkehr anhand von Merkmalen wie Quell- und Zieladresse, Transportprotokoll und Portnummern. Für unser TCP-SYN-Paket bedeutet das, dass die relevanten NSG-Regeln eine Kommunikation von 10.1.0.25 zur privaten Frontend-Adresse 10.10.1.4 auf TCP-Port 443 zulassen müssen.

Diese Filterung unterscheidet sich von der zuvor durchlaufenen Azure Firewall. Während die Azure Firewall in unserer Architektur einen zentralen, ausdrücklich über Routing eingebundenen Sicherheitskontrollpunkt bildet, werden NSG-Regeln innerhalb der verteilten Azure-Datenpfadverarbeitung durchgesetzt. Wie wir im Kapitel ‚Der Azure-Host als Netzwerkknoten‘ untersucht haben, verwendet Azure dafür softwaredefinierte Netzwerkfunktionen, die nicht als eigenständige physische Firewall-Geräte innerhalb des sichtbaren Kommunikationswegs erscheinen.

Zusammenspiel von Azure Firewall, NSG und Web Application Firewall

Für die Anwendungskommunikation bedeutet das, dass mehrere Sicherheitsentscheidungen wirksam werden können, obwohl sie auf unterschiedlichen technischen Mechanismen beruhen. Die zentrale Azure Firewall hat die Verbindung bereits zugelassen. Zusätzlich müssen nun die relevanten NSG-Regeln des Application-Gateway-Subnetzes den vorgesehenen Datenverkehr erlauben. Eine Freigabe an einem dieser Kontrollpunkte ersetzt nicht automatisch die erforderliche Freigabe am anderen. Dabei besitzt das Application Gateway besondere Anforderungen an seine Subnetz- und Netzwerksicherheitskonfiguration.

Neben dem eigentlichen Anwendungsverkehr müssen beispielsweise die für Verwaltung, Infrastrukturkommunikation und Backend-Erreichbarkeit erforderlichen Kommunikationsbeziehungen berücksichtigt werden. Die NSG darf diese notwendigen Verbindungen nicht unbeabsichtigt blockieren. Von dieser Netzwerkfilterung ist die optionale Web Application Firewall des Application Gateways zu unterscheiden. Eine NSG bewertet die Kommunikation anhand von Netzwerk- und Transportmerkmalen. Die WAF kann dagegen später die eigentliche HTTP-Anfrage auf Anwendungsebene untersuchen. Diese Verarbeitung setzt voraus, dass die Verbindung das Application Gateway erreicht und dort entsprechend verarbeitet wird.

Erreichen des Application Gateways und Abschluss der Netzwerkweiterleitung

Mit dem Erreichen der privaten Frontend-Adresse 10.10.1.4 hat unser TCP-SYN-Paket damit den vorgesehenen logischen Netzwerkweg durchlaufen: vom lokalen Unternehmensnetzwerk über ExpressRoute, die zentrale Azure Firewall und die Hub-and-Spoke-Konnektivität bis zum Application Gateway. Der TCP-Verbindungsaufbau ist zu diesem Zeitpunkt allerdings noch nicht vollständig abgeschlossen. Dazu muss das Application Gateway das eingehende SYN-Paket verarbeiten und die entsprechende Antwort den Rückweg zum Client finden.

Die Grenze eines virtuellen Netzwerks und die Grenze einer Sicherheitszone sind nicht zwangsläufig identisch. Erst das Zusammenspiel aus logischer Konnektivität, wirksamen Routinginformationen und den beteiligten Sicherheitskontrollen bestimmt, ob eine Kommunikation ihr vorgesehenes Ziel erreichen kann. In unserer Beispielarchitektur bilden Azure Firewall und Network Security Group unterschiedliche, aufeinander abgestimmte Kontrollpunkte innerhalb desselben clientseitigen Kommunikationsflusses.

Schritt 6: Application Gateway – Wenn aus einem Kommunikationsfluss zwei werden

Mit dem Erreichen des Application Gateways verändert sich die Art der Netzwerkverarbeitung grundlegend. Bis zu diesem Punkt haben wir überwiegend die Weiterleitung und Sicherheitskontrolle einer bestehenden IP-Kommunikation betrachtet. Das Application Gateway arbeitet dagegen als Layer-7-Reverse-Proxy. Es nimmt eingehende Verbindungen entgegen, verarbeitet HTTP- beziehungsweise HTTPS-Anfragen und vermittelt diese anschließend an geeignete Backend-Systeme. In unserer Beispielarchitektur erreicht das TCP-SYN-Paket des lokalen Clients 10.1.0.25 die private Frontend-Adresse 10.10.1.4 des Application Gateways. Dort ist ein HTTPS-Listener auf TCP-Port 443 konfiguriert. Das Application Gateway beantwortet den Verbindungsaufbau mit einem TCP-SYN-ACK-Paket, das über die vorgesehene Netzwerkroute zum Client zurückgelangt. Nach Abschluss des TCP-Drei-Wege-Handshakes beginnt die TLS-Aushandlung.

Für unser Szenario nehmen wir an, dass die TLS-Verbindung am Application Gateway terminiert wird. Der Client baut seine verschlüsselte HTTPS-Verbindung damit nicht unmittelbar zur eigentlichen Backend-Anwendung auf, sondern zum Application Gateway. Dieses übernimmt die serverseitige TLS-Verarbeitung, präsentiert das für den Anwendungsnamen passende Zertifikat und kann anschließend die HTTP-Anfrage auf Anwendungsebene auswerten. Ist das Application Gateway mit einer Web Application Firewall ausgestattet, kann die entschlüsselte HTTP-Anfrage zusätzlich anhand der konfigurierten WAF-Richtlinien untersucht werden. Dabei lassen sich beispielsweise bekannte Angriffsmuster erkennen, bestimmte Anfragen anhand definierter Regeln blockieren oder verdächtige Zugriffe protokollieren. Ob eine erkannte Anfrage tatsächlich blockiert oder lediglich dokumentiert wird, hängt unter anderem vom Betriebsmodus und den jeweiligen WAF-Regeln ab.

WAF-Prüfung und Auswahl eines geeigneten Backend-Systems

Diese Prüfung unterscheidet sich wesentlich von den zuvor durchlaufenen Sicherheitskontrollen. Die Azure Firewall hat in unserem Beispiel die Netzwerkverbindung anhand ihrer Sicherheitsrichtlinien zugelassen. Die Network Security Group hat die relevanten Netzwerk- und Transportmerkmale bewertet. Die WAF kann dagegen den Inhalt einer HTTP-Anfrage berücksichtigen. Sie trifft ihre Entscheidung somit auf einer anderen Protokollebene und verfügt über Informationen, die einer reinen Layer-3- oder Layer-4-Filterung nicht in gleicher Weise zur Verfügung stehen. Nach der Verarbeitung der eingehenden Anfrage ermittelt das Application Gateway anhand seiner Listener-, Routing- und Backend-Konfiguration das vorgesehene Backend-Ziel. In unserer Abbildung stehen dafür zwei virtuelle Maschinen im Backend-Subnetz 10.10.2.0/24 bereit. Sie besitzen die privaten IP-Adressen 10.10.2.10 und 10.10.2.11.

Welche Backend-VM für eine neue Anfrage beziehungsweise Verbindung ausgewählt wird, hängt von der konfigurierten Weiterleitungslogik und den verfügbaren gesunden Backend-Zielen ab. Das Application Gateway überwacht deren Erreichbarkeit mithilfe von Health Probes. Dabei wird nicht lediglich die Existenz einer IP-Adresse geprüft, sondern die Erreichbarkeit des Backend-Dienstes anhand der vorgesehenen Prüfkonfiguration bewertet. Der entscheidende technische Übergang erfolgt nun zwischen dem clientseitigen Frontend und der Backend-Kommunikation. Das Application Gateway leitet nicht einfach das ursprüngliche TCP-Paket des lokalen Clients unverändert an eine der virtuellen Maschinen weiter. Als Reverse Proxy verwendet es vielmehr eine eigenständige Transportverbindung zum ausgewählten Backend-System. Eine solche Verbindung kann neu aufgebaut oder im Rahmen des Verbindungsmanagements wiederverwendet werden.

Flow A und Flow B – Zwei unabhängige HTTPS-Verbindungen

Damit entstehen die beiden in unserer Architekturabbildung getrennt dargestellten Kommunikationsflüsse. Flow A beschreibt die HTTPS-Verbindung zwischen dem lokalen Client 10.1.0.25 und dem privaten Frontend 10.10.1.4 des Application Gateways. Diese Verbindung endet am Reverse Proxy. Flow B beschreibt die eigenständige Backend-Kommunikation zwischen dem Application Gateway und der ausgewählten virtuellen Maschine, beispielsweise 10.10.2.10. Für diese Verbindung verwendet das Application Gateway eine eigene Quelladresse aus seinem Subnetz sowie die Zieladresse und den konfigurierten Port des Backend-Dienstes.

In unserem Szenario gehen wir davon aus, dass auch die Backend-Verbindung über HTTPS erfolgt. Das Application Gateway baut dafür eine separate TLS-Verbindung zum Backend auf beziehungsweise verwendet eine geeignete bestehende Verbindung. Die Verschlüsselung zwischen Client und Application Gateway und die Verschlüsselung zwischen Application Gateway und Backend sind somit technisch eigenständige Vorgänge. Sie können unterschiedliche Zertifikate und TLS-Einstellungen verwenden. Auch die IP-Adressierung verändert sich an dieser Stelle. Während das Application Gateway die clientseitige Verbindung aufgrund unserer angenommenen Weiterleitung ohne SNAT mit der ursprünglichen Quelladresse 10.1.0.25 empfängt, erscheint diese Adresse nicht automatisch als IP-Quelle der Backend-Verbindung. Aus Sicht der Backend-VM stammt die neue Verbindung vom Application Gateway.

Clientidentität über HTTP-Header und Sicherheitskontrollen im Backend

Damit die Anwendung dennoch Informationen über den ursprünglichen Client erhält, kann das Application Gateway entsprechende HTTP-Header übermitteln. Ein bekanntes Beispiel ist X-Forwarded-For, über das die ursprüngliche Clientadresse weitergegeben werden kann. Diese Information gehört allerdings zur HTTP-Kommunikation und darf nicht mit der tatsächlichen IP-Quelladresse der Backend-Verbindung verwechselt werden.

Für sicherheitsrelevante Auswertungen muss außerdem berücksichtigt werden, welche vorgeschalteten Proxys als vertrauenswürdig gelten und wie entsprechende Header verarbeitet werden. Auch für Flow B gelten eigene Netzwerk- und Sicherheitsbedingungen. Die Verbindung muss anhand der wirksamen Routinginformationen das Backend-Subnetz erreichen können. Gleichzeitig müssen die relevanten Network Security Groups den Verkehr vom Application Gateway zum Backend-Dienst zulassen. Die erfolgreiche Freigabe von Flow A durch die zentrale Azure Firewall bedeutet deshalb nicht automatisch, dass auch Flow B funktioniert.

Die Proxy-Grenze als Trennung zweier Kommunikationsflüsse

Mit der Verarbeitung durch das Application Gateway wird somit eine wesentliche Grenze innerhalb unserer Anwendungskommunikation sichtbar. Aus einer eingehenden HTTPS-Anfrage entsteht eine separate Kommunikation zum eigentlichen Anwendungsserver. Beide Verbindungen besitzen eigene Adressierungsinformationen, Transportzustände, Sicherheitskontrollen und gegebenenfalls eigenständige TLS-Sitzungen.

Das Application Gateway ist damit nicht lediglich ein weiterer Weiterleitungspunkt im IP-Datenpfad. Es bildet eine Proxy-Grenze, an der die clientseitige Verbindung terminiert, die HTTP-Anfrage verarbeitet und die Kommunikation über eine eigenständige Backend-Verbindung fortgesetzt wird. Genau dieser Übergang erklärt, warum ein zusammenhängender Anwendungsvorgang nicht mit einer einzigen durchgehenden TCP-Verbindung gleichgesetzt werden darf.

Schritt 7: Die Anwendung – Vom Zielsystem zum neuen Client

Nachdem das Application Gateway die eingehende HTTPS-Anfrage verarbeitet und ein geeignetes Backend-System ausgewählt hat, erreicht die Anfrage nun die eigentliche Anwendung. In unserer Beispielarchitektur nehmen wir an, dass die virtuelle Maschine mit der privaten IP-Adresse 10.10.2.10 im Backend-Subnetz 10.10.2.0/24 ausgewählt wurde. Wie wir im vorherigen Schritt gesehen haben, erfolgt die Kommunikation zwischen dem Application Gateway und der Backend-VM über eine eigenständige Netzwerkverbindung. Aus Sicht des Betriebssystems der virtuellen Maschine stammt diese Verbindung von einer Backend-seitigen IP-Adresse des Application Gateways.

Die ursprüngliche Clientadresse 10.1.0.25 ist deshalb nicht automatisch die Quelladresse der eingehenden IP-Pakete. Sie kann der Anwendung jedoch über geeignete HTTP-Header, beispielsweise X-Forwarded-For, als zusätzliche Information zur Verfügung stehen. Die Backend-VM nimmt die HTTPS-Verbindung entgegen und verarbeitet die vom Application Gateway übermittelte HTTP-Anfrage. Da wir in unserem Szenario auch für die Backend-Kommunikation HTTPS vorgesehen haben, erfolgt die zugehörige TLS-Verarbeitung auf dem Anwendungsserver. Die Anwendung kann anschließend die angeforderte Operation ausführen und die dafür erforderlichen Daten zusammenstellen.

Rollenwechsel der Anwendung und Entstehung von Flow C

Für unser Beispiel nehmen wir an, dass die Anwendung zusätzliche Informationen aus einem Azure Storage-Konto benötigt. Dort könnten beispielsweise Dokumente, Konfigurationsdaten oder andere anwendungsbezogene Dateien abgelegt sein. Um diese Informationen abzurufen, muss die Anwendung eine weitere Netzwerkverbindung zu dem verwalteten Azure-Dienst herstellen. Damit verändert sich die Rolle der Backend-VM innerhalb unserer Architektur. Während sie gerade noch das Ziel einer eingehenden Kommunikation war, wird sie nun selbst zum Client einer neuen Verbindung.

In der Architekturabbildung beginnt an dieser Stelle Flow C. Die Backend-VM 10.10.2.10 initiiert eine eigenständige HTTPS-Kommunikation zum Azure Storage-Dienst. Dieser Zugriff erfolgt nicht über das Application Gateway, denn dessen Aufgabe besteht in unserem Szenario darin, eingehende Webanfragen an die Backend-Systeme zu vermitteln. Ebenso muss die neue Verbindung nicht zwangsläufig die zentrale Azure Firewall im Hub durchlaufen. Welche Netzwerkfunktionen tatsächlich beteiligt sind, ergibt sich aus der Zieladressierung und den dafür wirksamen Routing- und Sicherheitsvorgaben.

Private DNS-Auflösung und Verbindungsaufbau zum Azure Storage-Dienst

Zunächst benötigt die Anwendung eine Zieladresse für den Storage-Dienst. Dazu verwendet sie den vorgesehenen DNS-Namen des Storage-Kontos. In unserer Beispielarchitektur ist die private Namensauflösung so eingerichtet, dass dieser Name auf die IP-Adresse 10.10.3.5 des zugeordneten Private Endpoints verweist. Diese Adresse gehört zum Private-Endpoint-Subnetz des Spoke-VNets 10.10.0.0/16. Die Anwendung kann den Speicherdienst dadurch über einen privaten Zugangspunkt erreichen, ohne dessen öffentlichen Endpunkt als Zieladresse verwenden zu müssen. Wie die Verbindung über den Private Endpoint und Azure Private Link technisch vermittelt wird, untersuchen wir im nächsten Schritt. Bereits jetzt lässt sich jedoch erkennen, dass Flow C andere Kommunikationsmerkmale besitzt als die beiden vorherigen Abschnitte. Die Quelladresse ist nun die private IP-Adresse der Backend-VM 10.10.2.10. Die Zieladresse lautet 10.10.3.5, und für den HTTPS-Zugriff wird TCP-Port 443 verwendet. Der dynamisch gewählte Quellport, der TCP-Verbindungszustand und die TLS-Sitzung gehören ausschließlich zu dieser neuen Verbindung.

Auch die Sicherheitsentscheidungen müssen eigenständig betrachtet werden. Eine erfolgreiche Kommunikation zwischen Application Gateway und Backend-VM bedeutet nicht automatisch, dass die Backend-Anwendung den Storage-Dienst erreichen kann. Dafür müssen die Namensauflösung, die wirksamen Routinginformationen und die gegebenenfalls anwendbaren Netzwerksicherheitsrichtlinien ebenfalls eine zulässige Kommunikation ermöglichen. Hinzu kommen die Zugriffs- und Berechtigungsmechanismen des Storage-Dienstes selbst.

Eigenständige Netzwerkverbindungen innerhalb eines Anwendungsvorgangs

An dieser Stelle wird ein grundlegendes Prinzip moderner Anwendungsarchitekturen sichtbar: Die Verarbeitung einer einzigen Benutzer:innenanfrage kann mehrere voneinander getrennte Netzwerkverbindungen auslösen. Jede Verbindung besitzt ihre eigenen Kommunikationspartner und wird unabhängig von den anderen anhand der jeweils geltenden Netzwerk- und Sicherheitskonfiguration verarbeitet. Die Verbindung vom lokalen Client zum Application Gateway wird deshalb nicht bis zum Azure Storage-Konto verlängert. Ebenso wird die Backend-Verbindung des Application Gateways nicht einfach für den Storage-Zugriff weiterverwendet.

Stattdessen erzeugt die Anwendung eine zusätzliche Kommunikation, deren Ergebnis sie anschließend für die Bearbeitung der ursprünglichen Anfrage verwendet. Eine Anwendung kann somit gleichzeitig Ziel einer eingehenden Kommunikation und Ausgangspunkt weiterer Netzwerkverbindungen sein. In unserer Beispielarchitektur entstehen dadurch drei eigenständige Kommunikationsflüsse, die funktional zusammengehören, auf Netzwerkebene jedoch unterschiedliche Adressen, Verbindungszustände, Routingentscheidungen und Sicherheitskontrollen besitzen.

Schritt 8: Private Endpoint – Wenn ein Plattformdienst über eine private IP-Adresse erreichbar wird

Für den Zugriff auf das Azure Storage-Konto verwendet unsere Anwendung einen Private Endpoint, der sich im Spoke-VNet 10.10.0.0/16 befindet. In unserer Beispielarchitektur ist dafür das Subnetz 10.10.3.0/27 vorgesehen. Der Private Endpoint besitzt die private IP-Adresse 10.10.3.5 und stellt den Zugangspunkt zur entsprechenden Storage-Ressource bereit. Wie wir im Kapitel ‚Private Konnektivität‘ untersucht haben, wird der eigentliche Plattformdienst dadurch nicht Bestandteil des kundenseitigen virtuellen Netzwerks. Das Storage-Konto verbleibt innerhalb der von Microsoft betriebenen Dienstinfrastruktur. Der Private Endpoint stellt vielmehr eine private Netzwerkschnittstelle im VNet bereit, über die eine Verbindung zu einer bestimmten Dienstressource mithilfe von Azure Private Link hergestellt werden kann. Damit verändert sich vor allem die Art, wie die Anwendung den Dienst adressiert und erreicht. Die Backend-VM 10.10.2.10 muss nicht den öffentlichen Endpunkt des Storage-Dienstes als IP-Ziel verwenden. Stattdessen kann sie den vorgesehenen Dienstendpunkt über die private Adresse 10.10.3.5 erreichen.

Private DNS-Auflösung und Adressierung des Storage-Kontos

Die Grundlage dafür bildet erneut die Namensauflösung. Für unsere Beispielarchitektur nehmen wir an, dass die Anwendung auf Blob Storage zugreift und dafür den regulären Dienstnamen des Storage-Kontos verwendet, beispielsweise storagekonto.blob.core.windows.net. Die private DNS-Konfiguration ist so eingerichtet, dass dieser Name über die entsprechende Private-Link-Namensauflösung zur Adresse 10.10.3.5 führt. Dabei verwendet die Anwendung weiterhin den regulären Dienstnamen. Sie muss nicht ausdrücklich eine IP-Adresse oder einen besonderen privaten Hostnamen ansprechen.

Die DNS-Konfiguration sorgt dafür, dass die Verbindung innerhalb unserer Netzwerkarchitektur an den vorgesehenen Private Endpoint gerichtet wird. Dieser Zusammenhang ist wesentlich: Der Private Endpoint verändert nicht die fachliche Identität des angesprochenen Storage-Dienstes. Die Anwendung greift weiterhin auf dieselbe Azure-Ressource zu. Allerdings wird deren Erreichbarkeit über einen privaten Netzwerkzugang hergestellt. Auch die TLS-Verbindung kann weiterhin anhand des regulären Dienstnamens aufgebaut und das zugehörige Serverzertifikat entsprechend geprüft werden.

Flow C – Privater Netzwerkpfad zwischen Backend-VM und Storage

Nach erfolgreicher Namensauflösung initiiert die Backend-VM eine HTTPS-Verbindung von 10.10.2.10 zur Zieladresse 10.10.3.5 auf TCP-Port 443. Damit betrachten wir den dritten Kommunikationsfluss unserer Architekturabbildung, Flow C. Für diese Verbindung gelten eigene Routing- und Sicherheitsbedingungen. Die Backend-VM befindet sich im Subnetz 10.10.2.0/24, während der Private Endpoint dem Subnetz 10.10.3.0/27 zugeordnet ist. Beide Subnetze gehören zum selben Spoke-VNet.

In unserer Beispielarchitektur nehmen wir an, dass die wirksamen Routinginformationen einen direkten logischen Kommunikationsweg zwischen diesen beiden Netzwerkbereichen ermöglichen. Der Datenverkehr wird deshalb nicht erneut über die zentrale Azure Firewall im Hub geführt. Diese Firewall ist in unserem Szenario ausdrücklich für den eingehenden Kommunikationsfluss vom Unternehmensnetzwerk zum Application Gateway vorgesehen. Daraus ergibt sich jedoch keine automatische Verpflichtung, auch sämtliche von der Backend-Anwendung initiierten Verbindungen über denselben Sicherheitskontrollpunkt zu leiten.

Netzwerkrichtlinien für Private Endpoints und zentrale Sicherheitskontrollen

Soll auch der Zugriff auf Azure Storage zentral kontrolliert oder inspiziert werden, muss die Architektur dafür geeignete Routing- und Sicherheitsvorgaben enthalten. Dabei sind die Besonderheiten von Private Endpoints zu berücksichtigen. Anders als bei einer gewöhnlichen virtuellen Maschine unterliegen Private Endpoints spezifischen Netzwerkrichtlinien. Insbesondere die Anwendung von Network Security Groups und benutzerdefinierten Routen auf den Private-Endpoint-Datenverkehr hängt davon ab, welche Netzwerkrichtlinien für das betreffende Subnetz aktiviert sind und welche Azure-Funktionen unterstützt werden.

Das ist auch für unsere Abbildung relevant: Im Private-Endpoint-Subnetz ist eine Network Security Group dargestellt. Ihre bloße Zuordnung bedeutet jedoch nicht zwangsläufig, dass sämtliche darin definierten Regeln bereits für den Datenverkehr des Private Endpoints wirksam sind. Entscheidend ist, ob die entsprechende Unterstützung für Netzwerkrichtlinien auf dem Private-Endpoint-Subnetz aktiviert wurde und welche Regeln tatsächlich greifen.

Azure Private Link und die Zugriffsberechtigungen des Plattformdienstes

Für unser Szenario setzen wir voraus, dass die erforderlichen Netzwerkrichtlinien passend konfiguriert sind und die HTTPS-Kommunikation zwischen Backend-VM und Private Endpoint zulassen. Damit kann die Verbindung die private Zieladresse 10.10.3.5 erreichen. Am Private Endpoint wird die Kommunikation über die Azure-Private-Link-Infrastruktur zur zugeordneten Storage-Ressource vermittelt. Dabei handelt es sich nicht um eine gewöhnliche Weiterleitung zwischen zwei virtuellen Maschinen. Der Private Endpoint bildet vielmehr den kundenseitigen Eintrittspunkt in ein von Azure bereitgestelltes Konnektivitätsmodell, das die private Verbindung zu einem verwalteten Plattformdienst ermöglicht. Die interne technische Umsetzung dieses Übergangs ist für Administrator:innen nicht vollständig sichtbar. Insbesondere lässt sich der weitere Weg innerhalb der Microsoft-Dienstinfrastruktur nicht ohne Weiteres als Folge klassischer Router und Netzwerksegmente nachvollziehen.

Für die Netzwerkarchitektur sind deshalb vor allem die überprüfbaren Eigenschaften entscheidend: die private Zieladressierung, die Zuordnung des Private Endpoints zur vorgesehenen Storage-Ressource und die wirksamen Routing- und Sicherheitsvorgaben. Allerdings ist die erfolgreiche Herstellung einer Netzwerkverbindung noch nicht mit einer Berechtigung zum Zugriff auf die gespeicherten Daten gleichzusetzen. Auch über einen Private Endpoint muss die Anwendung die erforderlichen Authentifizierungs- und Autorisierungsanforderungen des Storage-Dienstes erfüllen. Dafür können beispielsweise Microsoft Entra ID und entsprechende rollenbasierte Berechtigungen verwendet werden.

Öffentlicher Netzwerkzugriff und die Grenzen privater Konnektivität

Ebenso bedeutet die Einrichtung eines Private Endpoints nicht automatisch, dass der öffentliche Netzwerkzugriff auf das Storage-Konto deaktiviert ist. Ob der Dienst zusätzlich über öffentliche Endpunkte erreichbar bleibt, hängt von dessen gesonderter Netzwerkkonfiguration ab. Private Konnektivität und die Einschränkung öffentlicher Zugriffsmöglichkeiten sind deshalb getrennt zu betrachten. Mit dem erfolgreichen Zugriff auf Azure Storage hat unsere Backend-Anwendung die benötigten Informationen abgerufen. Das Ergebnis kann nun innerhalb der Anwendung verarbeitet und anschließend über die bestehende Backend-Kommunikation an das Application Gateway zurückgegeben werden.

Der Private Endpoint stellt einen privaten Zugangspunkt innerhalb des kundenseitigen VNets bereit. Er ist weder eine Kopie des Plattformdienstes noch ein gewöhnlicher Router, sondern Bestandteil eines spezifischen Azure-Konnektivitätsmodells. Die private IP-Adresse beschreibt dabei den erreichbaren Netzwerkendpunkt, nicht den tatsächlichen Standort oder die interne Architektur des verwalteten Storage-Dienstes.

Schritt 9: Der Rückverkehr – Warum die Antwort nicht einfach denselben Weg zurücknimmt

Nachdem der Azure Storage-Dienst die angeforderte Operation verarbeitet hat, beginnt der Rückverkehr innerhalb unserer Beispielarchitektur. Aus Sicht der Anwendung entsteht nun die Antwort auf die ursprüngliche Anfrage des lokalen Clients. Auf Netzwerkebene handelt es sich allerdings nicht um ein einzelnes Paket, das den gesamten zuvor beschriebenen Kommunikationsweg in umgekehrter Richtung durchläuft. Vielmehr müssen wir erneut zwischen den drei eigenständigen Kommunikationsflüssen unterscheiden. Jeder dieser Flows besitzt eigene Kommunikationspartner, TCP-Verbindungszustände und gegebenenfalls eine separate TLS-Sitzung. Die Antworten werden deshalb zunächst innerhalb der jeweiligen Verbindung übertragen und anschließend von der beteiligten Anwendung beziehungsweise dem Reverse Proxy weiterverarbeitet.

Flow C – Rückverkehr vom Azure Storage-Dienst zur Backend-VM

Den Anfang bildet Flow C, die Kommunikation zwischen der Backend-VM 10.10.2.10 und dem Azure Storage-Dienst über den Private Endpoint 10.10.3.5. Der Storage-Dienst stellt die angeforderten Daten bereit. Die Antwort gelangt über die Azure-Private-Link-Infrastruktur und den zugeordneten Private Endpoint zurück zur Backend-VM. Aus Sicht der Anwendung erfolgt der Datenaustausch innerhalb der zuvor aufgebauten HTTPS-Verbindung.

Die TCP- und TLS-Verarbeitung sorgt dafür, dass die empfangenen Daten der entsprechenden Verbindung zugeordnet und auf Anwendungsebene verarbeitet werden können. In unserer Architektur verläuft diese Kommunikation über den vorgesehenen privaten Netzwerkpfad innerhalb des Spoke-VNets und die Private-Link-Anbindung. Die zentrale Azure Firewall im Hub ist an Flow C nicht beteiligt. Damit ist auch für den Rückverkehr dieses Kommunikationsabschnitts keine Weiterleitung über die zentrale Firewall vorgesehen.

Flow B – Die HTTP-Antwort der Backend-Anwendung

Nachdem die Backend-Anwendung die Daten des Storage-Dienstes erhalten hat, verarbeitet sie diese und erstellt die HTTP-Antwort für die ursprüngliche Benutzer:innenanfrage. Damit wird Flow B relevant: die eigenständige Backend-Kommunikation zwischen der virtuellen Maschine 10.10.2.10 und dem Application Gateway. Die Backend-VM überträgt ihre HTTP-Antwort über die bestehende beziehungsweise für diese Kommunikation verwendete HTTPS-Verbindung an das Application Gateway.

Dabei ist die Backend-VM aus Sicht der TCP-Verbindung der Server, während das Application Gateway als Client dieser Backend-Verbindung auftritt. Die Antwortpakete werden anhand der wirksamen Routinginformationen zum Application Gateway zurückgeführt. Auch für diesen Kommunikationsabschnitt gelten die Sicherheitsvorgaben des Backend-Subnetzes 10.10.2.0/24 und des Application-Gateway-Subnetzes 10.10.1.0/27. Die beteiligten Network Security Groups arbeiten zustandsbehaftet und können die Antwortpakete einer zuvor zugelassenen Verbindung zuordnen. Voraussetzung bleibt, dass die Netzwerkverarbeitung mit den geltenden Routing- und Sicherheitsvorgaben vereinbar ist.

Flow A – Rückübertragung zum lokalen Client über ExpressRoute

Das Application Gateway empfängt die Antwort der Backend-Anwendung und verarbeitet sie innerhalb seiner Reverse-Proxy-Funktion. Es leitet dabei nicht einfach die empfangenen TCP-Pakete unverändert an den ursprünglichen Client weiter. Vielmehr übernimmt es die HTTP-Antwort aus der Backend-Kommunikation und überträgt sie über die eigenständige clientseitige Verbindung. Damit gelangen wir zurück zu Flow A, der HTTPS-Kommunikation zwischen dem lokalen Client 10.1.0.25 und der privaten Frontend-Adresse 10.10.1.4 des Application Gateways. Das Application Gateway sendet die HTTP-Antwort über die bereits aufgebaute clientseitige TLS- und TCP-Verbindung an den lokalen Client. Die IP-Pakete dieses Kommunikationsabschnitts besitzen nun die Quelladresse 10.10.1.4 und die Zieladresse 10.1.0.25.

Die Rollen der beiden IP-Adressen haben sich gegenüber dem ursprünglichen Hinverkehr umgekehrt. Für die Zustellung dieser Antwort muss Azure eine passende Route zum lokalen Unternehmensnetzwerk 10.1.0.0/16 verwenden. In unserer Beispielarchitektur soll der Rückverkehr zunächst über die zentrale Azure Firewall im Hub und anschließend über das ExpressRoute Virtual Network Gateway zurück in das Unternehmensnetzwerk gelangen.

Symmetrisches Routing und Stateful Inspection der Azure Firewall

Diese Verkehrsführung ergibt sich jedoch nicht automatisch daraus, dass der Hinverkehr zuvor denselben Sicherheitskontrollpunkt passiert hat. IP-Routing trifft Weiterleitungsentscheidungen grundsätzlich anhand der jeweils wirksamen Routinginformationen für die aktuelle Zieladresse. Während beim Hinverkehr die Adresse 10.10.1.4 maßgeblich war, muss für den Rückverkehr nun die Erreichbarkeit des lokalen Clients 10.1.0.25 berücksichtigt werden. Dafür setzen wir voraus, dass die Routingkonfiguration des Application-Gateway-Subnetzes den vorgesehenen Weg zur Azure Firewall unterstützt. Insbesondere muss die für das lokale Unternehmensnetzwerk wirksame Route den Rückverkehr über den zentralen Sicherheitskontrollpunkt führen. Anschließend muss die Firewall ihrerseits über geeignete Routinginformationen verfügen, um die Antwort in Richtung des ExpressRoute-Gateways weiterzuleiten.

Hier zeigt sich die Bedeutung einer symmetrischen Verkehrsführung bei zustandsbehafteten Sicherheitskontrollen. Die Azure Firewall hat beim ursprünglichen Verbindungsaufbau den eingehenden TCP-Verkehr bewertet und entsprechende Zustandsinformationen angelegt. Erreichen die zugehörigen Antwortpakete dieselbe zustandsbehaftete Firewall-Verarbeitung, können sie der bereits zugelassenen Kommunikation zugeordnet werden. Würde der Rückverkehr dagegen einen anderen Weg nehmen und die Firewall umgehen, wäre die vorgesehene symmetrische Verkehrsführung nicht mehr gegeben. Eine solche Asymmetrie kann insbesondere bei komplexeren Routing- und Sicherheitsarchitekturen zu Verbindungsproblemen führen. Entscheidend ist dabei nicht allein, ob ein Ziel grundsätzlich erreichbar ist, sondern ob Hin- und Rückverkehr die für die jeweilige Verbindung erforderlichen Netzwerk- und Sicherheitsfunktionen konsistent durchlaufen.

Auch mögliche Adressübersetzungen müssen in einer solchen Analyse berücksichtigt werden. Für Flow A haben wir angenommen, dass die Azure Firewall keine SNAT-Operation durchführt. Deshalb bleiben die ursprünglichen IP-Adressen der clientseitigen Verbindung erhalten. Wäre dagegen eine Adressübersetzung aktiv, müsste die zustandsbehaftete Netzwerkverarbeitung zusätzlich die entsprechenden Übersetzungsinformationen für den Rückverkehr berücksichtigen.

Reverse-Proxy-Grenze und Abschluss des Anwendungsvorgangs

Eine andere Form der Verbindungsgrenze entsteht am Application Gateway. Dort werden keine IP-Adressen einer einzigen durchgehenden TCP-Verbindung lediglich übersetzt. Stattdessen verarbeitet der Reverse Proxy zwei voneinander unabhängige Transportverbindungen. Die Rückgabe einer HTTP-Antwort von Flow B an Flow A erfolgt daher auf Anwendungsebene und nicht durch die bloße Umkehr einer IP-Weiterleitungsentscheidung. Nachdem die Antwortpakete von Flow A die Azure Firewall passiert haben, werden sie über das ExpressRoute Virtual Network Gateway und die private ExpressRoute-Verbindung in Richtung des Unternehmensnetzwerks weitergeleitet. Dort sorgen die lokalen Routinginformationen für die Zustellung an den Client 10.1.0.25, der die HTTPS-Antwort schließlich empfängt.

Damit ist die ursprüngliche Anwendungsanforderung erfolgreich abgeschlossen. Technisch betrachtet haben wir jedoch drei unterschiedliche Kommunikationsabschnitte durchlaufen, deren Antworten jeweils innerhalb ihrer eigenen Verbindungen übertragen wurden. Erst die Verarbeitung durch die Backend-Anwendung und das Application Gateway stellt den funktionalen Zusammenhang zwischen ihnen her. Eine funktionierende Anwendung setzt nicht nur voraus, dass ihre jeweiligen Ziele erreichbar sind. Auch die Antwortwege müssen mit den wirksamen Routinginformationen, Sicherheitsrichtlinien und Verbindungszuständen sämtlicher beteiligter Kommunikationsabschnitte vereinbar sein. Die drei Flows unserer Architektur bilden deshalb einen gemeinsamen Anwendungsvorgang, aber keinen einzigen durchgehenden Netzwerkfluss.

Schritt 10: Diagnose und Beobachtbarkeit – Was wir über die Kommunikation tatsächlich wissen können

Nachdem wir die Anwendungskommunikation vom lokalen Unternehmensnetzwerk über ExpressRoute, die Azure Firewall und das Application Gateway bis zum Azure Storage-Dienst nachvollzogen haben, stellt sich abschließend eine wichtige Frage: Welche dieser Vorgänge können Administrator:innen tatsächlich überprüfen? Unsere Beispielarchitektur besteht aus drei eigenständigen Kommunikationsflüssen. Jeder dieser Flows besitzt eigene Netzwerkendpunkte, Routingentscheidungen, Sicherheitskontrollen und Verbindungszustände. Für eine belastbare Diagnose reicht es deshalb nicht aus, lediglich die Erreichbarkeit der Anwendung oder den Zustand einer einzelnen Azure-Ressource zu untersuchen. Vielmehr müssen wir die unterschiedlichen Informationsquellen miteinander verbinden. Dabei greifen wir auf die Diagnoseprinzipien aus dem Kapitel ‚Netzwerkdiagnose in Azure‘ zurück.

DNS-Auflösung und Analyse der wirksamen Azure-Routen

Den Ausgangspunkt bildet erneut die Namensauflösung. Auf dem lokalen Client 10.1.0.25 lässt sich überprüfen, ob der Anwendungsname app.contoso.local tatsächlich zur privaten Frontend-Adresse 10.10.1.4 des Application Gateways aufgelöst wird. Eine abweichende DNS-Antwort würde bereits die Grundlage für den vorgesehenen Kommunikationsweg verändern. Eine vergleichbare Prüfung ist auf der Backend-VM 10.10.2.10 erforderlich. Dort muss der verwendete DNS-Name des Azure Storage-Dienstes über die private Namensauflösung zur Adresse 10.10.3.5 des zugeordneten Private Endpoints führen. Auf diese Weise lässt sich nachvollziehen, ob Flow C tatsächlich den vorgesehenen privaten Zielendpunkt verwendet. Eine erfolgreiche Namensauflösung bestätigt allerdings zunächst nur, welche IP-Adresse der jeweilige Client erhalten hat. Sie beweist weder die tatsächliche Erreichbarkeit des Ziels noch die erfolgreiche Verarbeitung einer späteren HTTPS-Anfrage.

Für die Untersuchung der Routingentscheidungen stehen weitere Diagnosemöglichkeiten zur Verfügung. Auf den Netzwerkschnittstellen unterstützter Azure-VMs lassen sich die wirksamen Routen mithilfe von Effective Routes analysieren. Damit können wir beispielsweise untersuchen, welche Routinginformationen für die Backend-VM 10.10.2.10 gelten und wie Azure deren Kommunikation zu bestimmten Zieladressen grundsätzlich weiterleiten soll. Mit der Funktion Next Hop aus Azure Network Watcher lässt sich für unterstützte virtuelle Maschinen prüfen, welcher logische nächste Weiterleitungspunkt für eine bestimmte Zieladresse ermittelt wird. Das kann helfen, unerwartete Verkehrslenkungen über virtuelle Netzwerkfunktionen oder abweichende Routingkonfigurationen zu erkennen. Allerdings müssen wir die Grenzen dieser Werkzeuge berücksichtigen. Die Routinginformationen einer Backend-VM beschreiben nicht automatisch die wirksamen Weiterleitungsentscheidungen des ExpressRoute Virtual Network Gateways oder des Application Gateways. Diese Dienste besitzen eigene Netzwerk- und Diagnosemechanismen. Insbesondere können wir die vollständige Verkehrsführung von Flow A nicht allein aus den Effective Routes einer beliebigen VM ableiten.

ExpressRoute, Azure Firewall und NSG-Regeln überprüfen

Für die hybride Verbindung müssen deshalb auch die Informationen der ExpressRoute-Anbindung berücksichtigt werden. Dazu gehören beispielsweise der Zustand der Verbindung, die BGP-Sitzungen und die zwischen den beteiligten Netzwerken ausgetauschten Routingpräfixe. Sie helfen zu überprüfen, ob die erwarteten Unternehmens- und Azure-Adressbereiche über die private Verbindung bekannt sind. Ob der Datenverkehr tatsächlich die vorgesehene Azure Firewall erreicht und dort zugelassen wird, lässt sich anhand der entsprechenden Diagnose- und Protokollierungsinformationen untersuchen.

Für Flow A interessieren uns insbesondere Verbindungen vom lokalen Client 10.1.0.25 zur privaten Frontend-Adresse 10.10.1.4 auf TCP-Port 443. Die Firewall-Protokolle können Hinweise darauf liefern, welche Regel angewendet wurde und ob die betreffende Kommunikation zugelassen oder blockiert wurde. Auch die verteilten Sicherheitskontrollen müssen berücksichtigt werden. Mit Effective Security Rules lassen sich die wirksamen NSG-Regeln unterstützter VM-Netzwerkschnittstellen untersuchen. IP Flow Verify ermöglicht für unterstützte VM-Szenarien eine gezielte Prüfung, ob ein bestimmter Kommunikationsfluss anhand der wirksamen NSG-Regeln erlaubt oder verweigert würde.

Application Gateway, WAF und Backend-Erreichbarkeit analysieren

Diese Funktionen sind jedoch nicht mit einer universellen Diagnose sämtlicher Azure-Netzwerkdienste gleichzusetzen. Insbesondere lässt sich die NSG-Verarbeitung des Application Gateways oder eines Private Endpoints nicht ohne Weiteres mit denselben VM-bezogenen Prüfverfahren untersuchen. Hier müssen die jeweiligen Ressourcenkonfigurationen, Netzwerkrichtlinien und verfügbaren Diagnoseinformationen ergänzend betrachtet werden. Am Application Gateway verändert sich die Perspektive erneut. Während die bisherigen Prüfungen überwiegend die Netzwerkerreichbarkeit und Sicherheitsverarbeitung betreffen, können wir hier zusätzlich die Verarbeitung auf Anwendungsebene untersuchen.

Die Diagnoseinformationen des Application Gateways ermöglichen unter anderem Rückschlüsse auf eingehende HTTP-Anfragen, deren Verarbeitung und die Erreichbarkeit der konfigurierten Backend-Ziele. Informationen zum Backend-Zustand und zu den Health Probes helfen dabei, Probleme bei der Auswahl oder Erreichbarkeit der virtuellen Maschinen 10.10.2.10 und 10.10.2.11 einzugrenzen. Ist eine Web Application Firewall aktiviert, können die entsprechenden WAF-Protokolle zusätzliche Hinweise auf erkannte Angriffsmuster, angewendete Regeln und gegebenenfalls blockierte HTTP-Anfragen liefern. Damit lässt sich auch die Grenze zwischen Flow A und Flow B untersuchen. Eine erfolgreiche clientseitige HTTPS-Verbindung zum Application Gateway bedeutet nicht zwangsläufig, dass die Backend-Anwendung erreichbar ist. Ebenso kann ein Backend als grundsätzlich gesund eingestuft werden, obwohl eine bestimmte HTTP-Anfrage aufgrund eines Anwendungsfehlers nicht erfolgreich verarbeitet wird.

Auf der Backend-VM stehen uns schließlich klassische Diagnoseverfahren zur Verfügung. Dazu gehören beispielsweise die Untersuchung aktiver Netzwerkverbindungen, Betriebssystemprotokolle und gezielte Paketmitschnitte. Mit geeigneten Flow Logs können zusätzlich Informationen über beobachtete Kommunikationsbeziehungen bereitgestellt werden, sofern die entsprechende Protokollierung für die beteiligten Ressourcen unterstützt und aktiviert ist. Diese Informationen sind besonders hilfreich, um Flow B und Flow C voneinander zu unterscheiden. Auf der Backend-VM können wir einerseits die eingehende Verbindung des Application Gateways beobachten und andererseits die von der Anwendung initiierte HTTPS-Verbindung zum Private Endpoint 10.10.3.5.

Private Endpoint und die Grenzen der Paketbeobachtung

Ein Paketmitschnitt auf der virtuellen Maschine zeigt allerdings nur die Kommunikation aus Sicht dieses Erfassungspunkts. Er liefert kein vollständiges Abbild der internen Azure-Weiterleitung und erlaubt insbesondere keine unmittelbaren Rückschlüsse auf sämtliche physischen Netzwerkkomponenten, die an der Verarbeitung beteiligt sind.

Besonders deutlich wird diese Grenze beim Übergang zum Azure Private Endpoint. Wir können überprüfen, ob der Storage-Dienstname zur privaten Adresse 10.10.3.5 aufgelöst wird, ob die Backend-VM eine Verbindung zu dieser Adresse aufbauen kann und ob die Anwendung eine gültige Antwort vom Storage-Dienst erhält.

Zusätzlich lassen sich die Konfiguration und der Verbindungszustand des Private Endpoints sowie die relevanten Netzwerk- und Zugriffsrichtlinien des Storage-Kontos untersuchen. Daraus ergibt sich jedoch kein vollständiges Bild der internen Verarbeitung innerhalb der Azure-Private-Link- und Storage-Infrastruktur.

Systematische Fehleranalyse entlang von Flow A, Flow B und Flow C

Gerade hier müssen wir zwischen einer erfolgreichen Netzwerkverbindung und einer erfolgreichen Dienstoperation unterscheiden. Eine Backend-VM kann den Private Endpoint erreichen und dennoch beim Zugriff auf den Storage-Dienst scheitern, beispielsweise aufgrund fehlender Berechtigungen, einer fehlerhaften Authentifizierung oder eines Problems bei der angeforderten Storage-Operation. Für die Analyse unserer gesamten Architektur ergibt sich daraus eine wichtige methodische Konsequenz: Wir sollten die drei Kommunikationsflüsse jeweils an ihren eigenen Übergabepunkten untersuchen:

• Bei Flow A betrachten wir die DNS-Auflösung des lokalen Clients, die hybride ExpressRoute-Konnektivität, die Verkehrslenkung über die Azure Firewall und die Erreichbarkeit des Application Gateways.
• Bei Flow B untersuchen wir die Backend-Auswahl des Application Gateways, den Zustand der Backend-Ziele, die Netzwerksicherheitsregeln und die tatsächliche Kommunikation mit der ausgewählten virtuellen Maschine.
• Bei Flow C stehen die private DNS-Auflösung, die Erreichbarkeit des Private Endpoints, die Netzwerkrichtlinien und die erfolgreiche Verarbeitung der Storage-Anforderung im Mittelpunkt.

Diese Trennung verhindert, dass wir aus einem einzelnen erfolgreichen Prüfergebnis zu weitreichende Schlussfolgerungen ziehen. Eine vorhandene Route garantiert noch keine zulässige Verbindung. Eine erlaubende NSG-Regel beweist nicht, dass ein Dienst tatsächlich erreichbar ist. Und eine erfolgreich aufgebaute TCP-Verbindung sagt noch nichts darüber aus, ob die Anwendung die angeforderte Operation korrekt verarbeitet.

Konfigurationszustand, Protokolldaten und tatsächliches Anwendungsverhalten

Ebenso wichtig ist die zeitliche Zuordnung der Diagnoseinformationen. Routingtabellen und Sicherheitsregeln beschreiben einen bestimmten Konfigurationszustand. Protokolle dokumentieren dagegen beobachtete Ereignisse, sofern die erforderliche Erfassung aktiviert war. Eine spätere Konfigurationsprüfung muss deshalb nicht zwangsläufig den Zustand widerspiegeln, der zum Zeitpunkt eines zuvor aufgetretenen Fehlers wirksam war.

Die vollständige Kommunikation lässt sich nicht durch eine einzelne Diagnosefunktion erklären. Erst die Verbindung aus Namensauflösung, Routinganalyse, Sicherheitsprüfung, beobachtetem Datenverkehr und tatsächlichem Anwendungsverhalten ergibt ein belastbares Gesamtbild. In Azure bedeutet Netzwerkdiagnose deshalb weniger, jeden physischen Weiterleitungsschritt sichtbar zu machen, als die relevanten logischen Entscheidungen und ihre Auswirkungen systematisch nachzuvollziehen.

Was uns die Reise durch Azure über moderne Netzwerke zeigt

Unsere beispielhafte Anwendungskommunikation hat uns durch nahezu alle wesentlichen Bereiche der Azure-Netzwerkarchitektur geführt. Was aus Sicht des lokalen Clients wie eine gewöhnliche HTTPS-Anfrage erscheint, erweist sich bei genauerer Betrachtung als Zusammenspiel unterschiedlicher Netzwerkfunktionen, Sicherheitskontrollen und eigenständiger Kommunikationsverbindungen.

Am Anfang stehen die vertrauten Grundlagen der IP-Kommunikation: Namensauflösung, Adressierung und Routing. Über ExpressRoute erreicht der Datenverkehr die Azure-Umgebung, in der softwaredefinierte Routinginformationen den weiteren logischen Weg bestimmen. Die zentrale Azure Firewall kontrolliert die zugelassene Kommunikation, während innerhalb des Spoke-VNets zusätzliche Sicherheitsrichtlinien wirksam werden können. Am Application Gateway verändert sich schließlich die Art der Verarbeitung grundlegend. Der Reverse Proxy terminiert die eingehende HTTPS-Verbindung und vermittelt die Anfrage über eine eigenständige Backend-Verbindung an die Anwendung. Diese übernimmt anschließend selbst die Rolle eines Clients und greift über einen Private Endpoint auf Azure Storage zu.

Besonders aufschlussreich ist dabei die Unterscheidung zwischen unseren drei Kommunikationsflüssen. Flow A verbindet das lokale Unternehmensnetzwerk mit dem Application Gateway, Flow B das Application Gateway mit der Backend-Anwendung und Flow C die Anwendung mit dem Azure Storage-Dienst. Aus fachlicher Sicht gehören alle drei Verbindungen zu einem einzigen Anwendungsvorgang. Auf Netzwerkebene besitzen sie jedoch unterschiedliche Kommunikationspartner, Adressen, Verbindungszustände und Sicherheitsbedingungen. Der Erfolg einer Verbindung garantiert deshalb nicht automatisch die Funktionsfähigkeit der nachfolgenden Kommunikation.

Azure-Netzwerkfunktionen und die Grenzen der physischen Topologie

Ebenso deutlich wird, dass die beteiligten Azure-Technologien unterschiedliche Aufgaben erfüllen. VNet Peering stellt logische Konnektivität bereit, während Routinginformationen den vorgesehenen Weiterleitungsweg bestimmen. Die Azure Firewall und Network Security Groups kontrollieren Netzwerkverkehr auf unterschiedlichen Ebenen der Architektur. Das Application Gateway verarbeitet HTTP-Kommunikation als Reverse Proxy, während Azure Private Link den privaten Zugang zu einem verwalteten Plattformdienst ermöglicht. Keine dieser Funktionen lässt sich allein durch ihre Position in einer Architekturzeichnung vollständig erklären.

Daraus ergibt sich eine weitere grundlegende Erkenntnis: Die logische Netzwerkarchitektur ist nicht mit einer unmittelbar sichtbaren physischen Topologie gleichzusetzen. Azure abstrahiert große Teile der zugrunde liegenden Infrastruktur und setzt Routing- und Sicherheitsentscheidungen innerhalb einer softwaredefinierten Netzwerkumgebung um. Die grundlegenden Prinzipien der IP-Kommunikation bleiben dabei erhalten. Was sich verändert, sind die Mechanismen ihrer Bereitstellung und die Möglichkeiten, ihre technische Umsetzung nachzuvollziehen.

Was moderne Cloud-Netzwerke von Administrator:innen verlangen

Für Administrator:innen bedeutet das eine veränderte Herangehensweise. Nicht mehr die Untersuchung einzelner Router, Switches oder Firewall-Geräte steht zwangsläufig im Mittelpunkt, sondern das Verständnis der gesamten Kommunikationsbeziehung. Dazu gehört, die wirksamen Routinginformationen und Sicherheitsrichtlinien ebenso zu berücksichtigen wie die Grenzen zwischen eigenständigen Verbindungen und das tatsächlich beobachtbare Verhalten der beteiligten Dienste.

Unsere Paketreise zeigt damit vor allem eines: Wer Azure-Netzwerke verstehen und zuverlässig analysieren möchte, muss über die einzelnen Ressourcen hinausdenken und die Zusammenhänge zwischen Adressierung, Weiterleitung, Sicherheitsverarbeitung und Anwendungskommunikation erkennen. Erst aus diesem Gesamtbild wird eine komplexe Cloud-Architektur technisch nachvollziehbar.

Die Netzwerktechnik verschwindet nicht, sie verändert ihre Gestalt

Wer bis zu diesem Kapitel vorgedrungen ist, hat bereits eine beachtliche Leseleistung erbracht. Hinter uns liegen zahlreiche Seiten über IP-Adressierung, virtuelle Netzwerke, Routing, Sicherheitsarchitekturen, hybride Konnektivität und die Besonderheiten verwalteter Azure-Dienste. Wir haben uns mit Technologien beschäftigt, deren Funktionsweise sich nicht immer auf den ersten Blick erschließt, und sind schließlich einer HTTPS-Anfrage durch eine komplexe Azure-Netzwerkarchitektur gefolgt. Wer bis hierhin dabeigeblieben ist, hat nicht nur Ausdauer bewiesen, sondern offenbar auch den Anspruch, über die bloße Konfiguration von Azure-Ressourcen hinauszublicken und die technischen Zusammenhänge dahinter wirklich zu verstehen.

Genau darum ging es mir in diesem Beitrag. Nicht um eine möglichst vollständige Aufzählung von Azure-Diensten oder eine weitere Schritt-für-Schritt-Anleitung für das Azure-Portal, sondern um die Frage, wie Netzwerktechnik in einer softwaredefinierten Cloud-Umgebung tatsächlich funktioniert.

Vertraute Netzwerkprinzipien in einer neuen Architektur

Wer sich über viele Jahre mit klassischen Netzwerkinfrastrukturen beschäftigt hat, verbindet Netzwerktechnik häufig mit einer unmittelbar nachvollziehbaren physischen Umgebung. Router verbinden unterschiedliche IP-Netze, Switches transportieren Ethernet-Frames innerhalb lokaler Netzwerke und Firewalls kontrollieren den Datenverkehr zwischen Sicherheitszonen. Netzwerkverbindungen lassen sich über Schnittstellen, Routingtabellen und Paketmitschnitte untersuchen. Die technische Architektur ist dabei eng mit den eingesetzten Geräten und ihrer Verkabelung verbunden.

In Microsoft Azure begegnen uns dieselben grundlegenden Aufgaben in einer anderen Form. Virtuelle Netzwerke stellen logische Adressräume bereit, Routingentscheidungen werden innerhalb einer softwaredefinierten Infrastruktur umgesetzt und Sicherheitsrichtlinien können unmittelbar im verteilten Datenpfad durchgesetzt werden. Verwaltete Netzwerkdienste übernehmen Funktionen, für die in klassischen Umgebungen häufig eigenständige Systeme erforderlich waren.

Auf den ersten Blick könnte dadurch der Eindruck entstehen, dass Netzwerktechnik in der Cloud an Bedeutung verliert. Schließlich müssen Administrator:innen keine physischen Switches konfigurieren, keine Router verkabeln und sich in vielen Fällen auch nicht um die zugrunde liegende Hardware kümmern. Doch dieser Eindruck täuscht. Die Netzwerktechnik verschwindet in der Cloud nicht. Sie wird auf andere Weise bereitgestellt, gesteuert und beobachtet.

IP-Adressen müssen weiterhin eindeutig zugeordnet werden. DNS entscheidet nach wie vor darüber, welche Zieladresse eine Anwendung verwendet. Routing bestimmt, wohin Datenverkehr weitergeleitet wird, und Sicherheitsrichtlinien legen fest, welche Kommunikation zulässig ist. TCP-Verbindungen besitzen weiterhin Zustände, TLS schützt die Kommunikation auf den dafür vorgesehenen Abschnitten und asymmetrische Verkehrswege können auch in einer Cloud-Architektur zu Problemen führen.

Abstraktion verändert die Technik, nicht die Verantwortung

Was sich verändert, ist vor allem die Beziehung zwischen logischer Funktion und physischer Umsetzung. Ein virtuelles Netzwerk ist kein klassisches Ethernet-Segment. Eine benutzerdefinierte Route erfordert keinen selbst betriebenen Router. Eine Network Security Group ist keine physische Firewall-Appliance. Und ein Private Endpoint bedeutet nicht, dass ein verwalteter Plattformdienst plötzlich innerhalb des eigenen virtuellen Netzwerks ausgeführt wird. Diese Unterschiede sind mehr als technische Feinheiten. Sie beeinflussen unmittelbar, wie wir Cloud-Architekturen entwerfen, absichern und im Fehlerfall analysieren.

Die Verantwortung für die physische Netzwerkinfrastruktur liegt weitgehend beim Cloud-Anbieter. Die Verantwortung für eine funktionierende logische Netzwerkarchitektur bleibt dagegen eine wesentliche Aufgabe derjenigen, die Azure-Umgebungen planen und betreiben. Dazu gehören eine durchdachte IP-Adressierung, geeignete Routingkonzepte, klar definierte Sicherheitszonen und ein Verständnis dafür, wie Anwendungen tatsächlich miteinander kommunizieren.

Gerade das Zusammenspiel der einzelnen Komponenten entscheidet über die Qualität einer Architektur. Ein korrekt konfiguriertes VNet garantiert noch keine funktionierende Anwendung. Eine vorhandene Firewall schützt nicht automatisch sämtliche Kommunikationswege. Und ein privater Endpunkt ist für sich genommen noch kein vollständiges Sicherheitskonzept. Erst wenn Adressierung, Konnektivität, Routing, Sicherheitsrichtlinien und Anwendungsverhalten aufeinander abgestimmt sind, entsteht eine belastbare Gesamtlösung.

Netzwerkkompetenz bleibt auch in der Cloud unverzichtbar

Für Administrator:innen und Netzwerkfachleute bedeutet der Wandel zur Cloud keinen Abschied von bewährtem Wissen, sondern dessen Weiterentwicklung. Wer die Grundlagen von TCP/IP, Routing, DNS und Netzwerksicherheit beherrscht, besitzt bereits einen wesentlichen Teil des fachlichen Fundaments. Hinzukommen muss das Verständnis der Azure-spezifischen Abstraktionen, ihrer technischen Möglichkeiten und ihrer Grenzen.

Auch die Fehlersuche verändert sich. Während wir in klassischen Netzwerken häufig den Weg eines Pakets über konkrete Geräte und Schnittstellen verfolgen, müssen wir in Azure stärker zwischen konfiguriertem Zustand, wirksamen Weiterleitungsentscheidungen und tatsächlich beobachtetem Kommunikationsverhalten unterscheiden. Nicht jeder interne Verarbeitungsschritt ist sichtbar. Umso wichtiger wird die Fähigkeit, unterschiedliche Diagnoseinformationen zu einem schlüssigen Gesamtbild zusammenzuführen.

Dabei bleibt eine Fähigkeit besonders wertvoll: technische Zusammenhänge zu erkennen und vermeintlich einfache Erklärungen kritisch zu hinterfragen. Eine private IP-Adresse ist nicht automatisch gleichbedeutend mit einem vollständig privaten Kommunikationsweg. Eine konfigurierte Route beweist noch nicht, dass der erwartete Datenverkehr tatsächlich diesen Weg nimmt. Und die erfolgreiche Erreichbarkeit eines Netzwerkendpunkts sagt noch nichts darüber aus, ob eine Anwendung ihre Aufgabe erfüllen kann. Wer diese Unterschiede versteht, kann Azure-Netzwerke nicht nur konfigurieren, sondern Architekturentscheidungen begründen, Sicherheitskonzepte bewerten und Fehler systematisch eingrenzen.

Entscheidend ist das Verständnis hinter den Ressourcen

Unsere Reise durch die Azure-Netzwerkarchitektur hat gezeigt, wie viele technische Entscheidungen sich hinter einer scheinbar einfachen HTTPS-Anfrage verbergen können. Zugleich wurde deutlich, dass sich auch komplexe Cloud-Netzwerke systematisch erschließen lassen, wenn die zugrunde liegenden Prinzipien verstanden werden. Darin liegt für mich eine der wichtigsten Erkenntnisse moderner Cloud-Netzwerktechnik: Die Abstraktion nimmt uns zahlreiche Aufgaben beim Betrieb der Infrastruktur ab, ersetzt aber nicht das Verständnis dafür, wie Netzwerkkommunikation tatsächlich funktioniert. Wer Netzwerke versteht, muss in der Cloud nicht bei null anfangen. Vielmehr gilt es, vorhandenes Wissen auf neue Architekturen zu übertragen, vertraute Konzepte kritisch zu hinterfragen und die technischen Mechanismen hinter den Azure-Ressourcen zu erkennen.

Wenn dieser umfangreiche Deep Dive neben den vielen technischen Einzelheiten vor allem eines vermittelt hat, dann hoffentlich die Erkenntnis, dass fundiertes Netzwerkwissen auch in einer softwaredefinierten Cloud-Umgebung unverzichtbar bleibt. Die Technologien verändern sich, die Möglichkeiten entwickeln sich weiter und manche vertraute Vorstellung muss neu eingeordnet werden. Doch die grundlegenden Zusammenhänge zwischen Adressierung, Kommunikation, Weiterleitung und Sicherheit behalten ihre Bedeutung. Denn auch in der Cloud entsteht eine zuverlässige Netzwerkarchitektur nicht allein durch das Bereitstellen von Ressourcen, sondern durch das Verständnis ihres Zusammenspiels.

Quellenangaben

(Abgerufen am 01. November 2026)

Azure-Netzwerkarchitektur und globale Microsoft-Infrastruktur

• Himani Chauhan (Uvation): Microsoft Azure 2026 News: Powering the Global Network
• Loqman Salamatian, Scott Anderson, Joshua Mathews, Paul Barford, Walter Willinger, Mark Crovella (CACM): A Manifold View of Connectivity in the Private Backbone Networks of Hyperscalers
• Mary Branscombe (Data Center Knowledge): Here’s How Microsoft Keeps the Cost of Its Network Backbone Down
• Microsoft Learn: Azure control plane and data plane
• Microsoft Learn: Azure network architecture
• Microsoft Learn: Azure network foundation services overview
• Microsoft Learn: Azure networking services overview
• Microsoft Learn: Azure subscription and service limits, quotas, and constraints
• Microsoft Learn: Microsoft global network
• Microsoft Learn: Reliability in Azure Virtual Network
• Microsoft Learn: What are availability zones?
• Microsoft Learn: What are Azure regions?
• Microsoft Learn: What is the Azure Well-Architected Framework?
• Microsoft: Microsoft Datacenters: Illuminating the unseen power of the cloud
• Yousef Khalidi (Microsoft): Microsoft’s open approach to networking

Hyperscale-Rechenzentren und physische Netzwerkinfrastruktur

• Cisco: What is a hyperscale data center?
• Francisco J. M. Rey (Microsoft): Microsoft Azure scales Hollow Core Fiber (HCF) production through outsourced manufacturing
• ITU Online: What Is Hyperscale Network Architecture?
• Phill Powell, Ian Smalley (IBM): What is a hyperscale data center?
• Reza Azizi (Pythian): Microsoft Fabric and Hollow Core Fiber: Driving the Next Generation of Data Analytics and Network Performance
• Tobias Mildenberger (Contabo): What is a Hyperscaler?

Wissenschaftliche Veröffentlichungen zur optischen Netzwerktechnik

• Jamie Gaudette, Tim Stuch (OPG): Open Undersea Cable Systems for Cloud Scale Operation
• Mark Filer, Hacene Chaouch (OPG): Transmission Performance of Layer-2/3 Modular Switch with mQAM Coherent ASIC and CFP2-ACOs over Flex-Grid OLS with 104 Channels Spaced 37.5 GHz
• Mark Filer, Hacene Chaouch, Xiaoxia Wu, Jamie Gaudette, Jeffrey L. Cox (OPG): Interoperation of Layer-2/3 Modular Switches with 8QAM/16QAM Integrated Coherent Optics over 2000 km Open Line System
• Mark Filer, Steven Searcy, Yang Fu, Radhakrishnan Nagarajan, Sorin Tibuleac (OPG): Demonstration and Performance Analysis of 4 Tb/s DWDM Metro-DCI System with 100G PAM4 QSFP28 Modules

Software-Defined Networking, Overlay-Netzwerke und Azure-Datenpfad

• Daniel Firestone et al. (Microsoft Research): Azure Accelerated Networking: SmartNICs in the Public Cloud (PDF-Datei)
• Daniel Firestone (Microsoft Research): VFP: A Virtual Switch Platform for Host SDN in the Public Cloud (PDF-Datei)
• GeeksforGeeks: Network Overlays in Distributed Systems
• IEEE: What Is an Overlay Network?
• Kezia Lawson-Shanks (PacketFabric): Overlay vs. Underlay Networks: What’s the Difference?
• Microsoft Learn: Azure Accelerated Networking overview
• Microsoft Learn: Microsoft Azure Boost
• Microsoft Learn: Microsoft Azure Network Adapter overview
• Paul Bryant (Digital Thought Disruption): Azure Arc + SDN: Control Plane Integration Explained
• Paul Bryant (LinkedIn): Why SDN in Azure Local Is a Game Changer for Hybrid Networks

Virtuelle Netzwerke, DNS, Routing und Peering

• Alkira: How does Azure Networking work?
• Eric Berg: [DEEP] Azure Networking Basics
• GeeksforGeeks: What is Azure Virtual Network Peering ?
• Kathleen Casey (TechTarget): 12 core Azure networking services you need to know
• Microsoft Learn: Azure DNS overview
• Microsoft Learn: Azure Local hyperconverged baseline reference architecture
• Microsoft Learn: Azure virtual network peering
• Microsoft Learn: Overview of Azure Virtual Network routing appliances
• Microsoft Learn: What is Azure NAT Gateway?
• Microsoft Learn: What is Azure Virtual Network?
• Rami Ayoub (DEV Community): Azure Networking from Zero to Enterprise — Part 1: Networking Basics
• Stanislas Quastana: Networking in Azure – the BIG Picture

Hybride Konnektivität, ExpressRoute, VPN und Virtual WAN

• Cisco: Modern Transit Architecture with Cisco Cloud OnRamp for Azure Virtual WAN (PDF-Datei)
• Jared Ross (Microsoft): ExpressRoute Global Reach: Building your own cloud-based global backbone
• JL Valente (Cisco): Introducing automated site-to-site connectivity over Microsoft’s global backbone network with Cisco SD-WAN Cloud Hub
• Microsoft Learn: About BGP and VPN Gateway
• Microsoft Learn: About ExpressRoute Direct
• Microsoft Learn: About ExpressRoute Metro
• Microsoft Learn: About ExpressRoute virtual network gateways
• Microsoft Learn: Global transit network architecture and Virtual WAN
• Microsoft Learn: Virtual WAN routing deep dive
• Microsoft Learn: What is Azure ExpressRoute?
• Microsoft Learn: What is Azure Virtual WAN?
• Microsoft Learn: What is Azure VPN Gateway?
• Microsoft Learn: What is hybrid connectivity?
• Microsoft Learn: Windows 365 Connectivity Principles
• Microsoft: Azure ExpressRoute – Preise
• Preston Romney (Microsoft): Connecting to Azure Services on the Microsoft Global Network
• Sunakshi Tickoo (Cisco): Deploy and manage networks globally with Cisco SD-WAN Multi-Region Fabric

Private Konnektivität, Private Link und Service Endpoints

• Microsoft Learn: Azure virtual network service endpoints
• Microsoft Learn: What is a network security perimeter?
• Microsoft Learn: What is a private endpoint?
• Microsoft Learn: What is Azure Private Link service?
• Microsoft Learn: What is Azure Private Link?

Netzwerksicherheit, Firewall und Web Application Firewall

• Microsoft Learn: Azure network security groups overview
• Microsoft Learn: What is Azure DDoS Protection?
• Microsoft Learn: What is Azure Web Application Firewall?
• Microsoft: Service Level Agreements (SLA) for Online Services

Lastverteilung, Application Delivery und globale Verkehrssteuerung

• Dave Rendon (Medium): Inside the AI-Ready Azure Network: A Deep Dive into the Latest Networking Innovations.
• Microsoft Learn: What is Azure Application Gateway?
• Microsoft Learn: What is Azure Front Door?
• Microsoft Learn: What is Azure Load Balancer?
• Microsoft Learn: What is Azure Traffic Manager?
• Sandeep Kaushik (Medium): Azure Load Balancer: An Introduction

Netzwerkdiagnose, Monitoring und Beobachtbarkeit

• Microsoft Learn: Azure Monitor overview
• Microsoft Learn: Traffic analytics overview
• Microsoft Learn: What is Azure Network Watcher?

Weiterführende Forschung und Fachmaterialien

• Royal Academy of Engineering (YouTube): Enabling the next generation of global internet connectivity - Microsoft Azure Fibre
• Surya Narayana Lankalapalli (IJISAE): Architectural and Innovation Perspective for Hyperscale Cloud Networking

Weiterbildung und Zertifizierung

• Microsoft Learn: AZ-700 Design and Implement Microsoft Azure Network Solutions
• Microsoft Learn: Microsoft Certified: Azure Network Engineer Associate

Weiterlesen hier im Blog

• ARPANET, TCP/IP und das World Wide Web – Wie das Internet die Welt vernetzte
• Azure Grundlagen: Architekturprinzipien, Identität, Governance und Best Practices für moderne Cloud-Umgebungen
• Externes Routing im Internet und WAN – Architektur, Historie und Bedeutung von BGP
• IPv6 ist längst da – warum Unternehmen trotzdem an IPv4 festhalten
• Von VLAN zu VXLAN – Segmentierung im Cisco-Netzwerk im Wandel der Zeit
• Wenn Pakete reisen lernen – Vermittlung und Transport im IP-Zeitalter