Microsoft AZ-700: Redes Híbridas — Guía de estudio

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Network Engineer AZ-700 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Fundamentos de la conectividad híbrida y restricciones de direccionamiento

La conectividad híbrida consiste en la comunicación IP confiable, enrutable y segura entre las redes virtuales locales y de Azure. Al planificar el direccionamiento de la red virtual, recuerde que algunos recursos administrados por Azure dentro de una subred requieren una asignación de direcciones contigua y sin conflictos y, a veces, direcciones reservadas específicas: los balanceadores de carga de Azure y las subredes de puerta de enlace deben crearse deliberadamente (la GatewaySubnet debe tener ese nombre exacto y un tamaño que se ajuste a la escala del SKU de la puerta de enlace), y los puntos de conexión privados y los puntos de conexión de servicio administrados por Azure requieren direcciones extraídas de la VNet que los aloja. La superposición de prefijos locales y de Azure es la trampa más común: los rangos superpuestos interrumpen el enrutamiento y la selección de rutas BGP, crean enrutamiento asimétrico y complican las directivas de firewall. Utilice segmentos de al menos /27–/24 para subredes que alojen firewalls con estado, balanceadores de carga o muchos puntos de conexión privados; reserve una GatewaySubnet dedicada (/27 o mayor dependiendo del SKU). El DNS es igualmente crítico: los puntos de conexión privados utilizan zonas de DNS privado de la plataforma (por ejemplo, privatelink.database.windows.net), por lo que se necesitan reenviadores condicionales o Azure DNS Private Resolver en el entorno local para resolver los nombres privados de Azure. Las decisiones de diseño se centran en el equilibrio entre la utilización de IP y la resiliencia: los esquemas IPv4 más densos ahorran espacio de direcciones pero aumentan el riesgo de colisión y migración, mientras que los prefijos más grandes y menos eficientes simplifican la expansión futura y las estrategias de anuncio BGP.

SKUs de VPN Gateway, fundamentos de BGP y Local Network Gateways

Elegir el SKU de VPN Gateway adecuado (VpnGw1–VpnGw5, Basic donde sea heredado) afecta directamente al rendimiento, las sesiones S2S/P2S simultáneas y las características disponibles como el modo activo-activo o los límites de rutas. Utilice puertas de enlace basadas en rutas para diseños híbridos modernos; el modo basado en directivas es heredado y limita el uso de BGP. BGP proporciona un intercambio dinámico de prefijos y admite la resiliencia de la ruta, la conmutación por error automática y la priorización de prefijos; configure el ASN de Azure VPN Gateway (predeterminado 65515) y hágalo coincidir o emparéjelo con el ASN local en el objeto Local Network Gateway. El Local Network Gateway almacena la IP pública local, el/los espacio(s) de direcciones y, opcionalmente, la IP de par BGP y el ASN; olvidar rellenar la IP de par BGP o no hacer coincidir los ASN impide la propagación de rutas y conduce a soluciones alternativas con rutas estáticas. Considere los hubs de Azure Virtual WAN para escalar a múltiples sitios y para el enrutamiento de tránsito integrado; los hubs de VWAN admiten S2S y P2S a gran escala y se integran con Azure Firewall y ExpressRoute. Tenga cuidado con la propagación de la tabla de rutas: por defecto, algunas topologías de hub a spoke o de dispositivo virtual suprimen la propagación automática; pueden ser necesarios UDR explícitos o anuncios de ruta BGP. Decisiones de diseño: los SKU más altos y VWAN aumentan el costo, pero reducen la carga administrativa y mejoran el rendimiento y la escala de enrutamiento.

Opciones de diseño Point-to-Site, soporte de cliente e integración de DNS

Las elecciones de diseño de Point-to-Site (P2S) determinan la compatibilidad del cliente, la autenticación y la escala. OpenVPN (SSL) es el más multiplataforma y se recomienda para clientes de macOS, Linux y móviles; IKEv2 es ligero y funciona bien con los clientes nativos de macOS; SSTP sigue siendo una opción para escenarios más antiguos solo con Windows. Los modos de autenticación incluyen Azure Active Directory (recomendado para la integración de identidades y el acceso condicional), la autenticación basada en certificados y RADIUS para soluciones MFA locales o basadas en RADIUS. El SKU de VPN Gateway dicta el número de túneles P2S y el rendimiento; elija VpnGw2/3 para grupos de usuarios de tamaño mediano a grande y VpnGw4/5 para uso a gran escala o sensible al rendimiento. Los puntos de conexión privados y P2S interactúan a través de DNS: para permitir que los clientes P2S resuelvan nombres de puntos de conexión privados (zonas privatelink), vincule las zonas de DNS privado a la VNet o use Azure DNS Private Resolver y reenviadores condicionales desde el DNS local o del cliente. Una trampa frecuente es olvidar que los clientes P2S normalmente usan el DNS de Azure proporcionado por la puerta de enlace solo cuando el cliente inserta las rutas y la configuración de DNS; las configuraciones explícitas de sufijo DNS y reenviadores evitan problemas de «no se puede resolver el punto de conexión privado». Equilibre la escalabilidad y el costo: la autenticación por certificado es de bajo costo pero más difícil de revocar; Azure AD ofrece controles de seguridad modernos pero añade licenciamiento y complejidad.

Enrutamiento de tránsito, tunelización forzada, inspección y ubicación de dispositivos de seguridad

Diseñar el tránsito entre múltiples VNets, entornos locales y dispositivos de inspección requiere una aplicación clara de los límites de enrutamiento y NAT. Forzar el tráfico a través de Azure Firewall o dispositivos virtuales requiere rutas definidas por el usuario (UDR) que apunten a la IP privada del firewall o el uso del enrutamiento del hub de Virtual WAN para centralizar la inspección. Si necesita un proxy transparente completo o inspección TLS, ubique el dispositivo en una subred de inspección dedicada y asegúrese de que los SKU de la subred de la puerta de enlace y del firewall soporten el tránsito para el rendimiento esperado. Preste atención al comportamiento de SNAT y a la elección de los SKU de IP pública: se recomiendan IP públicas Standard y NAT Gateway para un SNAT de salida predecible y reglas de seguridad; NAT Gateway emparejado con un conjunto de IP públicas Standard descarga el SNAT y evita la proliferación de IP públicas por VM. Una trampa común es el enrutamiento asimétrico, cuando las rutas locales y las UDR de Azure provocan que el tráfico de retorno omita el dispositivo previsto; asegúrese de que todos los radios anuncien los prefijos necesarios a través de BGP o tengan UDR que canalicen el tráfico hacia el punto de inspección. Rendimiento frente a coste: una topología hub-and-spoke con Azure Firewall Premium o dispositivos de terceros de alto rendimiento aumenta la protección y la gestión centralizada, pero eleva el coste y el riesgo de fallo de un único concentrador, a menos que despliegue concentradores redundantes activo-activo y empareje puertas de enlace entre regiones.

Problema práctico: Escenario de caso de uso

Escenario: Contoso Ltd tiene dos centros de datos locales (Seattle y Ámsterdam) y un entorno de Azure existente con tres VNets (VNet-Prod, VNet-Shared, VNet-Dev) en una única VNet concentradora (VNet-Hub). Actualmente utilizan una VPN Gateway VpnGw1 para Seattle y una conexión de sitio a sitio a un hub de Azure Virtual WAN para Ámsterdam. Se utilizan puntos de conexión privados para Azure SQL en VNet-Shared.

Desafío: Contoso necesita conectividad híbrida resiliente y escalable con enrutamiento dinámico (BGP) entre ambos centros de datos y Azure, soporte P2S fiable para usuarios de macOS, resolución DNS de puntos de conexión privados desde el entorno local e inspección centralizada del tráfico de salida de los radios a través de Azure Firewall.

Enfoque recomendado:

Desplegar una nueva VPN Gateway VpnGw3 basada en rutas en VNet-Hub, configurada en modo activo-activo con BGP habilitado (establecer el ASN de la puerta de enlace explícitamente) y actualizar los objetos Local Network Gateway con las IP de los pares BGP y los ASN locales; migrar la conexión S2S de Seattle a la nueva puerta de enlace para soportar un mayor rendimiento y límites de rutas.
Consolidar la conexión de Ámsterdam en el concentrador estableciendo una conexión ExpressRoute o migrando el hub de VWAN a un emparejamiento de concentradores con VNet-Hub; asegurar el intercambio de rutas BGP entre ambos centros de datos para evitar rutas estáticas y permitir la conmutación por error automática.
Configurar P2S utilizando el protocolo OpenVPN con autenticación de Azure AD en la VpnGw3 para dar soporte a los clientes de macOS (con IKEv2 como alternativa), y dimensionar los grupos de clientes según los límites de VpnGw3; publicar un reenviador condicional en el DNS local para reenviar las zonas privatelink.* a un Azure DNS Private Resolver desplegado en VNet-Shared y vinculado a las zonas de DNS privado para los puntos de conexión privados.
Desplegar Azure Firewall (Standard o Premium si se requiere inspección TLS) en VNet-Hub en configuración activo-activo y crear UDR para las subredes de los radios que dirijan 0.0.0.0/0 a la IP privada del Firewall; adjuntar un NAT Gateway con IP públicas Standard al firewall o usar la IP pública del Firewall para SNAT explícito y registro en un Log Analytics central.

Justificación: El uso de VpnGw3 con BGP proporciona propagación dinámica de rutas y rendimiento para la resiliencia multisitio; OpenVPN+Azure AD da soporte a los usuarios de macOS de forma segura; el reenvío de DNS a Azure DNS Private Resolver asegura la resolución de nombres de los puntos de conexión privados desde el entorno local; centralizar la inspección en un concentrador con Azure Firewall y UDR evita el enrutamiento asimétrico y simplifica la gestión de políticas, a cambio de un mayor coste por una seguridad y observabilidad centralizadas.

← Diseño de Azure Virtual Network · Todos los dominios · Azure DNS y Resolución de Nombres →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →