Zwei VNets benötigen private Kommunikation? Erstelle ein VNet-Peering

CloudTrips benötigt jetzt ein separates Netzwerk für gemeinsame Dienste. Ein eigenes VNet bietet diesen Diensten einen unabhängigen Adressraum und eine eigene Netzwerkgrenze. VNets bleiben jedoch isoliert, bis sie bewusst miteinander verbunden werden.

Erstelle ein VNet-Peering zwischen dem Anwendungs-VNet und einem neuen Dienste-VNet. Durch Peering verwenden Ressourcen ihre privaten IP-Adressen über das Microsoft-Backbone, ohne öffentliche IP, VPN-Gateway oder Internetpfad.

Peering führt die VNets nicht zusammen. Jedes VNet behält seine eigenen Subnetze, NSGs, Routentabellen und seine eigene Verwaltungsgrenze.

Dieser Trip baut auf folgendem Trip auf: Datenverkehr muss einen benutzerdefinierten Pfad verwenden? Erstelle eine Routentabelle.

Peering planen

Verwende:

Application VNet: vnet-cloudtrips-test-weu
Application address space: 10.20.0.0/16
Services VNet: vnet-cloudtrips-services-test-weu
Services address space: 10.40.0.0/16
Services subnet: snet-services
Services subnet range: 10.40.1.0/24
Region: West Europe

Die Bereiche überlappen sich nicht. Überlappende Adressräume können nicht gepeert werden, da Azure sonst nicht eindeutig bestimmen könnte, welchem VNet eine passende Zieladresse gehört.

Der vorherige Routentabellen-Trip blockierte nur 10.30.0.0/16. Er blockiert das neue Dienste-VNet 10.40.0.0/16 nicht, und Peeringrouten bleiben in rt-cloudtrips-app-test-weu aktiviert.

Dienste-VNet erstellen

Suche im Azure-Portal nach Virtual networks, öffne den Dienst und wähle Create.

Konfiguriere unter Basics:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: vnet-cloudtrips-services-test-weu
Region: West Europe

Füge unter Security für diese Übung weder Azure Bastion, Azure Firewall, einen DDoS-Schutzplan noch virtuelle Netzwerkverschlüsselung hinzu.

Lege unter IP Addresses fest:

IPv4 address space: 10.40.0.0/16
Subnet purpose/template: Default
Subnet name: snet-services
Starting address: 10.40.1.0
Subnet size: /24
Default outbound access: Disabled

Füge unter Tags hinzu:

Application: CloudTrips
Environment: TEST
Purpose: SharedServices

Wähle Review + create und anschließend Create.

Die zwei Peeringverbindungen verstehen

Die Kommunikation ist bidirektional, Azure stellt sie jedoch durch zwei gerichtete Peeringressourcen dar:

vnet-cloudtrips-test-weu
└── peer-app-to-services ──────► vnet-cloudtrips-services-test-weu

vnet-cloudtrips-services-test-weu
└── peer-services-to-app ──────► vnet-cloudtrips-test-weu

Da sich beide VNets in derselben Subscription befinden und du beide verwalten kannst, erstellt das Portal beide Verbindungen in einem Vorgang.

Peering hinzufügen

Öffne vnet-cloudtrips-test-weu, wähle Settings > Peerings und dann Add.

In diesem Formular bezeichnet Local virtual network das aktuell geöffnete Anwendungs-VNet. Remote virtual network bezeichnet das unten ausgewählte Dienste-VNet. Der lokale Peeringname lautet daher peer-app-to-services, der Remote-Peeringname peer-services-to-app.

Konfiguriere unter Remote virtual network summary:

Peering link name: peer-services-to-app
Subscription: CloudTrips TEST
Virtual network: vnet-cloudtrips-services-test-weu

Erlaube dem Remote-VNet den Zugriff auf vnet-cloudtrips-test-weu. Aktiviere weder weitergeleiteten Datenverkehr noch Gateway-/Route-Server-Transit. Diese Einstellungen werden erst benötigt, wenn ein anderes Gerät oder Gateway Datenverkehr durch ein VNet weiterleitet.

Konfiguriere unter Local virtual network summary:

Peering link name: peer-app-to-services

Erlaube vnet-cloudtrips-test-weu den Zugriff auf das Remote-VNet. Lasse auch hier weitergeleiteten Datenverkehr und Gateway-/Route-Server-Optionen deaktiviert.

Wähle Add.

Beide Richtungen überprüfen

Kehre zu Peerings zurück und wähle Refresh, bis peer-app-to-services den Status Connected anzeigt.

Öffne vnet-cloudtrips-services-test-weu > Settings > Peerings und bestätige, dass auch peer-services-to-app den Status Connected anzeigt.

Du kannst beide Ressourcen zusätzlich in Cloud Shell überprüfen:

az network vnet peering list \
  --resource-group rg-cloudtrips-network-test-weu \
  --vnet-name vnet-cloudtrips-test-weu \
  --query "[].{Name:name,State:peeringState,Access:allowVirtualNetworkAccess}" \
  --output table

az network vnet peering list \
  --resource-group rg-cloudtrips-network-test-weu \
  --vnet-name vnet-cloudtrips-services-test-weu \
  --query "[].{Name:name,State:peeringState,Access:allowVirtualNetworkAccess}" \
  --output table

Beide Ergebnisse sollten Connected und True anzeigen.

Peering stellt die private Route bereit, aber NSGs kontrollieren weiterhin, welche Verbindungen erlaubt sind. Anwendungen müssen außerdem auf den Zielports lauschen. Die Namensauflösung zwischen beiden VNets benötigt ein passendes DNS-Design. Im Dienste-VNet ist noch kein Workload vorhanden, daher überprüft dieser Trip die Peeringkonfiguration statt einer Anwendungsverbindung.