El examen AZ-700 evalúa tu capacidad para determinar qué ruta elige el tráfico y qué factores deciden esa prioridad. Más que memorizar listas de funciones, debes saber en cada escenario qué herramienta corresponde y en qué posición. Controlar rutas estáticas con UDR, gestionar rutas dinámicas con BGP y Azure Route Server, y estructurar redes a gran escala con VNet Peering y Hub-Spoke son los pilares de esta sección.
Rutas del sistema y prioridad de enrutamiento
Cuando se inaugura una nueva autopista, las aplicaciones de navegación la incorporan de inmediato y empiezan a guiar a los conductores por ella. Azure funciona igual: en el momento en que creas una VNet, genera automáticamente rutas del sistema. El espacio de direcciones de la VNet recibe el next hop , apunta a y los rangos privados RFC 1918 se configuran como (descarte).
La prioridad de rutas sigue dos principios. Primero, el prefijo más específico siempre gana: es la regla de longest prefix match. Segundo, cuando dos rutas compiten con el mismo prefijo, el orden es .
Una trampa frecuente en el examen: si existe un UDR con y next hop , ese UDR supera cualquier anuncio BGP proveniente de un VPN Gateway. Para implementar force tunneling correctamente, el next hop debe ser , no .
UDR: dirigir el tráfico exactamente donde se necesita
Imagina un centro de distribución donde ciertos productos deben pasar obligatoriamente por una zona de inspección antes de ser enviados. En lugar de confiar en que cada trabajador encontrará el camino correcto, se colocan señales que obligan a todos a pasar por ese punto de control. Los User Defined Routes funcionan exactamente así: sustituyen las rutas del sistema de Azure para dirigir el tráfico por un salto específico.
El caso de uso más habitual es forzar que todo el tráfico de las subredes Spoke pase por una NVA o un firewall en el Hub. Se asocia una tabla de rutas a la subred Spoke con la regla: .
Los UDR admiten cinco tipos de next hop:
: reenvía a una IP concreta (NVA, firewall) : enruta hacia la puerta de enlace VPN o ExpressRoute : mantiene el tráfico dentro de la VNet : envía el tráfico a la internet pública de Azure : descarta el paquete
Una advertencia importante: aplicar un UDR incorrecto en puede cortar por completo la conexión VPN o ExpressRoute. Siempre hay que ser muy cuidadoso al asociar tablas de rutas a subredes de puerta de enlace.
BGP y Azure Route Server: el mundo del enrutamiento dinámico
Una torre de control aéreo no asigna una ruta fija a cada avión. Los aviones intercambian información continuamente con la torre y ajustan su trayectoria en tiempo real. BGP (Border Gateway Protocol) funciona del mismo modo: permite que los routers anuncien y aprendan rutas de manera dinámica, sin depender de tablas estáticas.
En Azure, BGP se usa principalmente en los VNet Gateways para intercambiar rutas dinámicamente con routers locales a través de conexiones VPN o ExpressRoute. Al habilitar BGP en un VPN Gateway, este se identifica con un ASN (Autonomous System Number). El ASN predeterminado es 65515, y no debe coincidir con el ASN local.
Azure Route Server va un paso más allá. Cuando una NVA establece un peering BGP con Azure Route Server, las rutas que la NVA anuncia se propagan automáticamente por toda la VNet. Esto elimina la necesidad de actualizar manualmente las entradas UDR cada vez que cambia la tabla de rutas de la NVA.
| Atributo | UDR | Azure Route Server | |--|--|--| | Tipo de ruta | Estática (manual) | Dinámica (BGP) | | Gestión | Actualización manual en cada cambio | La NVA actualiza automáticamente | | Mejor uso | Topologías pequeñas y fijas | Entornos grandes con NVA |
VNet Peering: conectado pero aislado
Piensa en dos edificios de oficinas dentro del mismo complejo empresarial. Podrías salir a la calle y rodear el edificio, o usar un corredor interno exclusivo que los conecta directamente. VNet Peering es ese corredor: el tráfico fluye por la red troncal de Azure sin pasar por internet público ni por una puerta de enlace.
El peering tiene dos modalidades: Regional (misma región de Azure) y Global (entre regiones distintas). La característica más importante que hay que recordar es que el peering es . Si VNet A está en peering con VNet B, y VNet B está en peering con VNet C, el tráfico de A no puede llegar a C pasando automáticamente por B.
Para permitir la comunicación Spoke-to-Spoke en un diseño Hub-Spoke, existen dos opciones:
Enrutar el tráfico de los Spoke a través de la NVA del Hub mediante UDR (el patrón más habitual) Usar Azure Virtual WAN, que gestiona automáticamente el enrutamiento Spoke-to-Spoke
Gateway Transit permite que las VNets Spoke compartan la puerta de enlace VPN o ExpressRoute del Hub para la conectividad local. Se deben configurar ambos lados: en el peering del Hub y en el peering del Spoke.
Topología Hub-Spoke: seguridad centralizada por diseño
Imagina la sede central de una empresa que recibe toda la correspondencia de las sucursales, la clasifica y la envía al departamento correcto. La topología Hub-Spoke sigue exactamente ese modelo. La VNet Hub aloja la infraestructura compartida: un firewall (NVA o Azure Firewall), el VPN/ExpressRoute Gateway, DNS y Active Directory. Cada VNet Spoke ejecuta sus propias cargas de trabajo y depende del Hub para los servicios comunes.
La principal ventaja es que las políticas de seguridad se administran en un único lugar. A medida que se añaden VNets Spoke, nunca es necesario replicar las reglas de firewall de forma independiente en cada una.
El force tunneling usa un UDR con apuntando a la NVA del Hub. Así se garantiza que cada solicitud de internet saliente desde una VM de un Spoke pase obligatoriamente por el firewall central para su inspección. Configurar el next hop como en lugar de saltaría el firewall por completo, un error sutil pero grave.
VNet Peering vs VPN vs ExpressRoute: cómo elegir la conexión adecuada
Elegir cómo conectar ubicaciones es como seleccionar un medio de transporte. Un pasillo interno directo, una carretera pública o una vía privada contratada responden a necesidades distintas según la velocidad, el coste y los requisitos de seguridad.
| Atributo | VNet Peering | VPN Gateway | ExpressRoute | |--|--|--|--| | Ruta | Red troncal de Azure | Internet pública (cifrada) | Circuito privado dedicado | | Latencia | La más baja | Media | La más baja (línea privada) | | Transit | No | Sí (BGP) | Sí (BGP) | | Base de coste | Volumen de transferencia de datos | SKU de Gateway + datos | Circuito + SKU de Gateway | | Uso principal | Interno Azure-a-Azure | Conexión local pequeña | Alto volumen y alta disponibilidad |
La naturaleza no transitiva de VNet Peering es la distinción más evaluada en esta área. Para que el tráfico procedente de una ubicación local llegue a una VNet Spoke a través del Hub, se necesita tanto un VPN Gateway en el Hub como Gateway Transit correctamente configurado en ambos lados del peering.
Escenarios trampa: tres situaciones que suelen confundir
Al igual que en un concurso donde dos respuestas parecen casi idénticas, las preguntas de enrutamiento del AZ-700 giran en torno a diferencias pequeñas pero significativas.
Escenario uno: aplicar un UDR en . En un diseño Hub-Spoke, a veces es necesario enrutar el tráfico procedente de entornos locales a través de una NVA. Eso requiere un UDR en GatewaySubnet, pero cualquier error en la definición de la ruta puede interrumpir silenciosamente el enlace VPN o ExpressRoute.
Escenario dos: confundir con . El gateway transit se configura en el lado del Hub. Use remote gateway se configura en el lado del Spoke. Ambas opciones son necesarias para que el Spoke pueda utilizar la puerta de enlace del Hub. Si falta cualquiera de las dos, el Spoke intentará usar su propia puerta de enlace, que no existe.
Escenario tres: elegir entre Azure Route Server y UDR. Si la NVA admite BGP y las tablas de enrutamiento cambian con frecuencia, Azure Route Server es la respuesta correcta. Para topologías simples y estables, un UDR es suficiente y más fácil de administrar.
Resumen para el Examen
"Tráfico Spoke-to-Spoke falla" -- VNet Peering es no transitivo; enrutar a través de la NVA del Hub con UDR "El Spoke necesita usar la puerta de enlace del Hub" -- Hub: Allow gateway transit activado; Spoke: Use remote gateway activado "UDR 0.0.0.0/0 next hop Internet + BGP de VPN" -- El UDR gana; el anuncio BGP se ignora "Configuración de force tunneling" -- UDR 0.0.0.0/0, next hop: Virtual network gateway o Virtual appliance "La NVA inyecta rutas dinámicamente en la VNet" -- Azure Route Server con peering BGP "Enrutamiento Spoke-to-Spoke automático en Hub-Spoke" -- Azure Virtual WAN "A intenta llegar a C pasando por B con VNet Peering" -- No es posible; añadir peering A-C o usar Virtual WAN "Error en UDR de GatewaySubnet" -- Puede cortar la conectividad VPN o ExpressRoute por completo "Solapamiento de ASN entre entorno local y Azure VPN Gateway" -- Error de configuración; los ASN deben ser únicos "Orden de prioridad de rutas" -- UDR supera a BGP, BGP supera a ruta del sistema (mismo prefijo)
UDR = control estático de tráfico, Azure Route Server = inyección dinámica de rutas por NVA, Hub-Spoke = puerta de seguridad centralizada