Das Büro benötigt eine private Azure-Verbindung? Erstelle ein VPN Gateway

CloudTrips benötigt einen sicheren Pfad zwischen dem Büronetzwerk und privaten Azure-Ressourcen. Wenn dieser Datenverkehr direkt über das Internet gesendet wird, ist der Verbindungspfad exponiert und das Büronetzwerk wird nicht in das Azure-Routing integriert.

Ein Azure VPN Gateway ist der Azure-seitige Endpunkt für verschlüsselte VPN-Tunnel. Es wird im Hub-VNet ausgeführt, damit mehrere Spoke-VNets ein Gateway gemeinsam verwenden können. Das Gateway besitzt eine öffentliche IP-Adresse zum Aufbau des Tunnels. Dadurch erhalten die Ressourcen in den Spokes jedoch keine öffentlichen IP-Adressen. Der Tunneldatenverkehr ist verschlüsselt.

Dieser Trip erstellt das Gateway und stellt es dem Anwendungs- und Dienste-Spoke bereit. Der eigentliche Site-to-Site-Tunnel benötigt Angaben zum VPN-Gerät des Büros und wird im nächsten Trip konfiguriert.

Dieser Trip baut auf folgendem Trip auf: Spoke-Netzwerke benötigen einen zentralen Hub? Konfiguriere ein Hub-Spoke-Netzwerk.

Azure-VPN-Endpunkt planen

Verwende:

Hub VNet: vnet-cloudtrips-hub-test-weu
Gateway subnet: GatewaySubnet
Gateway subnet range: 10.60.255.0/27
VPN gateway: vng-cloudtrips-hub-test-weu
Gateway type: VPN
VPN type: Route-based
SKU: VpnGw1AZ
Public IP: pip-cloudtrips-vng-test-weu
Active-active mode: Disabled
BGP: Disabled

VpnGw1AZ wird als kleinste AZ-fähige Gateway-SKU für diese TEST-Umgebung verwendet. Die Produktionsauswahl muss auf Verfügbarkeit, Tunnelanzahl, Durchsatz und den Funktionen des VPN-Geräts im Büro basieren.

VPN Gateway wird in Rechnung gestellt, solange die Ressource bereitgestellt ist. Die Erstellung dauert häufig 45 Minuten oder länger. Erstelle es nicht nur, um das Portalformular anzusehen.

GatewaySubnet erstellen

Ein VPN Gateway muss in einem Subnetz mit dem exakten Namen GatewaySubnet bereitgestellt werden. Dies ist nicht nur eine Namenskonvention: Azure verwendet den reservierten Namen, um das Subnetz für die Bereitstellung und Verwaltung der Gatewayinstanzen zu finden. Ein normal benanntes Subnetz wie snet-gateway wird nicht erkannt. Die Gatewayerstellung schlägt fehl, wenn GatewaySubnet nicht existiert. Platziere in diesem dedizierten Subnetz keine VMs oder anderen Ressourcen.

Öffne vnet-cloudtrips-hub-test-weu und wähle Settings > Subnets > + Subnet.

Konfiguriere:

Subnet purpose: Virtual Network Gateway
Name: GatewaySubnet
Starting address: 10.60.255.0
Size: /27

Die Auswahl des Subnetzzwecks sollte den erforderlichen Namen automatisch setzen. Ein /27 stellt 32 Adressen bereit und lässt Platz für Gatewayinstanzen sowie zukünftige Änderungen der Gatewaykonfiguration.

Ordne GatewaySubnet keine NSG, Routentabelle oder NAT Gateway zu. Wähle Add.

Virtuelles Netzwerkgateway erstellen

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

Konfiguriere unter Basics:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: vng-cloudtrips-hub-test-weu
Region: West Europe
Gateway type: VPN
SKU: VpnGw1AZ
Virtual network: vnet-cloudtrips-hub-test-weu

Das Portal sollte GatewaySubnet automatisch erkennen. Wenn das Hub-VNet nicht verfügbar ist, bestätige, dass die Gatewayregion West Europe ist und das erforderliche Subnetz existiert.

Konfiguriere den Bereich für die öffentliche IP-Adresse:

Public IP address: Create new
Public IP address name: pip-cloudtrips-vng-test-weu
Enable active-active mode: Disabled
Configure BGP: Disabled
Enable Key Vault access: Disabled

Das aktuelle Portal zeigt möglicherweise kein Feld Availability zone an. Bei einem neuen Gateway mit der AZ-fähigen SKU VpnGw1AZ übernimmt Azure die zonenredundante Bereitstellung automatisch. Es muss daher kein Zonenwert eingegeben werden.

Die öffentliche statische Standard-IP identifiziert die Azure-Seite eines zukünftigen VPN-Tunnels. Sie macht die privaten Adressen im Hub oder in den Spokes nicht öffentlich erreichbar.

Wähle Review + create und anschließend Create. Lasse die Bereitstellung laufen, bis Azure ihren Abschluss meldet.

Gateway überprüfen

Öffne vng-cloudtrips-hub-test-weu und bestätige:

Provisioning state: Succeeded
Gateway type: VPN
VPN type: Route-based
SKU: VpnGw1AZ
Virtual network: vnet-cloudtrips-hub-test-weu

Notiere die öffentliche IP-Adresse aus der Gatewayübersicht. Das VPN-Gerät im Büro verwendet diese Adresse im nächsten Trip als Azure-Tunnelendpunkt.

Du kannst das Gateway auch in Cloud Shell überprüfen:

az network vnet-gateway show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vng-cloudtrips-hub-test-weu \
  --query "{State:provisioningState,VpnType:vpnType,Sku:sku.name}" \
  --output table

az network public-ip show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name pip-cloudtrips-vng-test-weu \
  --query "{Address:ipAddress,Allocation:publicIPAllocationMethod,Sku:sku.name}" \
  --output table

Hub-Gateway mit den Spokes teilen

Gatewaytransit ermöglicht den Spokes, das Gateway im Hub zu verwenden, statt in jedem VNet ein eigenes Gateway bereitzustellen.

Öffne vnet-cloudtrips-hub-test-weu > Settings > Peerings. Öffne peer-hub-to-app. Aktiviere in den lokalen Peeringeinstellungen des Hubs Allow gateway or route server in vnet-cloudtrips-hub-test-weu to forward traffic to vnet-cloudtrips-test-weu und speichere das Peering. Wiederhole dies für peer-hub-to-services, sodass das Hub-Gateway Datenverkehr an vnet-cloudtrips-services-test-weu weiterleiten darf.

Öffne vnet-cloudtrips-test-weu > Settings > Peerings. Öffne peer-app-to-hub, aktiviere Enable vnet-cloudtrips-test-weu to use vnet-cloudtrips-hub-test-weu’s remote gateway or route server und speichere das Peering. Aktiviere nicht Allow gateway or route server in vnet-cloudtrips-test-weu to forward traffic. Diese Option erfordert ein Gateway im Anwendungs-VNet. Das Gateway befindet sich jedoch bewusst im Hub.

Öffne vnet-cloudtrips-services-test-weu > Settings > Peerings. Öffne peer-services-to-hub, aktiviere Enable vnet-cloudtrips-services-test-weu to use vnet-cloudtrips-hub-test-weu’s remote gateway or route server und speichere das Peering. Lasse die Option, die ein Gateway im Dienste-VNet erfordern würde, deaktiviert.

Ein VNet kann nur das Remotegateway eines einzigen Peerings verwenden. Keiner der Spokes enthält ein eigenes virtuelles Netzwerkgateway. Deshalb können beide das Hub-Gateway verwenden.

Der Azure-VPN-Endpunkt ist jetzt bereit und wird von beiden Spokes gemeinsam verwendet. Es existiert jedoch noch keine Verbindung zum Büro. Ein lokales Netzwerkgateway muss die öffentliche Adresse des VPN-Geräts und die privaten Adressbereiche des Büros beschreiben. Anschließend muss eine Verbindungsressource beide Gatewaydefinitionen verbinden, bevor ein Tunnel online gehen kann.