Wo NSGs für Azure Site-to-Site-VPN-Verkehr anzuwenden sind

Der Site-to-Site-Tunnel steht, der lokale Client erreicht einige Azure-Hosts und andere nicht, und jemand hat eine Netzwerksicherheitsgruppe an GatewaySubnet gehängt, um das zu beheben. Hören Sie dort auf. Azure unterstützt keine NSG auf GatewaySubnet, und die Gruppe sieht das innere Paket nicht so, wie eine Workload-Regel es tut. Setzen Sie die Richtlinie auf das Zielsubnetz oder die NIC, gleichen Sie die Quelladresse ab, die nach der Entschlüsselung existiert, und prüfen Sie dann mit einer neuen Verbindung statt mit einer alten.

Setzen Sie die NSG dorthin, wo Azure sie auswertet

Die unterstützte Grenze für Workload-Filterung ist das Zielsubnetz oder die Zielnetzwerkschnittstelle. Ein Gatewaysubnetz ist Infrastruktur, und Azure dokumentiert, dass NSGs dort nicht unterstützt werden und den Gatewaybetrieb beeinträchtigen können.

Auch die Platzierung hat ein logisches Problem. Die NSG auf GatewaySubnet würde den äußeren IPsec-Austausch auswerten, dessen Adressen zu den beiden Gateways gehören. Ihre Anwendungsregel braucht die private Quelle innerhalb des Tunnels, und dieses Paket existiert erst, nachdem das Gateway es entschlüsselt. Hängen Sie die Gruppe an das Workload-Subnetz, und die Regel sieht die Adresse, für die sie geschrieben wurde.

Prüfen Sie die aktuellen Zuordnungen, bevor Sie etwas ändern, damit Sie wissen, was Sie verschieben:

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

Finden Sie die Quelladresse nach der Entschlüsselung

Die innere Quelle ist die private Adresse des lokalen Clients oder die Adresse, die ein Gerät oder VPN-NAT nach der Übersetzung präsentiert. Sie ist nicht die öffentliche Adresse des lokalen VPN-Gateways, die zum äußeren Austausch gehört.

Wenn NAT Teil des Designs ist, bestätigen Sie die präsentierte Quelle, statt sie anzunehmen. Ein Paketmitschnitt auf der Azure-VM oder das Quellfeld im Verbindungsprotokoll des Dienstes klärt die Frage schneller als das Lesen der lokalen Konfiguration. Schreiben Sie die Regel dann gegen diese Adresse und den tatsächlichen Zielport.

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

Verwenden Sie eine Regel pro Dienst, den Sie bereitstellen wollen, und halten Sie die Portliste kurz. Eine Regel, die alle Ports aus dem lokalen Bereich erlaubt, macht die NSG zu einer Formalität.

Prüfen Sie den Standardbereich VirtualNetwork

Das Diensttag VirtualNetwork ist breiter als das lokale virtuelle Netzwerk. Seine Definition umfasst verbundene lokale Adressräume, Peering-Netze und andere gatewayverbundene Präfixe. Eine standardmäßige Zulassungsregel mit Bereich VirtualNetwork kann also bereits Tunnelverkehr erlauben, den ein Betreiber für extern hielt.

Lesen Sie die Standardregeln, bevor Sie enge hinzufügen, und lesen Sie jede Regel mit höherer Priorität, die zuerst passen könnte. Eine ausdrückliche Zulassung entfernt keine breitere Regel, die den Datenfluss bereits erlaubt. Wo die Richtlinie eine Ablehnung verlangt, setzen Sie sie auf eine Priorität, die tatsächlich vor der Zulassung ausgewertet wird.

Microsofts Dokumentation zu Diensttags listet, was das Tag VirtualNetwork abdeckt, und das ist die Referenz, die Sie zitieren, wenn jemand argumentiert, das Tag meine nur den VNet-Bereich.

Lesen Sie die effektiven Regeln an beiden Grenzen

Wenn sowohl eine Subnetz-NSG als auch eine NIC-NSG gelten, muss der Datenfluss beide erfüllen. Eine Zulassung in der einen hebt eine Ablehnung in der anderen nicht auf, und die zusammengeführte Sicht ist das, worauf das Paket tatsächlich trifft.

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Wenn Sicherheits-Administratorregeln von Azure Virtual Network Manager im Spiel sind, prüfen Sie auch diese Ebene. Eine administrative Always allow-Regel kann Verkehr ohne NSG-Auswertung zustellen, während ein administratives Deny ihn stoppt, bevor die NSGs ihn sehen. Eine Prüfung nur der NSGs ist für diese Anordnung unvollständig.

Denken Sie daran, dass NSGs zustandsbehaftet sind. Das Bearbeiten einer Regel beendet nicht unbedingt eine bestehende erlaubte Verbindung, daher braucht ein Abnahmetest einen frischen Datenfluss. Diese Eigenschaft ist im Betrieb nützlich und in einem Änderungsfenster irreführend.

Prüfen Sie mit einer frischen Verbindung

Öffnen Sie eine neue Sitzung vom lokalen Client zum Dienstport und wiederholen Sie das dann von einem Host, der abgelehnt werden sollte. Führen Sie den Flow-Test auch von der VM-Seite aus, damit Sie wissen, dass der Rückweg intakt ist.

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

Eine NSG-Zulassung ist eine Zugriffsentscheidung, keine Route und kein Listener. Wenn die Regel den Datenfluss erlaubt und die Verbindung trotzdem scheitert, prüfen Sie die Client-Route in das VPN, die Rückroute von Azure und die Host-Firewall, bevor Sie die Gruppe erneut bearbeiten. Notieren Sie die tatsächliche Quelladresse, die NSG-Zuordnungen und die passende Regel zusammen mit dem freigegebenen Dienst, denn die nächste Peering- oder Routenänderung kann verändern, was das Tag VirtualNetwork abdeckt.