Was solltest du verwenden? ExpressRoute, Route Server, IPv6 und SNAT

Diese vier Technologien arbeiten an unterschiedlichen Stellen eines Netzwerks. Sie werden in Enterprise-Designs oft gemeinsam genannt, ersetzen einander aber nicht. Beginne mit dem Problem und wähle danach die passende Funktion.

Problem	Technologie	Was sie bereitstellt
Ein privater, planbarer Pfad von einem externen Netzwerk zu Microsoft-Clouddiensten	ExpressRoute	Private Provider-Konnektivität in das Microsoft-Netzwerk
Routen zwischen Azure und Routing-Appliances müssen sich dynamisch ändern	Azure Route Server mit BGP	Verwalteter Austausch von Netzwerkpräfixen und Next-Hop-Informationen
Anwendungen müssen mit IPv6-Clients oder -Netzwerken kommunizieren	IPv6 Dual Stack	IPv4- und IPv6-Adressierung und -Erreichbarkeit
Private Backends benötigen ausgehende Internetverbindungen über einen Public Load Balancer	Load-Balancer-SNAT	Quelladressübersetzung und einen begrenzten Pool ausgehender Ports

Die ersten beiden Themen betreffen Hybridkonnektivität und Routing. IPv6 betrifft das Adressierungsprotokoll. SNAT betrifft Identität und Portkapazität ausgehender Verbindungen.

ExpressRoute: Private Hybridkonnektivität lösen

Problem: Eine Organisation muss ein lokales Netzwerk, ein Colocation-Rechenzentrum oder ein vom Provider verwaltetes WAN mit Azure verbinden, ohne diesen Traffic über das öffentliche Internet zu senden.

ExpressRoute erweitert das externe Netzwerk über einen Connectivity Provider oder ExpressRoute Direct in die Microsoft Cloud. Der ExpressRoute Circuit ist die logische Verbindung an einem Peeringstandort. Azure Private Peering transportiert private IP-Routen zwischen dem externen Netzwerk und Azure-VNets; ein ExpressRoute Virtual Network Gateway verbindet ein VNet mit dem Circuit.

Die logischen Bestandteile verstehen

ExpressRoute ist weder ein einzelnes Kabel noch eine einzelne Azure-Ressource. Das End-to-End-Design besteht aus mehreren logischen Teilen:

Bestandteil	Aufgabe	Typischer Verantwortlicher
Kundenrouter	Verbinden LAN oder WAN der Organisation mit dem Provider, tauschen Routen über BGP aus und leiten Traffic zu ExpressRoute weiter	Kunde
Connectivity Provider	Stellt die private Verbindung vom Kundenstandort zu einem ExpressRoute-Peeringstandort bereit	Provider
Peeringstandort	Physische Einrichtung, an der der Connectivity Provider die Verbindung an Microsoft Edge übergibt. Dies ist normalerweise nicht der Ort, an dem das Büro des Kunden mit dem Provider verbunden wird, und keine Azure-Region. Bei ExpressRoute Direct verbindet sich der Kunde dort direkt mit Microsoft.	Provider und Microsoft
ExpressRoute Circuit	Logische Azure-Konnektivitätsressource, welche die gekaufte Bandbreite und Verbindung am Peeringstandort repräsentiert	Kundenkonfiguration, Microsoft-Dienst
Peering	Wird auf dem ExpressRoute Circuit konfiguriert und legt fest, was die Verbindung erreichen kann. Azure Private Peering verbindet das Kundennetzwerk mit privaten Adressen in Azure-VNets. Microsoft Peering verbindet es über öffentliche Adressen mit unterstützten Microsoft-Diensten.	Kunde und Microsoft
ExpressRoute Gateway	Verbindet ein oder mehrere Azure-VNets mit dem Circuit und überträgt Routen und Traffic zwischen ihnen	Kundenbereitstellung in Azure
VNet Connection	Logische Verknüpfung zwischen Gateway und Circuit	Kundenkonfiguration
Azure-VNet und Workloads	Private Azure-Adressräume, die über Azure Private Peering erreichbar werden	Kunde

Die Verbindung vom Kunden zum Provider und die Übergabe vom Provider an Microsoft sind zwei unterschiedliche Grenzen. Der Kunde verbindet sich zuerst an einem Kundenstandort oder Provider-Zugangspunkt mit dem Connectivity Provider. Der Provider transportiert den Traffic danach zum ExpressRoute-Peeringstandort und übergibt ihn dort an die Edge-Router von Microsoft.

Der Circuit beschreibt den privaten Konnektivitätsdienst, befindet sich aber nicht selbst in einem VNet. Er ist eine Azure-Ressource, die Providerverbindung, Bandbreite, Peering und Autorisierung koordiniert. Private Peering tauscht private Routen über diesen Circuit aus. Das ExpressRoute Gateway ist die Azure-seitige Brücke, die den Circuit mit einem VNet verbindet. Ohne gemeinsam funktionierenden Providerpfad, BGP-Peering, Gateway und VNet Connection liefert der Circuit allein keine End-to-End-Erreichbarkeit.

Peering wird auf dem ExpressRoute Circuit konfiguriert, normalerweise nachdem der Connectivity Provider ihn bereitgestellt hat. Es wird nicht auf dem VNet oder ExpressRoute Gateway konfiguriert. Der Circuit kann Azure Private Peering, Microsoft Peering oder bei erfüllten Anforderungen beides besitzen.

ExpressRoute verwendet BGP zum Routenaustausch. Es kann planbarere Latenz, Bandbreite und Verfügbarkeit als ein Internet-VPN liefern, aber privat bedeutet nicht automatisch verschlüsselt. Verschlüsselung und Trafficinspektion bleiben separate Designentscheidungen.

Wähle ExpressRoute, wenn:

• private, dauerhafte Hybridkonnektivität eine Geschäftsanforderung ist;
• planbare Performance oder höhere Bandbreite wichtig ist;
• viele Workloads Zugriff auf ein bestehendes Enterprise-WAN benötigen;
• die Organisation Provider-Circuit, BGP, Kosten und Betrieb verantworten kann.

Wähle es nicht nur, um einem Administrator privaten Zugriff auf eine VM zu geben. Site-to-Site VPN, Point-to-Site VPN, Bastion oder Private Link können ein kleineres Problem mit weniger Infrastruktur lösen.

Jeder Circuit besitzt redundante Verbindungen auf Microsoft-Seite. Ein Circuit an einem Peeringstandort ist jedoch noch kein vollständiges Disaster Recovery. End-to-End-Resilienz muss auch Kundenrouter, Providerpfade, Gateways, Peeringstandorte und möglicherweise einen zweiten Circuit oder ein VPN-Backup berücksichtigen.

Route Server und BGP: Dynamischen Routenaustausch lösen

Problem: Network Virtual Appliances (NVAs), VPN- oder ExpressRoute-Gateways und Azure-Netzwerke müssen wechselnde Routen lernen, ohne große User Defined Route Tables ständig manuell zu pflegen.

Eine Network Virtual Appliance (NVA) ist Netzwerksoftware, die als virtuelle Appliance in Azure ausgeführt wird. Sie erfüllt Aufgaben, die in einem Rechenzentrum ein physisches Netzwerkgerät übernehmen könnte—beispielsweise Routing, Firewalling, Trafficinspektion oder SD-WAN-Konnektivität. SD-WAN verbindet Standorte wie Büros, Rechenzentren und Azure über zentral verwaltete Netzwerkpfade. Es kann anhand von Verfügbarkeit und Richtlinien zwischen vorhandenen Verbindungen wählen—beispielsweise Breitband, privatem WAN oder Mobilfunk. NVAs werden häufig von Netzwerksicherheitsanbietern über Azure Marketplace angeboten.

Jeder Workload benötigt eine Route, die eine Frage beantwortet: Wohin soll ich ein Paket für dieses Ziel senden? In einem statischen Design schreiben Administratoren diese Antworten in Route Tables. Wenn sich Netzwerke oder verfügbare Pfade häufig ändern, wird die manuelle Pflege schwierig.

Mit BGP teilen Router diese Antworten automatisch. Ein Router kann ankündigen: „Sende Traffic für dieses Netzwerkpräfix zu mir.“ Wenn der Pfad nicht mehr verfügbar ist, kann er die Ankündigung zurückziehen.

Vereinfacht gesagt ist Azure Route Server der verwaltete BGP-Dienst von Azure. Er ist der verwaltete Austauschpunkt für Routinginformationen in einem Azure-VNet. Seine grundlegende Aufgabe ist:

1. Eine BGP-fähige NVA teilt Route Server mit, welche Netzwerke sie erreichen kann.
2. Route Server stellt diese gelernten Routen dem virtuellen Azure-Routingsystem bereit.
3. Azure-Workloads können die NVA anschließend als Next Hop für diese Ziele auswählen.
4. Route Server teilt der NVA in der Gegenrichtung mit, welche Azure-VNet-Präfixe erreichbar sind.
5. Fällt eine Appliance oder Route aus, kann BGP diesen Pfad zurückziehen und einen anderen ankündigen.

Route Server kann außerdem Routen zwischen BGP-fähigen NVAs und einem ExpressRoute- oder VPN-Gateway austauschen. Dadurch lernt die NVA externe Routen und das Gateway Pfade über die NVA, ohne jedes Präfix in manuellen Route Tables zu duplizieren.

Route Server gehört zur Control Plane: Er teilt mit, wo sich Netzwerke befinden und welche Pfade verfügbar sind. Er gehört nicht zur Data Plane, über die Anwendungspakete fließen. Route Server inspiziert, filtert, übersetzt und transportiert daher keinen Anwendungstraffic. Nachdem Azure eine Route ausgewählt hat, läuft das Paket direkt zum Next Hop dieser Route, beispielsweise zur NVA oder zum Gateway.

Verwende Route Server, wenn Routen dynamisch gelernt werden müssen oder BGP-fähige Appliances in Azure Routing integriert werden sollen. Verwende eine normale Route Table, wenn die Topologie klein und statisch ist und wenige explizite Routen leichter verständlich sind. Verwende Virtual WAN, wenn das größere Problem eine verwaltete globale Transitarchitektur für viele Standorte und Regionen ist.

IPv6: Adressierung und Erreichbarkeit lösen

Problem: IPv6-only- oder IPv6-bevorzugende Clients und Netzwerke müssen die Anwendung erreichen, oder die Organisation benötigt einen Adressplan, der nicht durch knappen IPv4-Adressraum eingeschränkt ist.

Azure unterstützt Dual-Stack-VNets und -Subnetze, sodass Ressourcen IPv4 und IPv6 verwenden können. Bei einem Dual-Stack-Dienst kann DNS einen A Record für IPv4 und einen AAAA Record für IPv6 veröffentlichen. Ein geeigneter Client wählt ein nutzbares Protokoll und verbindet sich mit dem entsprechenden Endpunkt.

Ein IPv6-Präfix allein macht eine Anwendung nicht IPv6-fähig. Der gesamte Pfad muss es unterstützen:

• VNet- und Subnetzadresspläne;
• NICs, Application Listener und Backenddienste;
• Public IPs sowie Load-Balancing-Frontends und -Regeln;
• NSGs, Routen, Firewalls und Inspection Appliances;
• DNS-AAAA-Records, Monitoring, Logging und Diagnose.

Azure-IPv6-Subnetze müssen ein /64-Präfix verwenden. IPv6 ist nur mit bewussten Kontrollen sicher; eine IPv4-only-Firewallregel schützt den IPv6-Pfad nicht automatisch. Auch die Dienstunterstützung ist uneinheitlich. Azure Route Server, Virtual WAN und Azure Firewall besitzen derzeit beispielsweise wichtige IPv6-Einschränkungen. Prüfe jede Komponente, statt aus IPv4-Unterstützung auf IPv6-Unterstützung zu schließen.

Verwende Dual Stack, wenn sowohl bestehende IPv4-Consumer als auch IPv6-Netzwerke bedient werden müssen. Dies ist meist ein sichererer Migrationspfad als IPv6-only-Betrieb, den nicht jeder Azure-Workload oder -Dienst unterstützt.

Load-Balancer-SNAT: Ausgehende Identität und Portteilung lösen

Problem: Private Backendinstanzen hinter einem öffentlichen Azure Load Balancer müssen Verbindungen zum Internet initiieren, und das Ziel muss eine öffentliche Quelladresse sehen.

NAT bedeutet Network Address Translation. Es ist das allgemeine Verfahren, IP-Adressinformationen beim Übergang zwischen Netzwerken zu verändern. SNAT und DNAT sind zwei Formen von NAT:

Übersetzung	Was sich ändert	Typische Richtung	Gelöstes Problem
SNAT—Source NAT	Quell-IP-Adresse und normalerweise Quellport	Ausgehend	Ermöglicht einem privaten Workload, eine Verbindung mit einer öffentlichen Quelladresse zu initiieren
DNAT—Destination NAT	Ziel-IP-Adresse und normalerweise Zielport	Eingehend	Leitet Traffic von einer öffentlichen Adresse zu einem privaten Ziel weiter

NAT ist somit der Oberbegriff und SNAT eine bestimmte NAT-Art. Azure NAT Gateway verwendet SNAT, um ausgehende Verbindungen für ein Subnetz bereitzustellen. Azure Load Balancer kann SNAT verwenden, um ausgehende Verbindungen für seinen Backend Pool bereitzustellen. Eine eingehende Load-Balancer-Regel ändert stattdessen das Ziel eines eingehenden Flows.

Source Network Address Translation (SNAT) ersetzt die private Quell-IP und den Quellport eines Backends durch die öffentliche IP des Load-Balancer- Frontends und einen zugewiesenen ephemeren Port.

Wähle die ausgehende Konnektivität bewusst:

• Load-Balancer-Outbound-Regel: Geeignet, wenn sich die VMs bereits im Backend Pool befinden und der Outboundbedarf relativ klein ist.
• NAT Gateway: Besser, wenn ein gesamtes Subnetz skalierbaren ausgehenden Internetzugriff benötigt.
• Private Link: Besser, wenn das Ziel ein Azure-PaaS-Dienst ist und der Traffic privat bleiben soll.