Las preguntas de redes más difíciles de AZ-104 suenan así: "VM1 no puede conectarse a VM2. ¿Cuál es la causa y qué debes usar para confirmarla?". El temario oficial enumera por separado "solucionar problemas de conectividad de red" y "evaluar las reglas de seguridad efectivas en los NSG", y el dominio de supervisión añade "usar Azure Network Watcher y Connection Monitor". Un error en cualquier punto, ya sea un NSG, una ruta, un emparejamiento o el DNS, produce el mismo síntoma ("no conecta"), así que sin un orden fijo de comprobaciones acabas dando vueltas entre las opciones.
Este artículo propone un orden de cinco pasos que acota un problema de conectividad de fuera hacia dentro, junto con la herramienta de Network Watcher para cada paso. Explica el orden en que se evalúan los NSG en la subred y en la NIC, las reglas de selección de rutas y el próximo salto, por qué el emparejamiento no es transitivo y cómo funciona el tránsito de puerta de enlace, y los vínculos y el registro automático de las zonas DNS privadas. Los conceptos básicos de NSG, UDR y emparejamiento se explican primero en VNet, NSG, DNS y Load Balancer Explicados para Principiantes.
---
Acota un Problema de Conectividad en Cinco Pasos
Cuando un paquete no llega, revisas en orden: ¿la dirección es correcta?, ¿la ruta de reparto es correcta?, ¿lo detuvo la seguridad del edificio?, ¿están conectadas las redes de reparto regionales?, ¿está en casa el destinatario? Revisar un problema de conectividad entre VM en el mismo orden encuentra la causa rápido.
!Cinco pasos que acotan un problema de conectividad de una VM de fuera hacia dentro
| Paso | Pregunta | Herramientas para comprobarlo | |------|------|------| | 1. Resolución de nombres | ¿El nombre se resuelve a la IP correcta? | nslookup, el vínculo de red virtual de la zona DNS privada | | 2. Rutas | ¿El paquete va al próximo salto correcto? | Próximo salto, las rutas efectivas de la NIC | | 3. Reglas de seguridad | ¿Algún NSG lo permite? | Comprobación del flujo de IP, diagnóstico de NSG, reglas de seguridad efectivas | | 4. Topología | ¿Están conectadas las VNet, y la red local? | Estado del emparejamiento, solución de problemas de VPN, solución de problemas de conexión | | 5. Dentro de la VM | ¿La aplicación escucha y el firewall del SO lo permite? | Solución de problemas de conexión, captura de paquetes, diagnóstico dentro de la VM |
Consejo para el examen: Si la pregunta dice "averiguar qué regla bloquea el tráfico", la respuesta es la comprobación del flujo de IP; "averiguar hacia dónde se enruta el tráfico" es Próximo salto; "probar una vez la conexión entre una VM y un destino y ver latencia y saltos" es la solución de problemas de conexión; "supervisar de forma continua a lo largo del tiempo" es Connection Monitor.
---
Las Herramientas de Network Watcher de un Vistazo
Network Watcher es un conjunto de herramientas para diagnosticar recursos de red IaaS como VM, VNet, equilibradores de carga y puertas de enlace de aplicaciones. Recuerda también que no está pensado para supervisar servicios PaaS.
| Herramienta | Qué hace | Qué te dice el resultado | |------|------|------| | Comprobación del flujo de IP (IP flow verify) | Comprueba si un paquete de 5 tuplas concreto se permite, desde el punto de vista de una VM | Permitido/denegado + el nombre de la regla que decide | | Diagnóstico de NSG | Comprueba el tráfico de una IP, prefijo o etiqueta de servicio en una VM, conjunto de escalado o puerta de enlace de aplicaciones | Permitido/denegado + la regla; puede agregar una regla de mayor prioridad | | Próximo salto (Next hop) | Comprueba la ruta hacia una IP de destino concreta | Tipo de próximo salto, dirección IP, id. de la tabla de rutas | | Reglas de seguridad efectivas | Muestra las reglas que se aplican realmente a una NIC | El NSG de la NIC, el NSG de la subred y la suma de ambos | | Solución de problemas de conexión | Prueba una vez la conexión desde una VM (y otros) hacia una VM, FQDN, URI o IP | Accesibilidad, latencia, saltos, problemas detectados | | Connection Monitor | Supervisa de forma continua las conexiones entre puntos de conexión de Azure e híbridos | Latencia y pérdida a lo largo del tiempo, alertas | | Captura de paquetes | Captura de forma remota el tráfico de una VM o conjunto de escalado | Análisis a nivel de paquete | | Solución de problemas de VPN | Diagnostica puertas de enlace de red virtual y sus conexiones | Estado y registros de la puerta de enlace y la conexión | | Registros de flujo | Registra información del tráfico IP en almacenamiento, visualizada con análisis de tráfico | Registros de flujos permitidos y denegados | | Topología | Visualiza las relaciones de los recursos de red entre suscripciones y regiones | Comprender la configuración |
Para los registros de flujo, usa a partir de ahora los registros de flujo de red virtual. Ya no se pueden crear registros de flujo de NSG nuevos, y estos se retiran el 30 de septiembre de 2027.
---
Las Reglas de NSG se Evalúan Dos Veces, en un Orden Fijo
Si un edificio tiene un guardia en la entrada (el NSG de la subred) y una cerradura en la puerta de la oficina (el NSG de la NIC), tienes que pasar ambos. Azure los evalúa en un orden distinto según la dirección.
| Dirección | Orden de evaluación | Resultado | |------|------|------| | Entrada | NSG de la subred → NSG de la NIC | Si la subred lo deniega, el NSG de la NIC no se evalúa | | Salida | NSG de la NIC → NSG de la subred | Si la NIC lo deniega, el NSG de la subred no se evalúa | | Entre VM de la misma subred | El mismo orden que arriba | El NSG de la subred se aplica incluso dentro de la misma subred |
Dentro de cada NSG, las reglas se evalúan desde el número de prioridad más bajo (100–4096) hacia arriba, y la evaluación se detiene en la primera regla que coincide. Los NSG tienen estado, así que el tráfico de respuesta de una conexión permitida vuelve sin necesidad de otra regla. Cuando no has creado reglas, se aplican estas reglas predeterminadas.
| Dirección | Regla predeterminada (prioridad) | Significado | |------|------|------| | Entrada | AllowVNetInBound (65000) | Permite el tráfico desde dentro de la VNet y de las VNet emparejadas | | Entrada | AllowAzureLoadBalancerInBound (65001) | Permite los sondeos de estado del equilibrador de carga | | Entrada | DenyAllInBound (65500) | Deniega todo lo demás | | Salida | AllowVnetOutBound (65000) | Permite el tráfico que va hacia la VNet | | Salida | AllowInternetOutBound (65001) | Permite el tráfico que va a internet | | Salida | DenyAllOutBound (65500) | Deniega todo lo demás |
Comprobarlo con una Pregunta de Tabla
El NSG de la subred tiene la regla "prioridad 200, permitir TCP 3389", y el NSG de la NIC de VM1 tiene la regla "prioridad 100, denegar todo el tráfico desde internet". Un intento de RDP desde internet hacia VM1 pasa el NSG de la subred pero lo deniega el NSG de la NIC. Las reglas de seguridad efectivas muestran juntas las reglas de ambos NSG, y la comprobación del flujo de IP devuelve el nombre de la regla de denegación del NSG de la NIC.
Consejo para el examen: Al elegir la solución, revisa en qué NSG va la regla y con qué prioridad. Para ganar a la regla de denegación de prioridad 100 del NSG de la NIC, hay que agregar una regla de permiso con un número menor que 100 en ese mismo NSG de la NIC. Por muy bajo que sea el número que uses en el NSG de la subred, la denegación del NSG de la NIC no cambia.
---
Rutas: ¿Adónde Va el Paquete?
Aunque un NSG permita el tráfico, un paquete enviado al lugar equivocado nunca conecta. Azure crea automáticamente rutas del sistema para cada subred, y las rutas definidas por el usuario (UDR) y las rutas BGP pueden reemplazarlas.
Hay dos reglas de selección de rutas. Primero, Azure elige la ruta cuyo prefijo coincide de forma más específica con la IP de destino (coincidencia de prefijo más largo). Si existen 10.0.0.0/16 y 10.0.0.0/24, el tráfico hacia 10.0.0.5 sigue la ruta /24. Si los prefijos son idénticos, la prioridad es ruta definida por el usuario → ruta BGP → ruta del sistema.
| Tipo de próximo salto | Significado | Qué recordar | |------|------|------| | Red virtual | Se entrega directamente dentro del espacio de direcciones de la VNet | Ruta del sistema | | Internet | Se envía a internet | El valor predeterminado de la ruta del sistema 0.0.0.0/0 | | Aplicación virtual | Se envía a la IP privada de una NVA, como un firewall | Hay que habilitar el reenvío IP en la NIC de esa NVA | | Puerta de enlace de red virtual | Se envía a una puerta de enlace de VPN o ExpressRoute | Tráfico con destino a la red local | | Ninguno | El tráfico se descarta | Para bloquear un intervalo a propósito |
Consejo para el examen: Si "una UDR envía 0.0.0.0/0 a una NVA y se corta todo el tráfico de internet", sospecha de la configuración de reenvío IP de la NIC de la NVA o del enrutamiento dentro de la NVA. La herramienta Próximo salto muestra el tipo de próximo salto como "Aplicación virtual" junto con el id. de la tabla de rutas aplicada.
---
Emparejamiento y Puertas de Enlace: Problemas de Topología
Aunque los NSG y las rutas sean correctos, las VNet no se comunican sin una conexión entre ellas. La trampa más frecuente es que el emparejamiento no es transitivo. Si la VNet A está emparejada con B y B con C, A y C siguen sin poder comunicarse directamente.
| Solución | Cómo funciona | |------|------| | Emparejar A y C directamente | Lo más simple, pero el número de emparejamientos crece rápido al añadir VNet | | Pasar por una NVA o Azure Firewall en el concentrador | Una UDR en las subredes radiales fija el firewall del concentrador como próximo salto; permitir el tráfico reenviado en el emparejamiento | | Compartir la puerta de enlace del concentrador | Con el tránsito de puerta de enlace, las radiales usan la puerta de enlace de VPN o ExpressRoute del concentrador |
El tránsito de puerta de enlace consiste en activar