Onde aplicar os NSG ao tráfico VPN de sitio a sitio de Azure

O túnel de sitio a sitio está activo, o cliente local chega a algúns hosts de Azure e a outros non, e alguén asociou un grupo de seguridade de rede a GatewaySubnet para arranxalo. Détente aí. Azure non admite un NSG en GatewaySubnet, e o grupo non ve o paquete interno como o fai unha regra de carga de traballo. Pon a política na subrede ou na NIC de destino, fai coincidir o enderezo de orixe que existe tras o descifrado e despois verifica cunha conexión nova, non cunha antiga.

Pon o NSG onde Azure o avalia

O límite admitido para o filtrado de carga de traballo é a subrede ou a interface de rede de destino. A subrede da pasarela é infraestrutura, e Azure documenta que os NSG non se admiten alí e poden prexudicar o funcionamento da pasarela.

Tamén hai un problema de lóxica na colocación. O NSG en GatewaySubnet avaliaría o intercambio IPsec exterior, cuxos enderezos pertencen ás dúas pasarelas. A túa regra de aplicación necesita a orixe privada dentro do túnel, e ese paquete só existe despois de que a pasarela o descifre. Asocia o grupo á subrede de carga de traballo e a regra verá o enderezo para o que se escribiu.

Comproba as asociacións actuais antes de cambiar nada, para saber que estás movendo:

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

Atopa o enderezo de orixe tras o descifrado

A orixe interna é o enderezo privado do cliente local, ou o enderezo que presenta un dispositivo ou o NAT da VPN tras a tradución. Non é o enderezo público da pasarela VPN local, que pertence ao intercambio exterior.

Cando o NAT forma parte do deseño, confirma a orixe presentada en lugar de supoñela. Unha captura de paquetes na VM de Azure, ou o campo de orixe no rexistro de conexións do servizo, resolve a cuestión máis rápido que ler a configuración local. Despois escribe a regra contra ese enderezo e o porto de destino real.

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

Usa unha regra por servizo que queiras expoñer e mantén curta a lista de portos. Unha regra que permite todos os portos do rango local converte o NSG nun trámite.

Comproba o ámbito predeterminado VirtualNetwork

A etiqueta de servizo VirtualNetwork é máis ampla que a rede virtual local. A súa definición inclúe espazos de enderezos locais conectados, redes con peering e outros prefixos conectados á pasarela. Por iso, unha regra de permiso predeterminada limitada a VirtualNetwork xa pode permitir tráfico do túnel que un operador cría externo.

Le as regras predeterminadas antes de engadir estreitas, e le cada regra de maior prioridade que poida coincidir primeiro. Engadir un permiso explícito non elimina unha regra máis ampla que xa permite o fluxo. Onde a política esixa unha denegación, colócaa nunha prioridade que realmente se avalíe antes do permiso.

A documentación de etiquetas de servizo de Microsoft enumera que cobre a etiqueta VirtualNetwork, e é a referencia que hai que citar cando alguén sostén que a etiqueta só significa o rango da VNet.

Le as regras efectivas nos dous límites

Cando se aplican á vez un NSG de subrede e un NSG de NIC, o fluxo debe satisfacer ambos. Un permiso nun non anula unha denegación no outro, e a vista agregada é o que o paquete atopa realmente.

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

Se interveñen regras de administrador de seguridade de Azure Virtual Network Manager, revisa tamén esa capa. Unha regra administrativa Always allow pode entregar tráfico sen avaliación do NSG, mentres que unha Deny administrativa o detén antes de que os NSG o vexan. Unha revisión só do NSG é incompleta para esa disposición.

Lembra que os NSG teñen estado. Editar unha regra non remata necesariamente unha conexión permitida existente, así que unha proba de aceptación necesita un fluxo novo. Esa propiedade é útil en produción e enganosa durante unha ventá de cambio.

Verifica cunha conexión nova

Abre unha sesión nova desde o cliente local ao porto do servizo e despois repite desde un host que debería ser denegado. Executa a proba de fluxo tamén desde o lado da VM, para saber que a ruta de retorno está intacta.

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

Un permiso do NSG é unha soa decisión de acceso, non unha ruta nin un escoitador. Se a regra permite o fluxo e a conexión segue fallando, comproba a ruta do cliente cara á VPN, a ruta de retorno de Azure e a devasa do host antes de volver editar o grupo. Anota o enderezo de orixe real, as asociacións do NSG e a regra coincidente xunto co servizo aprobado, porque o seguinte cambio de peering ou de ruta pode alterar que cobre a etiqueta VirtualNetwork.