Todo entorno de Azure llega a la misma semana: alguien pregunta por qué la cuenta de almacenamiento es alcanzable desde internet, la respuesta es "porque es el valor por defecto" y el equipo se pone a arreglarlo. Dos días después hay un ticket titulado "la aplicación resuelve la cuenta de almacenamiento pero obtiene la IP pública".
Ese ticket es todo el tema. La parte de red de los endpoints privados es fácil. La parte de DNS es donde se tuerce.
Service endpoints frente a endpoints privados
Los service endpoints extienden la identidad de tu VNet al servicio PaaS por la red troncal de Azure y permiten que el cortafuegos del servicio admita tráfico desde una subred concreta. El servicio conserva su IP pública y su nombre DNS público. El tráfico se queda en la troncal, pero el recurso sigue siendo direccionable desde fuera salvo que el cortafuegos lo deniegue.
Los endpoints privados dan al servicio una IP privada dentro de tu VNet. El recurso pasa a ser alcanzable por esa IP, el acceso de red público se puede desactivar por completo y la conexión funciona desde cualquier sitio que pueda enrutar a tu VNet, incluida la red local por ExpressRoute o VPN.
Los service endpoints son gratuitos; los endpoints privados cuestan por hora más datos procesados. Para cualquier cosa con datos de clientes, el endpoint privado es la respuesta correcta y el coste no es el factor decisivo. Para una cuenta de almacenamiento de desarrollo, un service endpoint con una regla de cortafuegos es proporcionado.
El problema de DNS, dicho claramente
Cuando creas un endpoint privado, el nombre DNS público del recurso —mialmacen.blob.core.windows.net— sigue resolviendo públicamente a una IP pública. Lo que hace que resuelva a la IP privada es una zona DNS privada (privatelink.blob.core.windows.net) vinculada a la VNet, con un registro A para el endpoint.
Los modos de fallo se deducen directamente:
- La zona existe pero no está vinculada a la VNet que consulta. La resolución devuelve la IP pública y la conexión falla o se va por internet en silencio.
- Cada equipo creó su propia zona. Ahora tienes cuatro zonas
privatelink.database.windows.netcon registros distintos, y cuál te toca depende de en qué VNet estés. Este es el lío que cuesta un fin de semana desenredar. - Los clientes de la red local no resuelven nada, porque tu DNS corporativo no sabe nada de las zonas privadas de Azure.
La disposición que funciona
Un único conjunto de zonas DNS privadas, en la suscripción de conectividad, vinculadas a todas las VNet. Centralízalas desde el principio. Créalas con Terraform y usa Azure Policy (DeployIfNotExists) para registrar automáticamente cada endpoint privado nuevo en la zona central correcta. Esa política es lo más valioso de este artículo: significa que un equipo que crea un endpoint privado no puede equivocarse con el DNS, porque no interviene en él.
Un reenviador de DNS en el hub —el proxy de DNS de Azure Firewall o Azure DNS Private Resolver— para que los clientes locales reenvíen las consultas de zonas de Azure y obtengan las respuestas privadas. Private Resolver es la opción creada para esto y evita tener que mantener VM reenviadoras.
Denegar el acceso de red público por política en cuentas de almacenamiento, servidores SQL, Key Vaults y cuentas de Cosmos de tu grupo de administración de producción, para que el endpoint privado no solo esté presente sino que sea el único camino.
Hub y radios, y dónde va el cortafuegos
La forma estándar: una VNet hub en la suscripción de conectividad con Azure Firewall, la pasarela de VPN o ExpressRoute y el resolutor de DNS; VNet radiales por suscripción de carga, emparejadas con el hub, con rutas definidas por el usuario mandando la salida por el cortafuegos.
Dos decisiones que conviene tomar a propósito:
- Azure Firewall o un dispositivo virtual de red. Firewall es gestionado, se integra con las políticas y es caro a bajo volumen. Para un entorno pequeño, NSG más una NAT gateway puede ser proporcionado — pero pierdes el filtrado de salida por FQDN, que es un control real de detección y de exfiltración.
- Virtual WAN o hub y radios clásico. Virtual WAN compensa con muchas regiones y sedes; el peering clásico es más simple para un entorno de una sola región.
Grupos de seguridad de red en todas las subredes, con flow logs activados hacia una cuenta de almacenamiento y traffic analytics encendido. Como con los flow logs en AWS, el valor aparece durante un incidente, y solo si alguien lo preparó antes.
La parte de planificación de IP
Espacio de direcciones sin solapamientos entre VNet, red local y cualquier red de socios, a partir de un plan documentado. Cada endpoint privado consume una IP, así que dimensiona la subred de endpoints con margen — un /26 se llena antes de lo que crees en un entorno con una cuenta de almacenamiento y una base de datos por carga.
Desplegamos esto junto a la estructura de grupos de administración y políticas al inicio de casi todos los proyectos cloud, porque la política de DNS tiene que existir antes de que los equipos empiecen a crear endpoints, no después.
Qué hacer esta semana
Lista tus zonas DNS privadas en todas las suscripciones. Si hay más de una zona por tipo de servicio, o si alguna zona no está vinculada a las VNet que la consultan, ya has encontrado el origen de la próxima caída confusa.