VNet-Peering und Dienstendpunkte

Ressourcen in verschiedenen Azure-VNets können standardmäßig nicht miteinander kommunizieren – selbst wenn sie sich in derselben Azure-Region befinden. Große Organisationen verfügen jedoch häufig über mehrere VNets: separate VNets für Entwicklung, Staging und Produktion oder unterschiedliche VNets für verschiedene Abteilungen. VNet-Peering verbindet zwei VNets direkt über das private Backbone-Netzwerk von Microsoft. Dadurch können Ressourcen in beiden VNets miteinander kommunizieren, als befänden sie sich im selben Netzwerk – ohne dass Datenverkehr das öffentliche Internet durchläuft oder ein VPN-Gateway erforderlich ist.

VNet-Peering ist eine nicht transitive Verbindung: Wenn VNet A mit VNet B per Peering verbunden ist und VNet B mit VNet C verbunden ist, kann VNet A nicht mit VNet C kommunizieren, solange kein separates Peering zwischen A und C erstellt wird. Peeringverbindungen sind bidirektional, müssen jedoch auf beiden Seiten konfiguriert werden – durch das Erstellen eines Peerings von A nach B wird nicht automatisch eines von B nach A erstellt. Sobald beide Seiten konfiguriert sind, nutzt der Datenverkehr zwischen den per Peering verbundenen VNets das Azure-Backbone mit geringer Latenz und hoher Bandbreite, vergleichbar mit der Kommunikation zwischen Subnetzen innerhalb eines einzelnen VNets.

VNet-Peering bietet zwei Optionen für den Geltungsbereich: Lokales VNet-Peering verbindet zwei VNets in derselben Azure-Region. Der Datenverkehr bleibt innerhalb der Region, wobei eine geringe Gebühr pro übertragenem GB anfällt. Globales VNet-Peering verbindet zwei VNets in verschiedenen Azure-Regionen und wird über Microsofts globales Backbone geroutet. Dadurch können Ressourcen in East US privat mit Ressourcen in West Europe kommunizieren, ohne das öffentliche Internet zu durchlaufen. Globales Peering ist etwas teurer als lokales Peering, aber dennoch deutlich günstiger und zuverlässiger als das Routing über ein VPN.

Ein verbreitetes Muster in Unternehmen verwendet VNet-Peering zur Implementierung einer Hub-and-Spoke-Topologie. Ein zentrales Hub-VNet hostet gemeinsam genutzte Dienste: Azure Firewall, VPN Gateway, DNS-Server und Überwachung. Mehrere Spoke-VNets – jeweils eines pro Umgebung oder Workload – werden mit dem Hub per Peering verbunden. Wenn der gesamte Datenverkehr der Spokes über die Hub-Firewall geroutet wird, erhält die Organisation eine zentrale Sicherheitsüberprüfung, ohne dass in jedem Spoke eine komplexe NSG-Verwaltung erforderlich ist. Da Peering nicht transitiv ist, routet die Hub-Firewall den Datenverkehr zwischen den Spokes mithilfe von User-Defined Routes (UDRs).

VNet-Peering hat eine entscheidende Voraussetzung: Die Adressräume der per Peering verbundenen VNets dürfen sich nicht überschneiden. Wenn VNet A 10.0.0.0/16 verwendet und VNet B ebenfalls 10.0.0.0/16 nutzt, schlägt das Peering fehl, da Azure den Datenverkehr zwischen identischen Adressbereichen nicht routen kann. Deshalb ist es so wichtig, bereits vor Beginn für alle VNets – und für lokale Netzwerke – sich nicht überschneidende CIDR-Bereiche zu planen. Wenn Ressourcen bereits bereitgestellt wurden, erfordert das Ändern des Adressraums eines VNets eine Neuerstellung des VNets oder die Verwendung der (eingeschränkten) Funktion zum Hinzufügen bzw. Entfernen von Adressräumen.

Service Endpoints erweitern die Identität des VNets auf Azure-PaaS-Dienste wie Azure Storage, Azure SQL Database, Azure Key Vault und Cosmos DB. Wenn Sie einen Service Endpoint für ein Subnetz aktivieren, wird der Datenverkehr von Ressourcen in diesem Subnetz zum angegebenen Azure-Dienst über das Azure-Backbone statt über das öffentliche Internet geroutet – auch wenn die öffentliche IP-Adresse des Dienstes verwendet wird. Der Dienst kann den Zugriff anschließend auf Ressourcen in VNets beschränken, für die der Service Endpoint aktiviert ist. Das stellt eine deutliche Sicherheitsverbesserung gegenüber über das Internet erreichbaren Endpunkten dar.

Service Endpoints und Private Endpoints ermöglichen beide einen sicheren Zugriff auf Azure-PaaS-Dienste, funktionieren jedoch unterschiedlich: Service Endpoint – routet den Datenverkehr über das Azure-Backbone, verwendet aber weiterhin die öffentliche IP-Adresse des Dienstes; der Service Endpoint befindet sich auf Subnetzebene. Private Endpoint – weist dem Dienst eine private IP-Adresse aus Ihrem VNet zu; der öffentliche Endpunkt kann vollständig deaktiviert werden, sodass der Dienst tatsächlich privat ist. Private Endpoints bieten eine stärkere Isolation und können auch von lokalen Netzwerken über VPN/ExpressRoute erreicht werden. Für ein Höchstmaß an Sicherheit werden Private Endpoints bevorzugt; Service Endpoints sind eine einfachere und kostengünstigere Alternative.

Nachdem Sie einen Service Endpoint für ein Subnetz aktiviert haben, konfigurieren Sie den Azure-Dienst so, dass er nur Verbindungen aus diesem Subnetz akzeptiert. Bei einem Speicherkonto bedeutet dies, dass Sie in den Firewall-Einstellungen des Speicherkontos eine VNet-Regel hinzufügen. Nach dieser Änderung können nur VMs im angegebenen Subnetz das Speicherkonto erreichen – sämtlicher anderer Internetdatenverkehr wird abgewiesen. Dies ist eine schnelle und kostenlose Möglichkeit, die Sicherheit eines Speicherkontos deutlich zu verbessern, verglichen mit einer Freigabe für den gesamten Internetdatenverkehr. Das gilt insbesondere für Konten, in denen vertrauliche Anwendungsdaten gespeichert sind.

VNet-Integration – nicht zu verwechseln mit VNet-Peering – ermöglicht Azure App Service-Anwendungen, ausgehende Aufrufe an Ressourcen innerhalb eines VNets zu senden. Ohne VNet-Integration wird der ausgehende Datenverkehr eines App Service immer über das öffentliche Internet geleitet – selbst wenn Ressourcen wie Azure SQL oder Azure Cache for Redis im selben VNet aufgerufen werden. Bei aktivierter VNet-Integration wird der ausgehende Datenverkehr der App in das VNet geroutet und kann private Ressourcen erreichen. Dafür ist im VNet ein dediziertes delegiertes Subnetz mit einem Adressraum von mindestens /28 erforderlich.

Da VNet-Peering nicht transitiv ist, erfordert die Verbindung von mehr als zwei VNets entweder direktes Peering zwischen jedem Paar – mit einer Komplexität von O(n²) – oder einen zentralen Routing-Hub. In einem Hub-and-Spoke-Modell enthält das Hub-VNet eine Network Virtual Appliance (NVA) oder Azure Firewall, die als Transitrouter zwischen den Spoke-VNets fungiert. Jeder Spoke erhält eine UDR, die den gesamten Datenverkehr (0.0.0.0/0 oder bestimmte Spoke-CIDRs) an die IP-Adresse der NVA im Hub weiterleitet. Die NVA leitet den Datenverkehr anschließend an den richtigen Ziel-Spoke weiter und ermöglicht so effektiv eine transitive Verbindung über den Hub.

Wichtige Einschränkungen von VNet-Peering: Nicht überlappende Adressräume erforderlich – planen Sie die CIDR-Bereiche sorgfältig, bevor Sie VNets erstellen. Nicht transitiv – Peering zwischen A und B sowie zwischen B und C verbindet A und C nicht. Der Adressraum eines VNets kann nicht vergrößert oder verkleinert werden, wenn aktive Peerings vorhanden sind, ohne diese vorübergehend zu löschen. Gateway-Transit – Spoke-VNets können das VPN- oder ExpressRoute-Gateway im Hub-VNet verwenden, indem Sie in der Peering-Konfiguration „Use Remote Gateways“ aktivieren. Dafür muss das Hub-Gateway jedoch zuerst erstellt werden. Für den Entwurf skalierbarer und wartbarer Architekturen mit mehreren VNets ist es wichtig, diese Einschränkungen zu verstehen.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion zu Microsoft Azure Fundamentals (AZ-900).

In dieser Lektion haben Sie gelernt: VNet-Peering verbindet zwei VNets über Microsofts Backbone für private Kommunikation mit geringer Latenz und ohne VPN, ist jedoch nicht transitiv, Service Endpoints routen den Datenverkehr eines Subnetzes über das Backbone zu Azure-PaaS-Diensten, ohne ihn dem öffentlichen Internet auszusetzen, und Private Endpoints sind die leistungsfähigere Alternative: Sie weisen einem PaaS-Dienst eine private IP-Adresse zu, sodass der öffentliche Endpunkt vollständig deaktiviert werden kann. Als Nächstes beschäftigen wir uns mit den Grundlagen von Azure DNS und Load Balancer.