Ein Remote-Mitarbeiter benötigt privaten Azure-Zugriff? Konfiguriere ein Point-to-Site-VPN
Ein CloudTrips-Mitarbeiter im Homeoffice benötigt Zugriff auf private Azure-Ressourcen, ist aber nicht mit einem Firmennetzwerk verbunden. Ohne Bürorouter oder ein anderes VPN-Gerät kann ein Site-to-Site-VPN dieses Szenario nicht lösen.
Ein Point-to-Site-VPN (P2S) erstellt eine verschlüsselte Verbindung von einem einzelnen Clientcomputer, dem Point, zu einem Azure-VNet, der Site. Der Mitarbeiter startet die Verbindung in Azure VPN Client und authentifiziert sich mit einem Microsoft-Entra-Konto. Ein Rechenzentrum oder firmeneigenes VPN-Gerät ist nicht erforderlich.
Dieser Trip baut auf folgendem Trip auf: Privater Azure-Zugriff benötigt einen VPN-Endpunkt? Erstelle ein VPN Gateway.
Clientverbindung planen
Verwende:
VPN gateway: vng-cloudtrips-hub-test-weu
Client address pool: 172.30.0.0/24
Tunnel type: OpenVPN (SSL)
Authentication type: Microsoft Entra ID
Azure VPN Client audience: c632b3df-fb67-4d84-bdcf-b95ad541b5c8
Der Clientadresspool ist kein Azure-Subnetz. Azure weist jedem verbundenen
VPN-Client eine Adresse aus diesem Bereich zu. Er darf sich weder mit einem
CloudTrips-VNet noch mit dem lokalen Netzwerk überschneiden, aus dem der Laptop
die Verbindung herstellt. Wenn dein aktuelles Netzwerk bereits
172.30.0.0/24 verwendet, wähle einen anderen freien privaten Bereich.
Bestätige vor dem Fortfahren, dass vng-cloudtrips-hub-test-weu den
Provisioning state: Succeeded anzeigt und peer-app-to-hub für die
Verwendung des Remotegateways im Hub konfiguriert ist.
Tenant-ID finden
Öffne im Azure-Portal Microsoft Entra ID > Overview und kopiere die Tenant ID. Die Tenant-ID identifiziert das CloudTrips-Microsoft-Entra- Verzeichnis. Sie ist kein Client Secret.
Erstelle damit:
Tenant: https://login.microsoftonline.com/<your-tenant-id>
Issuer: https://sts.windows.net/<your-tenant-id>/
Der abschließende / im Issuer-Wert ist erforderlich.
Point-to-Site-Zugriff konfigurieren
Öffne vng-cloudtrips-hub-test-weu und wähle Settings > Point-to-site
configuration > Configure now.
Konfiguriere:
Address pool: 172.30.0.0/24
Tunnel type: OpenVPN (SSL)
Authentication type: Microsoft Entra ID
Tenant: https://login.microsoftonline.com/<your-tenant-id>
Audience: c632b3df-fb67-4d84-bdcf-b95ad541b5c8
Issuer: https://sts.windows.net/<your-tenant-id>/
Der Audience-Wert identifiziert den von Microsoft registrierten Azure VPN Client. Er ist für Azure-Public-Tenants identisch. Im CloudTrips-Tenant muss dafür keine App-Registrierung erstellt werden.
Das Portal zeigt möglicherweise noch Azure Active Directory statt Microsoft Entra ID an. Beide Bezeichnungen meinen hier dieselbe Authentifizierungsoption.

Wähle Save und warte, bis die Aktualisierung abgeschlossen ist.
Clientprofil herunterladen
Wähle oben auf der Seite Point-to-site configuration die Option Download VPN client. Azure kann mehrere Minuten benötigen, um das Paket zu erstellen.
Entpacke die heruntergeladene ZIP-Datei und öffne den Ordner AzureVPN. Er
enthält azurevpnconfig.xml oder azurevpnconfig_aad.xml. Die Datei enthält
die Gateway- und Authentifizierungseinstellungen für Azure VPN Client. Sie
enthält nicht dein Microsoft-Entra-Kennwort.

Wenn das Profil die Routen zu den CloudTrips-Spoke-VNets nicht enthält, bestätige Gatewaytransit auf den Hub-Peerings sowie die Verwendung des Remotegateways auf den Spoke-Peerings. Lade danach ein neues Clientpaket herunter.
Azure VPN Client installieren und verbinden
Installiere Azure VPN Client unter Windows aus dem Microsoft Store oder unter macOS aus dem App Store. Cisco Secure Client wird für diese Microsoft-Entra-ID-Konfiguration nicht verwendet.
Öffne Azure VPN Client und wähle + > Import. Wähle die XML-Datei aus
dem entpackten Ordner AzureVPN, behalte die importierten Einstellungen bei
und wähle Save.
Wähle das neue CloudTrips-Profil und dann Connect. Melde dich mit deinem CloudTrips-Microsoft-Entra-Konto an und schließe bei Aufforderung die MFA ab.

Der Client sollte Connected anzeigen und eine Adresse aus
172.30.0.0/24 erhalten. Dies bestätigt, dass sich der Laptop authentifiziert
und den OpenVPN-Tunnel aufgebaut hat. Im nächsten Schritt wird der Zugriff auf
einen privaten Workload geprüft.
Temporären privaten Testdienst vorbereiten
Der frühere NSG-Diagnose-Trip löschte seine temporäre VM, behielt aber
nic-cloudtrips-vm-test-weu. Diese NIC gehört weiterhin zur Application ASG
und besitzt noch eine öffentliche IP auf Instanzebene. Die frühere Regel
Allow-HTTPS-Internet würde daher auch Internetverkehr zu TCP 443 erlauben und
einen reinen VPN-Test ungültig machen.
Entferne diese Regel vorübergehend, bevor du den Dienst erneut erstellst oder startest:
az network nsg rule delete \
--resource-group rg-cloudtrips-network-test-weu \
--nsg-name nsg-cloudtrips-app-test-weu \
--name Allow-HTTPS-Internet
az network nsg rule list \
--resource-group rg-cloudtrips-network-test-weu \
--nsg-name nsg-cloudtrips-app-test-weu \
--query "[?name=='Allow-HTTPS-Internet'].name" \
--output tsv
Der Prüfbefehl darf keine Ausgabe zurückgeben. Starte den temporären Dienst erst danach. Erstelle die VM jetzt kurzzeitig erneut mit der erhaltenen NIC:
az vm create \
--resource-group rg-cloudtrips-network-test-weu \
--name vm-cloudtrips-nsg-test-weu \
--location westeurope \
--zone 3 \
--nics nic-cloudtrips-vm-test-weu \
--image Canonical:0001-com-ubuntu-server-jammy:22_04-lts-gen2:latest \
--size Standard_D2s_v3 \
--admin-username azureuser \
--generate-ssh-keys \
--os-disk-name osdisk-cloudtrips-nsg-test-weu \
--os-disk-size-gb 30 \
--storage-sku Standard_LRS \
--os-disk-delete-option Delete \
--nic-delete-option Detach
Erlaube dem VPN-Clientpool den Zugriff und verweigere danach allen anderen Quellen TCP 443, bevor die NSG-Standardeingangsregeln ausgewertet werden:
az network nsg rule create \
--resource-group rg-cloudtrips-network-test-weu \
--nsg-name nsg-cloudtrips-app-test-weu \
--name Allow-HTTPS-P2S \
--priority 110 \
--direction Inbound \
--access Allow \
--protocol Tcp \
--source-address-prefixes 172.30.0.0/24 \
--source-port-ranges '*' \
--destination-asgs asg-cloudtrips-app-test-weu \
--destination-port-ranges 443
az network nsg rule create \
--resource-group rg-cloudtrips-network-test-weu \
--nsg-name nsg-cloudtrips-app-test-weu \
--name Deny-HTTPS-NonP2S \
--priority 120 \
--direction Inbound \
--access Deny \
--protocol Tcp \
--source-address-prefixes '*' \
--source-port-ranges '*' \
--destination-asgs asg-cloudtrips-app-test-weu \
--destination-port-ranges 443
Da Priorität 110 vor Priorität 120 ausgewertet wird, können verbundene P2S-Clients den Dienst erreichen. Alle anderen Quellen werden während dieses Testfensters verweigert.
Starte über Azure Run Command einen temporären HTTP-Dienst auf Port 443:
az vm run-command invoke \
--resource-group rg-cloudtrips-network-test-weu \
--name vm-cloudtrips-nsg-test-weu \
--command-id RunShellScript \
--scripts "systemd-run --unit=cloudtrips-p2s-test --property=Restart=always /usr/bin/python3 -m http.server 443 --directory /tmp"
Dies ist ein temporärer Klartext-HTTP-Konnektivitätstest auf TCP 443 und kein produktiver HTTPS-Dienst.
Private Verbindung testen
Führe den folgenden Befehl auf dem Laptop aus, während Azure VPN Client Connected anzeigt. Verwende dafür nicht Cloud Shell:
VM_PRIVATE_IP=$(az vm list-ip-addresses \
--resource-group rg-cloudtrips-network-test-weu \
--name vm-cloudtrips-nsg-test-weu \
--query '[0].virtualMachine.network.privateIpAddresses[0]' \
--output tsv)
printf 'Private Testadresse: %s\n' "$VM_PRIVATE_IP"
curl "http://${VM_PRIVATE_IP}:443"
Die zurückgegebene Verzeichnisliste stammt von der privaten IP-Adresse der VM. Die Anfrage läuft vom Laptop durch den Point-to-Site-Tunnel, das VPN Gateway im Hub und das Peering zwischen Hub und Anwendung. Sie verwendet nicht die öffentliche IP-Adresse der VM.

Der beibehaltene Screenshot zeigt 10.20.1.4, die beim ursprünglichen Capture
vergebene Adresse. Verwende den abgefragten Wert, statt dieselbe dynamische
private IP anzunehmen. Wenn die VPN-Verbindung funktioniert, die Anfrage aber
fehlschlägt, bestätige, dass die VM ausgeführt wird, VM_PRIVATE_IP nicht leer
ist, der Testdienst aktiv ist, die P2S-NSG-Regel existiert und der Laptop die
Spoke-Routen aus dem heruntergeladenen Profil erhalten hat.
Temporäre Computeressourcen entfernen
Trenne Azure VPN Client und lösche danach die temporäre VM, bevor du eine NSG-Regel änderst. Entferne beide Testregeln und erstelle die frühere Internetregel neu, die der spätere Load-Balancer-Trip voraussetzt:
az vm delete \
--resource-group rg-cloudtrips-network-test-weu \
--name vm-cloudtrips-nsg-test-weu \
--yes
az network nsg rule delete \
--resource-group rg-cloudtrips-network-test-weu \
--nsg-name nsg-cloudtrips-app-test-weu \
--name Allow-HTTPS-P2S
az network nsg rule delete \
--resource-group rg-cloudtrips-network-test-weu \
--nsg-name nsg-cloudtrips-app-test-weu \
--name Deny-HTTPS-NonP2S
az network nsg rule create \
--resource-group rg-cloudtrips-network-test-weu \
--nsg-name nsg-cloudtrips-app-test-weu \
--name Allow-HTTPS-Internet \
--priority 100 \
--direction Inbound \
--access Allow \
--protocol Tcp \
--source-address-prefixes Internet \
--source-port-ranges '*' \
--destination-asgs asg-cloudtrips-app-test-weu \
--destination-port-ranges 443
Der Betriebssystemdatenträger wird gelöscht. Die vorhandene NIC wird getrennt
und bleibt erhalten. Das VPN Gateway verursacht weiterhin Kosten, bis es
gelöscht wird, auch wenn kein Client verbunden ist. TCP 443 war nur während des
temporären Dienstes und der beiden Testregeln ausschließlich per VPN erreichbar.
Die Wiederherstellung von Allow-HTTPS-Internet nach dem Löschen der VM bringt
das sequenzielle Lab auf den Ausgangszustand für den späteren Trip zurück.