So funktioniert das Routing in Azure mit Systemrouten und User Defined Routes

Einführung

Azure legt für jedes Subnetz automatisch eine Routingtabelle an. In dieser ist standardmäßig eine Default Route enthalten. Diese Systemrouten lassen sich nicht löschen, können aber durch benutzerdefinierte Routen (Custom Routes) überschrieben werden. Azure verwendet diese Einträge, um den Datenverkehr aus einem Subnetz heraus zu steuern. Damit du das Routingverhalten nachvollziehen kannst, habe ich in diesem Beitrag die wichtigsten Prinzipien zusammengefasst.

Wie Default-Routen funktionieren?

Jede Route besteht aus einem Adresspräfix und einem Zieltyp, dem sogenannten Next Hop. Wenn Traffic ein Subnetz verlässt, prüft Azure die Zieladresse und gleicht sie mit den vorhandenen Präfixen in der Routingtabelle ab. Die am besten passende Route wird ausgewählt.

Standardmäßig gibt es die folgenden Arten von Next-Hop-Typen:

• Der Next-Hop-Typ Virtual Network ermöglicht die Kommunikation zwischen Subnetzen innerhalb desselben virtuellen Netzwerks.
• Beim Next-Hop-Typ Internet wird sämtlicher Traffic, der nicht zum internen Adressraum gehört, ins Internet weitergeleitet. Eine Ausnahme gilt für IP-Adressen, die Azure-Diensten zugewiesen sind. In diesem Fall bleibt der Datenverkehr innerhalb des Azure-Backbones, selbst wenn die Adresse eigentlich zum öffentlichen Adressraum gehört. Dieses Verhalten lässt sich bei Bedarf durch eigene Routen anpassen.
• Der Next-Hop-Typ None bedeutet, dass entsprechender Traffic einfach verworfen wird und das Subnetz nicht verlässt.

Bei der Verwendung spezifischer Funktionen können weitere Standardrouten angelegt werden:

• Wenn bspw. Virtual Network Peering verwendet wird, gelten automatisch neue Routen für alle Subnetze des jeweiligen Netzwerks.
• Wenn ein Virtual Network Gateway das Border Gateway Protocol (BGP) nutzt, legt Azure dynamisch weitere Routen an.
• Bei aktivierten Service Endpoints für bestimmte Azure-Dienste werden auch automatisch passende Routen mit dem Next-Hop-Typ VirtualNetworkServiceEndpoint erstellt. Da sich die öffentlichen IP-Bereiche dieser Dienste regelmäßig ändern, müssen wir durch die Verwendung von Service Endpoints und den zugehörigen Service Tags uns nicht um die Pflege der Adressbereiche kümmern.

Benutzerdefinierte Routen in Azure

In vielen Fällen entsprechen die Standardrouten nicht unseren Anforderungen, sodass wir eigene Routingregeln nutzen müssen. Diese benutzerdefinierten Routen (UDRs) kannst du entweder für einzelne Subnetze oder global für das gesamte virtuelle Netzwerk definieren. Eine Routingtabelle kann bis zu 400 benutzerdefinierte Routen enthalten und du kannst sogar mit dem Azure Virtual Network Manager bis zu 1000 Einträge nutzen.

Im Folgenden schauen wir uns die verschiedene Optionen für den Next-Hop-Typ einer benutzerdefinierten Route an.

Virtual Appliance

Wenn du Virtual Appliance auswählst wird der Traffic über eine spezifische private IP-Adresse weitergeleitet. Das ist in der Regel die IP eines Network-Interfaces einer VM, die als Weiterleitungseinheit fungiert. Um diese Funktion zu nutzen musst du dabei IP Forwarding für das jeweilige Network-Interface aktivieren. In speziellen Fällen musst du das IP Forwarding nicht nur im Azure Portal, sondern auch im Betriebssystem der VM einrichten.

Falls der Virtual Appliance Traffic an öffentliche IP-Adressen weiterleiten soll, ist zudem eine Netzwerknat (NAT) oder ein Proxy notwendig. Azure führt in diesem Fall die Übersetzung in eine öffentliche IP-Adresse durch, bevor der Traffic weiter ins Internet geleitet wird.

Weiterhin solltest du die Virtual Applicance in einem eigenen Subnet in deinem VNet erstellen, um eine Routing-Loop zu vermeiden.

Virtual Network Gateway

Wenn du den Next-Hop-Typ Virtual Network Gateway angibst, wird der Traffic aus dem VNet an ein VPN Gateway weitergeleitet.

Bei Gateways mit ExpressRoute Verbindungen ist die Verwendung von benutzerdefinierten Routen nicht möglich, da hier das Border Gateway Protocol die Weiterleitung übernimmt.

Ähnlich verhält es sich bei einer Kombinationen aus VPN- und ExpressRoute-Gateways. Dabei solltest du keine feste Route zum Gateway konfigurieren, sondern stattdessen auf BGP setzen. So lassen sich beispielsweise alle ausgehenden Verbindungen (0.0.0.0/0) über BGP an das Gateway übergeben.

None

Der Next-Hop-Typ None ermöglicht es dir, den Datenverkehr gezielt zu unterbinden. Wenn du in einer benutzerdefinierten Route diesen Typ auswählst, werden Pakete mit dem zugewiesenen Adresspräfix nicht weitergeleitet.

Diese Option ist besonders nützlich, wenn du bestimmte IP-Bereiche oder Ziele absichern möchtest. Auch für Zero-Trust-Ansätze oder stark segmentierte Netzwerke kann dieser Routingtyp eingesetzt werden, um den Datenfluss aktiv zu blockieren. Dabei musst du dafür keine zusätzliche Firewall oder NSG-Regeln erstellen.

Virtual Network

Mit dem Next-Hop-Typ Virtual Network kannst du das Standardverhalten der Azure-Systemrouten innerhalb eines VNets gezielt überschreiben. Standardmäßig erlaubt Azure die Kommunikation zwischen allen Subnetzen eines VNets. Das wird durch die systemseitige Default Route mit dem Zieltyp "Virtual Network" ermöglicht.

Wenn du jedoch in einer benutzerdefinierten Route ebenfalls "Virtual Network" als Zieltyp verwendest, kannst du bewusst eingreifen und das Routing innerhalb des Netzwerks neu steuern. Zum Beispiel kannst du erreichen, dass bestimmte IP-Bereiche bevorzugt über bestimmte Subnetze oder Appliances geleitet werden.

Internet

Wenn du in einer benutzerdefinierten Route den Next-Hop-Typ "Internet" auswählst, wird der zugehörige Datenverkehr gezielt ins öffentliche Internet geleitet. Wenn du explizit festlegen möchtest, dass bestimmte IP-Adressen oder IP-Bereiche nicht über Gateways oder Firewalls geroutet werden sollen, ist dieser Next-Hop-Type hilfreich.

Ein typisches Szenario wäre etwa, dass du nur spezifische Subnetze oder einzelne Workloads für den direkten Internetzugang freigibst, während der übrige Traffic über Appliances oder Gateways kontrolliert wird. Auch für Entwicklungs- oder Testumgebungen, bei denen keine zusätzliche Sicherheitsprüfung nötig ist, kann das sinnvoll sein.

Gleichzeitig bietet Azure mit Service Tags eine elegante Möglichkeit, den Datenverkehr zu bestimmten Azure-Diensten effizient zu steuern. Anstatt die jeweils gültigen IP-Adressbereiche selbst zu verwalten und in den Routingtabellen zu pflegen, kannst du einfach den entsprechenden Service Tag verwenden. In einer einzelnen Routingtabelle kannst du dabei bis zu 25 dieser Service Tags verwenden.

Was ist das Border Gateway Protocol?

Das Border Gateway Protocol (BGP) ist ein dynamisches Routing-Protokoll, um automatisch Netzwerke miteinander zu verbinden. Anstatt Routinginformationen manuell zu konfigurieren, tauschen die Netzwerke ihre Routen mithilfe von BGP untereinander aus. In Azure kommt dieses Verfahren bei VPN-Gateways und ExpressRoute-Verbindungen zum Einsatz.

Du betreibst beispielsweise ein lokales Firmennetzwerk und möchtest es entweder über ein VPN-Gateway oder eine ExpressRoute verbinden. Damit beide Seiten wissen, welche Netzwerke jeweils vorhanden sind und wie Datenverkehr korrekt weitergeleitet werden soll, müssen die Routen bekannt sein. Das Border Gateway Protokoll übernimmt diese Aufgabe automatisch und sorgt dafür, die internen On-Premise Netze und deine Azure VNet und Subnet Informationen ausgetauscht werden.

Ohne BGP müsstest du sowohl in deinem lokalen Netzwerk als auch in Azure alle relevanten Routen manuell eintragen. Das ist zwar grundsätzlich möglich, wird aber schnell aufwendig und fehleranfällig. Mit BGP wird dieser Prozess deutlich effizienter. Dein lokales Gateway teilt Azure automatisch mit, für welche Netzwerke es zuständig ist. Azure trägt diese Informationen automatisch in die Routingtabellen ein. Im Gegenzug erfährt auch dein lokales Gateway in deinem On-Premise Rechenzentrum, welche Netzbereiche in Azure vorhanden sind.

Noch wichtiger wird BGP bei ExpressRoute-Verbindungen, da hier ist der Einsatz des Protokolls verpflichtend. Sobald du dein Rechenzentrum über eine dedizierte ExpressRoute-Leitung mit Azure verbindest, kündigt dein Router die verfügbaren Routen über BGP an die Edge-Router von Microsoft an. Azure weiß dadurch automatisch, über welche Pfade der Datenverkehr geleitet werden kann.

Hierarchie von Azure Routen

Nachdem wir nun die verschiedenen Typen von Routen kennengelernt haben, stellt sich die Frage, wie Azure eigentlich entscheidet, welche Route genutzt wird, wenn eine virtuelle Maschine mit einer bestimmten Zieladresse kommunizieren möchte. Diese Entscheidung trifft Azure automatisch im Hintergrund, folgt dabei aber einer klaren Logik.

Azure verwendet immer die Route mit der längsten Präfixübereinstimmung. Das bedeutet, je spezifischer der Adressbereich einer Route ist, desto höher ist ihre Priorität.

Angenommen, in deinem virtuellen Netzwerk gibt es zwei Routen. Eine Route für den Bereich 10.0.0.0/16 zeigt ins Internet, eine andere für 10.0.0.0/24 führt zum virtuellen Netzwerk-Gateway. Wenn nun eine VM versucht, die IP-Adresse 10.0.0.5 zu erreichen, passen beide Routen theoretisch, aber Azure entscheidet sich für die Route mit dem Präfix /24, da dieser Bereich kleiner und damit präziser ist. Der Traffic wird also über das Gateway und nicht ins Internet geleitet.

Wenn allerdings mehrere Routen denselben Präfix verwenden greift eine zweite Regel. Azure ordnet den dann Routen eine Priorität nach ihrer Herkunft zu.

• An erster Stelle stehen benutzerdefinierte Routen, die du selbst in Routingtabellen eingetragen hast.
• Danach folgen dynamische BGP-Routen, die beispielsweise von einem VPN-Gateway stammen.
• Erst danach berücksichtigt Azure die systemseitigen Standardrouten.

Ein typisches Beispiel wäre dabei eine benutzerdefinierte Route für 0.0.0.0/0 die auf ein virtuelles Netzwerk-Gateway verweist. Gleichzeitig existiert eine systemseitige Route mit demselben Präfix die ins Internet zeigt. Wenn eine VM nun eine externe IP wie 8.8.8.8 ansprechen will, passen beide Routen. Da aber benutzerdefinierte Routen Vorrang haben, wird der Datenverkehr über das Gateway geleitet und nicht direkt ins Internet.

Was bedeutet 0.0.0.0/0 in Azure-Routingtabellen?

Die Route mit dem Präfix 0.0.0.0/0 nimmt in Azure eine besondere Rolle ein. Sie bestimmt wie ausgehender Datenverkehr aus einem Subnetz standardmäßig behandelt wird. Diese Route steht sinngemäß für alle IP-Adressen, die nicht durch spezifischere Routen abgedeckt sind. Sobald du ein Subnetz in Azure erstellst, wird diese Route automatisch angelegt.

Wenn eine virtuelle Maschine oder ein anderer Dienst eine Verbindung zu einer IP-Adresse außerhalb des eigenen Netzwerks aufbauen möchte, nutzt Azure diese Default Route, sofern keine genauere benutzerdefinierte Route existiert. Dabei zeigt die Route in der Regel ins öffentliche Internet.

Trotzdem verlässt der Datenverkehr nicht zwangsläufig die Azure-Plattform. Wenn du beispielsweise von einer VM aus auf einen Azure Storage Account oder eine Azure SQL-Datenbank zugreifst, wird der Traffic über den Azure Backbone geroutet. Obwohl 0.0.0.0/0 eigentlich auf das Internet verweist, wird der Datenverkehr intern über das Azure-Backbone geleitet und nicht ins öffentliche Netz übertragen. Diese intelligente Auflösung geschieht im Hintergrund und schützt den Datenfluss.

Du hast aber auch die Möglichkeit, die Standardroute selbst zu überschreiben. Erstellst du eine eigene Route mit dem Präfix 0.0.0.0/0, kannst du festlegen, dass aller ausgehender Traffic über ein VPN-Gateway, eine Firewall-Appliance oder eine ExpressRoute-Verbindung laufen soll. Dieses Prinzip wird in vielen produktiven Azure-Umgebungen eingesetzt, um ausgehenden Datenverkehr vollständig zu kontrollieren. Häufige Ziele sind Sicherheitsüberprüfungen über zentrale Firewalls oder das Unterbinden des direkten Zugriffs auf das öffentliche Internet.

Die Route 0.0.0.0/0 ist damit ein zentrales Werkzeug, wenn du Netzwerkverbindungen in Azure gezielt steuern oder absichern willst.

Worauf du beim Überschreiben von 0.0.0.0/0 achten solltest

Wenn du in Azure das Standardrouting änderst und den Datenverkehr über ein VNet-Gateway oder eine virtuelle Network Appliance (bspw. Firewall) leitest, musst du einige wichtige Dinge beachten. Fehler an dieser Stelle können dazu führen, dass dein Netzwerk nicht mehr erreichbar ist oder dass dein Gateway komplett ausfällt.

Wenn du ein VNet-Gateway als Nächsten Hop verwendest

Ein häufiger Fehler ist die Konfiguration einer benutzerdefinierten Route mit dem Präfix 0.0.0.0/0, die als nächstes Ziel ein VPN- oder ExpressRoute-Gateway angibt. Auf den ersten Blick mag das logisch erscheinen, schließlich möchtest du den gesamten Datenverkehr über das Gateway steuern. Kritisch wird es jedoch, wenn diese Route im GatewaySubnet eingetragen wird.

Das GatewaySubnet ist ein speziell reservierter Bereich innerhalb deines virtuellen Netzwerks, in dem Azure das Gateway bereitstellt. Azure nutzt dieses Subnetz intern für den Betrieb und die Verwaltung der Verbindung zur Außenwelt, zum Beispiel zu deinem On-Premises-Netzwerk oder ins Internet. Wenn du hier eine Routingregel mit 0.0.0.0/0 definierst, versucht das Gateway seinen eigenen Traffic über sich selbst zu routen. Dadurch verliert es die Fähigkeit, überhaupt noch mit externen Netzwerken zu kommunizieren.

Das kann zur Folge haben, dass VPN-Tunnel nicht mehr aufgebaut werden können, dass bestehende Verbindungen abbrechen oder dass das Gateway überhaupt nicht mehr erreichbar ist. Eine Routingtabelle mit einer Route für 0.0.0.0/0 darf daher niemals an das GatewaySubnet angehängt werden. Dieses Subnetz sollte grundsätzlich keine benutzerdefinierten Routen enthalten.

Wenn du eine virtuelle Appliance (bspw. Firewall) als Nächsten Hop angibst

Wenn du den ausgehenden Datenverkehr in Azure über eine virtuelle Appliance leitest, etwa eine Firewall übernimmt diese die Rolle eines zentralen Kontrollpunkts. Solche Appliances prüfen, filtern oder verarbeiten den Traffic bevor er an sein Ziel weitergeleitet wird. Häufig eingesetzte Lösungen sind hier die Azure Firewall oder Network Virtual Appliances von Drittanbietern.

Damit dieses Setup zuverlässig funktioniert, müssen einige Voraussetzungen erfüllt sein. Die Appliance selbst muss grundsätzlich erreichbar sein, wenn sie auch eingehenden Verkehr aus dem Internet oder aus einem On-Premises-Netzwerk verarbeiten soll. In diesen Fällen ist eine öffentliche IP-Adresse erforderlich, da sie ohne diese keine externen Verbindungen entgegennehmen kann.

Neben der Erreichbarkeit ist eine korrekte Konfiguration der Routingeinstellungen, Firewall-Regeln und NAT-Definitionen notwendig. Die virtuelle Appliance muss wissen, wie sie den eingehenden Datenverkehr behandeln und an interne Ziele wie virtuelle Maschinen im VNet weiterleiten soll. Gängige Verfahren zur Steuerung und Weiterleitung sind dabei Source NAT (SNAT), Destination NAT (DNAT) oder auch die Verwendung als Proxy.

Ein weiterer Punkt, den du im Blick behalten solltest, sind die Network Security Groups (NSGs). Auch wenn die Routinglogik korrekt ist, können restriktive NSG-Regeln den Datenverkehr blockieren. Du solltest daher sicherstellen, dass eingehender Traffic zur Network Appliance erlaubt ist, ebenso wie die Rückverbindung von der Appliance zu den Zielsystemen. Besonders Regeln wie Deny All am Ende einer NSG können verhindern, dass Daten überhaupt ankommen.

Ein funktionierendes Zusammenspiel zwischen Routing, Network Appliance und NSG-Regeln ist daher entscheidend, wenn du in Azure eine zentrale Network Appliance als Kontrollpunkt für den Datenverkehr nutzen willst.

Anwendungsbeispiel

Zum Abschluss möchte ich in diesem Kapitel ein Beispielszenario vorstellen und die jeweiligen Routing Optionen anwenden.

Beispiel-Szenario

Wir besitzen ein Virtuelles Netz mit dem Namen Virtual Network 1. In diesem VNet haben wir bereits mehrere Subnets für unterschiedliche Compute Ressourcen deployt. Dabei haben wir insgesamt vier Subnetze, die sich folgenderweise untergliedern:

• Subnet 1: Hier haben wir ein Container App Environment deployt, dass 2 Container Apps beinhaltet.
• Subnet 2: In diesem Subnet haben wir einen App Service Plan deployt, der ebenso 2 App Services enthält.
• Subnet 3: Dieses Subnet beinhaltet 2 virtuelle Maschinen.
• Subnet 4: Dieses Subnet haben wir speziell für die Verwendung einer Azure Firewall verwendet, um spezifischen egress Traffic abzufangen und mit Firewall Policies zunächst zu bewerten.

Wir wollen nun folgende Anforderungen an unser VNet erfüllen:

• Jeder outbound Traffic aus dem Subnet 3 soll zunächst an das Subnet 4 mit der Azure Firewall weitergeleitet werden.
• Die virtuellen Maschinen in Subnet 3 sollen über privaten IP Adressen miteinander kommunizieren können.
• Outbound Traffic aus dem Subnet 3 in das Subnet 1 und 2 soll abgelehnt werden.
• Subnet 1 und Subnet 2 sollen Storage Accounts direkt ansprechen können, ohne in Subnet 4 geroutet zu werden.

Lösung des Beispiel-Szenarios

Route Table für Subnet 1 und 2:

Erklärung der Routen:

• Kein zusätzlicher UDR erforderlich, da nur direkter Storage-Zugriff über Service Endpoints gefordert ist.
• Service Endpoint für Azure Storage ist bereits aktiviert, sodass Route ID dafür sorgt, dass Azure Storage Accounts auch ohne die Azure Firewall erreichbar sind.

Route Table für Subnet 3:

Erklärung der Routen:

• ID1: Diese Standardroute innerhalb des VNets wird durch ID5 (UDR) überschrieben.
• ID2: Erlaubt Kommunikation innerhalb von Subnet 3 (VM ↔ VM), wichtig für die direkte private Kommunikation in unserer zweiten Anforderung.
• ID3 & ID4: Blockieren gezielt Traffic aus Subnet 3 in Richtung Subnet 1 (10.0.0.0/24) und Subnet 2 (10.0.1.0/24) entsprechend unserer dritten Anforderung.
• ID5: Erzwingt, dass aller andere Traffic (bspw. ins Internet oder On-Prem über VPN/ExpressRoute) zur Azure Firewall in Subnet 4 weitergeleitet wird (10.0.4.4 als private IP der Firewall).

Zusammenfassung

Azure legt für jedes Subnetz automatisch Routingtabellen mit Standardrouten an, die das grundlegende Traffic-Verhalten im virtuellen Netzwerk bestimmen. Durch benutzerdefinierte Routen (User Defined Routes) kannst du dieses Verhalten gezielt anpassen, um Traffic über Gateways, Firewalls oder bestimmte Network Appliances zu leiten. Die Auswahl der jeweils genutzten Route basiert auf der längsten Präfixübereinstimmung, wobei benutzerdefinierte Routen immer Vorrang vor BGP- und Systemrouten haben.

Besonders relevant ist die Default Route 0.0.0.0/0, da sie für ausgehenden Datenverkehr steht. Diese kann überschrieben werden, um bspw. zentrale Sicherheitslösungen einzubinden oder Internetzugänge zu kontrollieren. Wichtig ist dabei ein sorgfältiger Umgang mit kritischen Subnetzen wie dem GatewaySubnet, das keine benutzerdefinierten Routen enthalten sollte.

Hilfreiche Links für weiterführende Recherchen:

• Routing von Datenverkehr für virtuelle Netzwerke: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
• Verwenden von SNAT für ausgehende Verbindungen: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections?toc=%2Fazure%2Fvirtual-network%2Ftoc.json
• Azure System-Routen und Benutzerdefinierte Routen:
  • https://learn.microsoft.com/de-de/azure/virtual-network-manager/how-to-create-user-defined-route
  • https://cloudbuild.co.uk/tag/azure-system-routes-vs-user-defined-routes/
  • https://prashanth-kumar-ms.medium.com/azure-user-defined-routing-d0a2dd1eefa6
• Azure Routing Grundlagen: https://www.azure-heros.com/blog/azure-routing-from-zero-to-hero-the-basic