Dónde aplicar los NSG al tráfico VPN de sitio a sitio de Azure

El túnel de sitio a sitio está activo, el cliente local llega a algunos hosts de Azure y a otros no, y alguien ha asociado un grupo de seguridad de red a GatewaySubnet para arreglarlo. Deténgase ahí. Azure no admite un NSG en GatewaySubnet, y el grupo no ve el paquete interno como lo hace una regla de carga de trabajo. Coloque la directiva en la subred o la NIC de destino, haga coincidir la dirección de origen que existe tras el descifrado y luego verifique con una conexión nueva, no con una antigua.

Coloque el NSG donde Azure lo evalúa

El límite admitido para el filtrado de carga de trabajo es la subred o la interfaz de red de destino. La subred de puerta de enlace es infraestructura, y Azure documenta que los NSG no se admiten allí y pueden perjudicar el funcionamiento de la puerta de enlace.

También hay un problema de lógica en la ubicación. El NSG en GatewaySubnet evaluaría el intercambio IPsec exterior, cuyas direcciones pertenecen a las dos puertas de enlace. Su regla de aplicación necesita el origen privado dentro del túnel, y ese paquete solo existe después de que la puerta de enlace lo descifre. Asocie el grupo a la subred de carga de trabajo y la regla verá la dirección para la que se escribió.

Compruebe las asociaciones actuales antes de cambiar nada, para saber qué está moviendo:

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

Encuentre la dirección de origen tras el descifrado

El origen interno es la dirección privada del cliente local, o la dirección que presenta un dispositivo o el NAT de la VPN tras la traducción. No es la dirección pública de la puerta de enlace VPN local, que pertenece al intercambio exterior.

Cuando el NAT forma parte del diseño, confirme el origen presentado en lugar de suponerlo. Una captura de paquetes en la VM de Azure, o el campo de origen en el registro de conexiones del servicio, resuelve la cuestión más rápido que leer la configuración local. Después escriba la regla contra esa dirección y el puerto 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

Use una regla por servicio que quiera exponer y mantenga corta la lista de puertos. Una regla que permite todos los puertos del rango local convierte el NSG en un trámite.

Compruebe el ámbito predeterminado VirtualNetwork

La etiqueta de servicio VirtualNetwork es más amplia que la red virtual local. Su definición incluye espacios de direcciones locales conectados, redes con peering y otros prefijos conectados a la puerta de enlace. Por eso, una regla de permiso predeterminada limitada a VirtualNetwork ya puede permitir tráfico del túnel que un operador creía externo.

Lea las reglas predeterminadas antes de añadir estrechas, y lea cada regla de mayor prioridad que pueda coincidir primero. Añadir un permiso explícito no elimina una regla más amplia que ya permite el flujo. Donde la política exija una denegación, colóquela en una prioridad que realmente se evalúe antes del permiso.

La documentación de etiquetas de servicio de Microsoft enumera qué cubre la etiqueta VirtualNetwork, y es la referencia que hay que citar cuando alguien sostiene que la etiqueta solo significa el rango de la VNet.

Lea las reglas efectivas en ambos límites

Cuando se aplican a la vez un NSG de subred y un NSG de NIC, el flujo debe satisfacer ambos. Un permiso en uno no anula una denegación en el otro, y la vista agregada es lo que el paquete encuentra realmente.

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

Si intervienen reglas de administrador de seguridad de Azure Virtual Network Manager, revise también esa capa. Una regla administrativa Always allow puede entregar tráfico sin evaluación del NSG, mientras que una Deny administrativa lo detiene antes de que los NSG lo vean. Una revisión solo del NSG es incompleta para esa disposición.

Recuerde que los NSG tienen estado. Editar una regla no termina necesariamente una conexión permitida existente, así que una prueba de aceptación necesita un flujo nuevo. Esa propiedad es útil en producción y engañosa durante una ventana de cambio.

Verifique con una conexión nueva

Abra una sesión nueva desde el cliente local al puerto del servicio y luego repita desde un host que debería ser denegado. Ejecute la prueba de flujo también desde el lado de la VM, para saber que la 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 del NSG es una sola decisión de acceso, no una ruta ni un escucha. Si la regla permite el flujo y la conexión sigue fallando, compruebe la ruta del cliente hacia la VPN, la ruta de retorno de Azure y el firewall del host antes de volver a editar el grupo. Anote la dirección de origen real, las asociaciones del NSG y la regla coincidente junto con el servicio aprobado, porque el siguiente cambio de peering o de ruta puede alterar qué cubre la etiqueta VirtualNetwork.