Un cliente de servicios públicos quiere que todo el tráfico de spoke-to-spoke atraviese un NVA central implementado en el hub de Virtual WAN. Intentaron crear UDRs en las VNets spoke con un next hop que apunta a la IP del firewall del hub, pero las subredes spoke no respetan esos UDRs. ¿Por qué sucede esto y cuál es la forma correcta de forzar el tráfico de spoke-to-spoke a través del NVA del hub?

La opción correcta es que los UDRs en las VNets spoke no influyen en el tránsito administrado por Virtual WAN. Cuando una VNet está conectada a un hub de Virtual WAN, el enrutamiento lo gestiona el hub. Para forzar el tráfico spoke-to-spoke a través de un NVA central, debe crear una tabla de rutas personalizada en el hub virtual. Esta tabla de rutas debe incluir una ruta estática (o una ruta predeterminada 0.0.0.0/0) que apunte a la IP privada del NVA. Luego, asocie esta tabla de rutas personalizada con las conexiones de las VNets spoke en el hub virtual. Esto asegura que el hub dirija el tráfico de las spokes al NVA para su inspección. Las otras opciones son incorrectas porque: Azure no bloquea los UDRs, pero Virtual WAN toma precedencia en el enrutamiento. El encadenamiento de servicios no es el mecanismo correcto para este escenario. Habilitar BGP en las VNets spoke no es la forma correcta de influir en el enrutamiento del hub de Virtual WAN para el tráfico spoke-to-spoke a través de un NVA. El emparejamiento global de VNet no es necesario ni la forma correcta de implementar este patrón de enrutamiento con Virtual WAN.