Où appliquer les NSG au trafic VPN site à site Azure

Le tunnel site à site est opérationnel, le client local atteint certains hôtes Azure et pas d’autres, et quelqu’un a attaché un groupe de sécurité réseau à GatewaySubnet pour corriger cela. Arrêtez-vous là. Azure ne prend pas en charge de NSG sur GatewaySubnet, et le groupe ne voit pas le paquet interne comme le fait une règle de charge. Placez la stratégie sur le sous-réseau ou la carte réseau de destination, faites correspondre l’adresse source qui existe après le déchiffrement, puis vérifiez avec une connexion nouvelle plutôt qu’ancienne.

Placez le NSG là où Azure l’évalue

La limite prise en charge pour le filtrage de charge est le sous-réseau ou l’interface réseau de destination. Un sous-réseau de passerelle est de l’infrastructure, et Azure documente que les NSG n’y sont pas pris en charge et peuvent dégrader le fonctionnement de la passerelle.

Le placement pose aussi un problème de logique. Le NSG sur GatewaySubnet évaluerait l’échange IPsec externe, dont les adresses appartiennent aux deux passerelles. Votre règle applicative a besoin de la source privée à l’intérieur du tunnel, et ce paquet n’existe qu’après que la passerelle l’a déchiffré. Attachez le groupe au sous-réseau de charge et la règle verra l’adresse pour laquelle elle a été écrite.

Vérifiez les associations actuelles avant de changer quoi que ce soit, afin de savoir ce que vous déplacez :

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

Trouvez l’adresse source après le déchiffrement

La source interne est l’adresse privée du client local, ou l’adresse qu’un équipement ou le NAT du VPN présente après traduction. Ce n’est pas l’adresse publique de la passerelle VPN locale, qui relève de l’échange externe.

Quand le NAT fait partie de la conception, confirmez la source présentée au lieu de la supposer. Une capture de paquets sur la VM Azure, ou le champ source du journal de connexion du service, tranche la question plus vite que la lecture de la configuration locale. Écrivez ensuite la règle sur cette adresse et sur le port de destination réel.

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

Utilisez une règle par service que vous voulez exposer, et gardez la liste de ports courte. Une règle qui autorise tous les ports depuis la plage locale réduit le NSG à une formalité.

Vérifiez l’étendue par défaut VirtualNetwork

L’étiquette de service VirtualNetwork est plus large que le réseau virtuel local. Sa définition inclut les espaces d’adresses locaux connectés, les réseaux appairés et d’autres préfixes connectés à la passerelle. Une règle d’autorisation par défaut limitée à VirtualNetwork peut donc déjà autoriser du trafic de tunnel qu’un exploitant croyait externe.

Lisez les règles par défaut avant d’en ajouter d’étroites, et lisez chaque règle de priorité supérieure qui pourrait correspondre en premier. Ajouter une autorisation explicite ne supprime pas une règle plus large qui autorise déjà le flux. Là où la stratégie exige un refus, placez-le à une priorité réellement évaluée avant l’autorisation.

La documentation des étiquettes de service de Microsoft indique ce que couvre l’étiquette VirtualNetwork, et c’est la référence à citer quand quelqu’un soutient que l’étiquette ne désigne que la plage du VNet.

Lisez les règles effectives aux deux frontières

Quand un NSG de sous-réseau et un NSG de carte réseau s’appliquent tous deux, le flux doit satisfaire les deux. Une autorisation dans l’un n’annule pas un refus dans l’autre, et c’est la vue agrégée que le paquet rencontre réellement.

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

Si des règles d’administrateur de sécurité Azure Virtual Network Manager interviennent, examinez aussi cette couche. Une règle d’administration Always allow peut livrer du trafic sans évaluation du NSG, tandis qu’un Deny administratif l’arrête avant que les NSG ne le voient. Une revue limitée au NSG est incomplète pour cette disposition.

Rappelez-vous que les NSG sont à état. Modifier une règle ne met pas forcément fin à une connexion autorisée existante, donc un test d’acceptation exige un flux neuf. Cette propriété est utile en production et trompeuse pendant une fenêtre de changement.

Vérifiez avec une connexion neuve

Ouvrez une nouvelle session depuis le client local vers le port du service, puis répétez depuis un hôte qui devrait être refusé. Exécutez aussi le test de flux côté VM, pour savoir que le chemin de retour est intact.

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

Une autorisation NSG est une seule décision d’accès, pas une route ni un écouteur. Si la règle autorise le flux et que la connexion échoue encore, vérifiez la route du client vers le VPN, la route de retour d’Azure et le pare-feu de l’hôte avant de modifier à nouveau le groupe. Notez l’adresse source réelle, les associations du NSG et la règle correspondante avec le service approuvé, car le prochain changement d’appairage ou de route peut modifier ce que couvre l’étiquette VirtualNetwork.