D4 · Infraestructura

Conectividad Híbrida y DNS

Conectar on-premises con Azure: VPN vs ExpressRoute según ancho de banda, SLA y compliance; acceso privado a PaaS con Private Endpoints; y la pieza que une todo: el DNS híbrido.

Contenido

VPN Gateway: S2S y P2S
ExpressRoute
Service Endpoints vs Private Endpoints
DNS híbrido y Private Resolver
Tabla de decisión

VPN Gateway: Site-to-Site y Point-to-Site

Site-to-Site (S2S)

• Túnel IPsec/IKE entre tu dispositivo VPN y el gateway (en GatewaySubnet)
• Sobre internet — latencia variable, cifrado nativo
• SKUs por throughput/túneles; active-active y zone-redundant para HA
• BGP para rutas dinámicas y failover
• Hasta ~10 Gbps agregado en SKUs altos — suficiente para la mayoría

Point-to-Site (P2S)

• Clientes individuales (laptops) → VNet: OpenVPN, IKEv2, SSTP
• Auth: certificados, Entra ID, RADIUS
• Para usuarios remotos/admins — considerar también Bastion para solo administración

ExpressRoute

Circuito privado y dedicado vía proveedor de conectividad — el tráfico NO cruza internet. Latencia consistente, hasta 10/100 Gbps (Direct), SLA 99.95%+. No cifrado por defecto (privado ≠ cifrado): añadir MACsec (Direct) o IPsec sobre el circuito si exigen cifrado.

Conceptos

• Private peering: a tus VNets · Microsoft peering: a servicios públicos (M365, IPs públicas de Azure)
• Global Reach: conectar datacenters entre sí vía Microsoft
• FastPath: bypass del gateway para mejor rendimiento al data plane
• HA: dos conexiones por circuito; circuitos en dos peering locations para DR

VPN vs ExpressRoute — la decisión

• "Latencia predecible", "el tráfico no debe cruzar internet", ">1 Gbps sostenido", "SAP/SQL replicación pesada" → ExpressRoute
• "Rápido de montar", "bajo costo", "cifrado nativo", "sucursal pequeña" → VPN S2S
• Patrón recomendado: VPN como backup de ExpressRoute (coexisten en el mismo gateway hub)

Service Endpoints vs Private Endpoints

Aspecto	Service Endpoint	Private Endpoint
Qué es	La subnet "se identifica" ante el servicio PaaS; tráfico por backbone	NIC con IP PRIVADA de tu VNet que representa al recurso PaaS
El servicio sigue teniendo IP pública	Sí — solo restringes QUIÉN llega	Puede deshabilitarse el acceso público por completo
Accesible desde on-prem/peered VNets	No — solo desde la subnet habilitada	Sí — vía VPN/ER y peering (es una IP privada normal)
Granularidad	Al SERVICIO completo (todas las storage accounts)	Al RECURSO individual (esa storage account, ese blob endpoint)
Requiere DNS especial	No	Sí — Private DNS Zone privatelink.*
Costo	Gratis	Por hora + GB procesado
Recomendación	Legacy/costo mínimo	El estándar de seguridad actual y la respuesta del examen para "acceso solo privado"

DNS híbrido y Private Resolver

Las piezas

• Azure DNS público: hosting de zonas públicas (no registrar dominios)
• Private DNS Zones: resolución privada en VNets vinculadas (+ autoregistro de VMs)
• Zonas privatelink.* para que los private endpoints resuelvan a IP privada
• 168.63.129.16: el resolver interno de Azure

DNS Private Resolver (la respuesta híbrida moderna)

• PaaS — reemplaza las VMs de DNS forwarder
• Inbound endpoint: on-prem consulta nombres de Azure (privatelink incluidos)
• Outbound endpoint + rulesets: Azure consulta dominios on-prem (conditional forwarding)
• Señal: "resolver nombres privados de Azure desde on-premises sin gestionar servidores DNS" → Private Resolver

Tabla de decisión

Requisito	Diseño
Conectar oficina a Azure rápido y barato, cifrado	VPN S2S
Tráfico a Azure sin cruzar internet, latencia consistente	ExpressRoute (private peering)
ExpressRoute + requisito de cifrado	MACsec (Direct) o IPsec sobre el circuito
Continuidad si el circuito ER falla	VPN S2S como backup (o segundo circuito)
Usuarios remotos acceden a la VNet	P2S VPN (o Bastion para administración)
SQL accesible SOLO por IP privada, incluso desde on-prem	Private Endpoint + privatelink DNS + deshabilitar público
Restringir storage a una subnet sin pagar PE	Service Endpoint + firewall de cuenta
On-prem resuelve nombres privatelink de Azure	DNS Private Resolver (inbound) + forwarders on-prem
Azure resuelve dominio AD corp.local de on-prem	Private Resolver outbound + ruleset
Conectar dos datacenters propios vía Microsoft	ExpressRoute Global Reach

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Un banco migra su core a Azure. Requisitos: (1) la conexión on-premises↔Azure no debe atravesar internet público y necesita 5 Gbps sostenidos con latencia predecible, (2) si la conexión principal falla debe haber un camino de respaldo aunque sea degradado, (3) las apps on-premises deben resolver los nombres privados de las bases de datos en Azure (private endpoints). ¿Qué combinación diseñas?

Inicia sesión para llevar tu progreso.

AnteriorDiseño de Red (Hub-Spoke)Infraestructura SiguienteSeguridad y Entrega de RedInfraestructura