La verificación de flujo IP de Azure dice permitido, pero la VPN sigue fallando

Túnel de sitio a sitio conectado, VM sana, el cliente local no recibe nada. Abres Network Watcher, ejecutas la verificación de flujo IP y dice Access allowed, así que el ticket se cierra como un problema de VPN. Ese resultado no significa lo que parece, porque la verificación de flujo IP evalúa las reglas de seguridad del flujo que describiste y nunca comprueba si Azure tiene una ruta a tu prefijo local.

La pregunta de filtrado y la pregunta de enrutamiento son distintas, y Network Watcher las responde con herramientas diferentes. Saber cuál hiciste es la mayor parte del diagnóstico.

Qué decide realmente la verificación de flujo IP

La verificación de flujo IP toma una VM, una interfaz de red, una dirección, valores de la quíntupla y un protocolo, y luego informa la decisión de la regla NSG y del administrador de seguridad para ese flujo. Funciona con TCP y UDP, así que no es un probador de reglas ICMP y un ping bloqueado no demuestra nada sobre tu servicio. Dale el flujo real en lugar de una suposición. Una conexión entrante desde el entorno local a un puerto de base de datos es una descripción distinta de una conexión saliente que inicia la VM.

Si la puerta de enlace traduce direcciones, usa la dirección de origen que llega al límite que evalúas, no la de la configuración del cliente. Lee el resultado por lo que es, también. Access allowed significa que la capa de filtrado permitiría el paquete si llegara, y nada más.

Lo que no puede decirte es la ruta que eligió Azure, si el firewall del invitado permite el puerto o si algo está escuchando. Eso vive en otras capas.

Qué aportan el siguiente salto y las rutas efectivas

El siguiente salto responde una pregunta de reenvío: para este destino, qué tipo de siguiente salto elige Azure, en qué dirección, desde qué tabla de rutas. Las rutas efectivas enumeran lo que la NIC tiene realmente. Ejecuta ambos y obtendrás la ruta del lado de Azure que una verificación de flujo IP en verde deja en blanco.

La introducción a la verificación de flujo IP de Microsoft indica el alcance del filtrado directamente, mientras que las páginas de siguiente salto y diagnóstico de rutas cubren el lado del reenvío. Cita la página correcta cuando escribas el hallazgo.

Los comandos son lo bastante cortos para ejecutarlos desde un shell. az network nic show-effective-route-table enumera las rutas aplicadas a la interfaz. az network watcher show-next-hop con un origen y un destino devuelve el salto seleccionado. Compara el prefijo que te importa con esa tabla y luego confirma qué entrada gana.

Recorre la ruta de vuelta desde la NIC de la VM

Hazlo desde la NIC de la VM de destino, para el prefijo del cliente local, no para internet. La ruta de vuelta es donde se esconden las fallas de sitio a sitio, porque una comprobación de estado del túnel solo informa que las asociaciones de seguridad están activas.

Si falta la ruta esperada, revisa los prefijos remotos que proporciona la configuración de la puerta de enlace, el diseño de conectividad de la VNet y cualquier ajuste de propagación de rutas. Un objeto de puerta de enlace de red local describe el lado local; su existencia no demuestra que todos los prefijos necesarios estén presentes y se prefieran en la NIC. Son hechos distintos, y solo uno de ellos aparece en un resumen del portal.

Lee el tipo de siguiente salto en lugar de copiar un ejemplo

Una ruta de puerta de enlace VPN administrada normalmente muestra VirtualNetworkGateway como tipo de siguiente salto. VirtualAppliance describe un diseño de reenvío distinto, normalmente un firewall o un dispositivo de red virtual.

No crees una ruta de dispositivo apuntando a un punto de conexión VPN supuesto porque una respuesta antigua de un foro usó ese tipo. Si una ruta definida por el usuario anula la ruta prevista, busca a su propietario y su propósito antes de cambiarla. Una segunda NIC también puede cambiar qué interfaz usa el invitado, y quitarla puede romper otro servicio en lugar de arreglar esta ruta.

Pasa al límite que sigue fallando

Cuando el filtrado y el enrutamiento coinciden con el diseño, la falla está en otro lugar. Revisa la tabla de rutas del propio invitado, su firewall y si el escucha está ligado a la dirección esperada. Luego revisa los selectores de tráfico protegido de la VPN y la ruta de respuesta local. Cada una de ellas es una prueba separada con un resultado separado.

Cierra con una solicitud de aplicación permitida y observaciones desde ambos extremos. Un resultado de allow y un siguiente salto correcto son dos piezas de evidencia, no la prueba de que la conexión haya funcionado.