Contoso Ltd. tiene una topología hub-spoke en East US: una VNet de hub (Hub-VNet) con un NVA y dos VNets spoke (Spoke-A y Spoke-B). Spoke-A está emparejada con Hub-VNet y Spoke-B está emparejada con Hub-VNet. Los ingenieros notan que las VM en Spoke-A no pueden alcanzar las VM en Spoke-B a través de las conexiones de emparejamiento. ¿Qué explicación describe mejor por qué el tráfico directo spoke-a-spoke no atraviesa el emparejamiento del hub, y qué debe hacer Contoso para habilitar la comunicación spoke-a-spoke sin rediseñar todos los emparejamientos?

El emparejamiento de VNet en Azure no es transitivo. Esto significa que si Spoke-A está emparejada con Hub-VNet y Spoke-B está emparejada con Hub-VNet, Spoke-A y Spoke-B no pueden comunicarse directamente entre sí a través del hub sin una configuración adicional. Para habilitar la comunicación spoke-a-spoke, el tráfico debe ser dirigido explícitamente a través del hub. La solución correcta es implementar un NVA en el hub (o usar una puerta de enlace VPN/ExpressRoute) y configurar rutas definidas por el usuario (UDRs) en las VNets spoke. Estas UDRs deben reenviar el tráfico destinado a la otra spoke al NVA del hub. Las opciones incorrectas son: "Transit Peering" no es una característica de Azure VNet Peering; el emparejamiento no bloquea todo el tráfico este-oeste por defecto, pero sí requiere enrutamiento explícito para la transitividad. Los Network Security Groups (NSGs) controlan el flujo de tráfico dentro y entre subredes, pero no resuelven el problema fundamental de la falta de transitividad del emparejamiento de VNet. La ubicación de la suscripción del hub no afecta el comportamiento de enrutamiento transitivo del emparejamiento de VNet.