Escenario de una sola región: Private Link y DNS en Azure Virtual WAN

En este artículo se muestra cómo exponer un recurso de PaaS a través de un punto de conexión privado a una carga de trabajo específica en una sola región. En el escenario, la topología de red es una topología en estrella tipo hub-and-spoke y el centro de conectividad es un centro de Azure Virtual WAN.

Escenario

Figura 1: escenario de una sola región para Virtual WAN con Private Link y Azure DNS: el desafío

Descargue un archivo Visio de esta arquitectura. En esta sección se define el escenario y se vuelve a definir el desafío de este escenario (el desafío es el mismo que el ejemplo de no funcionamiento en la página de información general). La arquitectura de escenario inicial se basa en la topología de red inicial definida en la guía de información general. A continuación se muestran las adiciones y los cambios:

• Solo hay una región con un centro de conectividad virtual.
• Hay una cuenta de Azure Storage en la región que tiene deshabilitado el acceso a la red pública. La suposición en este escenario es que solo una carga de trabajo accede a la cuenta de almacenamiento.
• Inicialmente hay una única red virtual conectada al centro de conectividad virtual.
• La red virtual tiene una subred de carga de trabajo que contiene un cliente de máquina virtual (VM).
• La red virtual contiene una subred de punto de conexión privado que contiene un punto de conexión privado para la cuenta de almacenamiento.

Resultado correcto

El cliente de Azure Virtual Machine puede conectarse a la cuenta de Azure Storage a través del punto de conexión privado de la cuenta de almacenamiento que se encuentra en la misma red virtual y se bloquea el resto del acceso a la cuenta de almacenamiento.

Impedimento

Necesita un registro DNS en el flujo DNS que pueda resolver el nombre de dominio completo (FQDN) de la cuenta de almacenamiento en la dirección IP privada del punto de conexión privado. Como se identifica en la información general, el desafío con el escenario es doble:

1. No es posible vincular una zona DNS privada que mantenga las cuentas de almacenamiento necesarias para los registros DNS a un centro de conectividad virtual.
2. Puede vincular una zona DNS privada a la red de carga de trabajo, por lo que podría pensar que funcionaría. Desafortunadamente, la arquitectura de línea base estipula que cada red virtual conectada tiene servidores DNS configurados para que apunten a usar el proxy DNS de Azure Firewall.

Dado que no puede vincular una zona DNS privada a un centro de conectividad virtual y la red virtual está configurada para usar el proxy DNS de Azure Firewall, los servidores DNS de Azure no tienen ningún mecanismo para resolver el (FQDN) de la cuenta de almacenamiento en la dirección IP privada del punto de conexión privado. El resultado es que el cliente recibe una respuesta DNS errónea.

Flujos DNS y HTTP

Vamos a revisar los flujos de solicitud HTTP y DNS resultantes para esta carga de trabajo. La revisión nos ayuda a visualizar el impedimento descrito anteriormente.

Figura 2: escenario de una sola región para Virtual WAN con Private Link y Azure DNS: el desafío

Descargue un archivo Visio de esta arquitectura.

Flujo DNS

1. La consulta de DNS para stgworkload00.blob.core.windows.net desde el cliente se envía al servidor DNS configurado, que es Azure Firewall en el centro regional emparejado.
2. Azure Firewall envía mediante proxy la solicitud a Azure DNS. Dado que no es posible vincular una zona DNS privada a un centro virtual, Azure DNS no sabe cómo resolver el FQDN a la dirección IP privada del punto de conexión privado. Sabe cómo resolver el FQDN en la dirección IP pública de la cuenta de almacenamiento, por lo que devuelve la dirección IP pública de la cuenta de almacenamiento.

Flujo de HTTP

1. Con el resultado DNS en mano, la dirección IP pública de la cuenta de almacenamiento, el cliente emite una solicitud HTTP a stgworkload00.blob.core.windows.net.
2. La solicitud se envía a la dirección IP pública de la cuenta de almacenamiento. Esta solicitud produce un error por muchas razones:
   • Es posible que el NSG de la subred de carga de trabajo no permita este tráfico enlazado a Internet.
   • Es probable que la instancia de Azure Firewall que filtra el tráfico de salida enlazado a Internet no tenga una regla de aplicación para admitir este flujo.
   • Incluso si tanto el NSG como Azure Firewall tenían asignaciones para este flujo de solicitud, la cuenta de almacenamiento está configurada para bloquear todo el acceso a la red pública. En última instancia, el intento infringe nuestro objetivo de permitir el acceso únicamente a la cuenta de almacenamiento a través del punto de conexión privado.

Solución: establecimiento de una extensión de centro de conectividad virtual para DNS

Una solución al desafío es que el equipo de red empresarial implemente una extensión de centro de conectividad virtual para DNS. La única responsabilidad de la extensión del centro de conectividad virtual para DNS es habilitar los equipos de carga de trabajo que necesitan usar zonas DNS privadas en su arquitectura dentro de esta topología de centro de Virtual WAN de inicio.

La extensión DNS se implementa como un radio de red virtual que está emparejado con su centro virtual regional. Es posible vincular zonas DNS privadas a esta red virtual. La red virtual también contiene una instancia de Azure DNS Private Resolver que permite a los servicios fuera de esta red virtual, como Azure Firewall, consultar y recibir valores de todas las zonas DNS privadas vinculadas. A continuación se muestran los componentes de una extensión de centro de conectividad virtual para DNS típica, junto con algunos cambios de configuración necesarios:

• Nueva red virtual de radio que está emparejada con el centro virtual de la región. Este radio está configurado como cualquier otro radio, lo que significa que el servidor DNS predeterminado y las reglas de enrutamiento fuerzan el uso de Azure Firewall en el centro regional.
• Se implementa un recurso de DNS Private Resolver con un punto de conexión de entrada en la red virtual de radio.
• Se crea un recurso de zona DNS privado denominado privatelink.blob.core.windows.net.
  • Esta zona contiene un registro A que se asigna desde el nombre FQDN de la cuenta de almacenamiento a la dirección IP privada del punto de conexión privado de la cuenta de almacenamiento.
  • La zona DNS privada está vinculada a la red virtual de radio.
  • Si permite el control de acceso basado en roles (RBAC), puede usar entradas administradas por el servicio o el registro automático para mantener estos registros DNS. De lo contrario, puede mantenerlos manualmente.
• En el centro regional, el servidor DNS de Azure Firewall se cambia para que apunte al punto de conexión de entrada de DNS Private Resolver.

En el diagrama siguiente se muestra la arquitectura, junto con los flujos DNS y HTTP.

Figura 3: solución de trabajo para un escenario de región única para Virtual WAN con Private Link y DNS

Descargue un archivo Visio de esta arquitectura.

Flujo DNS para establecer una extensión de centro de conectividad virtual para DNS

1. La consulta de DNS para stgworkload00.blob.core.windows.net desde el cliente se envía al servidor DNS configurado, que es Azure Firewall en el centro regional emparejado; en este caso, 10.100.0.132.

   Figura 4: configuración de los servidores DNS para la red virtual de carga de trabajo

2. Azure Firewall envía mediante proxy la solicitud a la instancia regional de Azure DNS Private Resolver en la extensión del centro: 10.200.1.4 en este caso, que es la dirección IP privada del punto de conexión de entrada de DNS Private Resolver.

   

   Captura de pantalla de la directiva de Azure Firewall donde está habilitado el proxy DNS y los servidores DNS están establecidos en Personalizados. La entrada apunta a la dirección IP privada del punto de conexión de entrada de DNS Private Resolver.

   Figura 5: configuración DNS en una directiva de Azure Firewall

3. DNS Private Resolver envía mediante proxy la solicitud a Azure DNS. Dado que una zona DNS privada está vinculada a la red virtual que contiene el punto de conexión de entrada, Azure DNS puede usar registros en esas zonas DNS privadas vinculadas.

   Figura 6: vínculos de red virtual de zona DNS privada

4. Azure DNS consulta la zona DNS privada vinculada y resuelve el FQDN de stgworkload00.blob.core.windows.net a 10.1.2.4, que es la dirección IP del punto de conexión privado para la cuenta de almacenamiento. Esta respuesta se proporciona al DNS de Azure Firewall, que luego devuelve la dirección IP privada de la cuenta de almacenamiento al cliente.

   Figura 7: zona DNS privada con el registro A para el punto de conexión privado de la cuenta de almacenamiento

Flujo de HTTP

1. Con el resultado DNS en mano, la dirección IP privada de la cuenta de almacenamiento, el cliente emite una solicitud HTTP a stgworkload00.blob.core.windows.net.
2. La solicitud se envía a la dirección IP privada (10.1.2.4) de la cuenta de almacenamiento. Esta solicitud se enruta correctamente, suponiendo que no haya restricciones en conflicto en los grupos de seguridad de red locales de la subred del cliente o de la subred del punto de conexión privado. Es importante comprender que, aunque Azure Firewall protege el tráfico privado, la solicitud no se enruta a través de Azure Firewall porque el punto de conexión privado está en la misma red virtual que el cliente. Es decir, no es necesario realizar concesiones de Azure Firewall para este escenario.
3. Se establece una conexión privada a la cuenta de almacenamiento mediante el servicio de Private Link. La cuenta de almacenamiento solo permite el acceso a la red privada y acepta la solicitud HTTP.

Consideraciones para la extensión del centro virtual para DNS

Al implementar la extensión para su empresa, tenga en cuenta las instrucciones siguientes.

• La implementación de la extensión DNS no es una tarea para el equipo de la carga de trabajo. Esta tarea es una función de red empresarial y debe ser una decisión de implementación tomada con esas personas.
• La extensión DNS y las zonas DNS privadas deben existir antes de agregar cualquier servicio de PaaS para el que quiera configurar los registros DNS del punto de conexión privado.
• La extensión del centro virtual es un recurso regional, evite el tráfico entre regiones y establezca una extensión de centro por centro regional donde se espera la resolución DNS del punto de conexión privado.

Red virtual de radios

• De acuerdo con el principio de responsabilidad única, la red virtual de la extensión DNS solo debe contener los recursos necesarios para la resolución DNS y no debe compartirse con otros recursos.
• La red virtual de la extensión DNS debe seguir las mismas directrices de configuración en Adición de redes de radio.

Azure DNS Private Resolver

• Cada región debe tener una extensión DNS de centro virtual con una instancia de DNS Private Resolver.

• DNS Private Resolver solo requiere un punto de conexión de entrada y ningún punto de conexión de salida para este escenario. La dirección IP privada del punto de conexión de entrada es lo que se establece para el servicio DNS personalizado en la directiva de Azure Firewall (consulte la figura 5).

• Para lograr una mayor resistencia y un mayor control de carga, puede implementar varias instancias de DNS Private Resolver por región, con el proxy de Azure DNS configurado con varias direcciones IP para la resolución proxy.

  Figura 8: puntos de conexión de entrada para la instancia de DNS Private Resolver

• Siga las restricciones de red virtual para la instancia de DNS Private Resolver.

• El grupo de seguridad de red de la subred del punto de conexión de entrada de DNS Private Resolver solo debe permitir el tráfico UDP desde su centro regional al puerto 53. Debe bloquear el resto del tráfico entrante y saliente.

Zona DNS privada

Dado que Azure DNS Private Resolver resuelve DNS a través de Azure DNS, Azure DNS puede recoger las zonas DNS privadas vinculadas a la red virtual de la subred entrante.

• Vincule la zona DNS privada a la extensión del centro virtual para la red virtual DNS.
• Siga las instrucciones para administrar zonas DNS privadas para puntos de conexión privados.
• Si espera que los propietarios de recursos de PaaS administren sus propias entradas, configure RBAC en consecuencia o implemente una solución como la de Integración de Private Link y DNS a gran escala.

Consideraciones sobre escenarios

Con una extensión DNS de centro virtual bien administrada, volvamos a la carga de trabajo y abordaremos algunos puntos adicionales para ayudar a lograr los objetivos de resultados correctos en este escenario.

Cuenta de almacenamiento

• Establezca el Acceso a la red pública: Deshabilitado en Conectividad de red para asegurarse de que solo se puede acceder a la cuenta de almacenamiento a través de puntos de conexión privados.
• Agregue un punto de conexión privado a una subred de punto de conexión privado dedicado en la red virtual de la carga de trabajo.
• Envíe Azure Diagnostics al área de trabajo de Log Analytics de la carga de trabajo. Puede usar los registros de acceso para ayudar a solucionar problemas de configuración.

Seguridad de punto de conexión privado

Un requisito de esta solución es limitar la exposición de esta cuenta de almacenamiento. Una vez que quite el acceso público desde Internet al recurso de PaaS, debe abordar la seguridad de red privada.

Cuando Azure Firewall protege el tráfico privado en una topología en estrella tipo hub-and-spoke de Virtual WAN, el comportamiento predeterminado de Azure Firewall es denegar la conectividad de radio a radio. Esta configuración predeterminada impide que las cargas de trabajo de otras redes radiales accedan a puntos de conexión privados (y otros recursos) en la red virtual de la carga de trabajo. El tráfico completamente dentro de una red virtual no se enruta a través de Azure Firewall. Para controlar el acceso dentro de la red virtual y agregar una protección más detallada, tenga en cuenta las siguientes recomendaciones para el grupo de seguridad de red (NSG).

• Cree un grupo de seguridad de aplicaciones (ASG) para agrupar los recursos que tienen necesidades de acceso entrante o saliente similares. En este escenario, use un ASG para las máquinas virtuales cliente que necesitan acceder al almacenamiento y otra para las cuentas de almacenamiento a las que se tiene acceso. Consulte Configuración de un grupo de seguridad de aplicaciones (ASG) con un punto de conexión privado.
• Asegúrese de que la subred que contiene la máquina virtual de carga de trabajo tiene un grupo de seguridad de red.
• Asegúrese de que la subred que contiene los puntos de conexión privados tiene un grupo de seguridad de red.

Reglas de grupo de seguridad de red para la subred que contiene la máquina virtual de carga de trabajo

Además de cualquier otra regla de red que requiera la carga de trabajo, configure las reglas siguientes.

• Reglas de salida
  • Permita que el ASG de proceso acceda al ASG de la cuenta de almacenamiento.
  • Permita el ASG de proceso a la dirección IP privada de Azure Firewall del centro regional para UDP en el puerto 53.

*Figura 9: reglas de NSG para la subred de carga de trabajo

Reglas de NSG para subredes que contienen puntos de conexión privados

Se considera un procedimiento recomendado exponer los puntos de conexión privados en una subred pequeña y dedicada dentro de la red virtual que consume. Una razón es que puede aplicar rutas definidas por el usuario y directivas de red de grupo de seguridad de red para puntos de conexión privados para un control de tráfico y seguridad agregados.

Este escenario permite aplicar un grupo de seguridad de red altamente restrictivo.

• Reglas de entrada
  • Permitir que el ASG de proceso acceda al ASG de la cuenta de almacenamiento
  • Denegar todo el resto del tráfico
• Reglas de salida
  • Denegar todo el tráfico

*Figura 10: reglas de NSG para la subred de punto de conexión privado

Seguridad de punto de conexión privado en acción

En la imagen siguiente se muestra cómo seguir las consideraciones que se han descrito puede proporcionar seguridad de defensa en profundidad. En el diagrama se muestra una segunda red virtual de radio con una segunda máquina virtual. Esa carga de trabajo no puede acceder al punto de conexión privado.

Figura 11: solución de trabajo para un escenario de región única para Virtual WAN con Private Link y DNS

Descargue un archivo Visio de esta arquitectura.

Flujo DNS

El flujo DNS es exactamente el mismo que en el flujo de la solución.

Lo que es importante resaltar es que el FQDN se resuelve en la dirección IP privada y no en la dirección IP pública. Esta resolución significa que todos los radios siempre reciben la dirección IP privada de este servicio. Otro escenario describe cómo puede usar este enfoque para compartir un servicio de PaaS en varias cargas de trabajo que consumen. En este escenario de carga de trabajo única, esto no es un problema.

Flujo de HTTP

1. Con el resultado DNS en mano, la dirección IP privada de la cuenta de almacenamiento, el cliente emite una solicitud HTTP a stgworkload00.blob.core.windows.net.
2. La solicitud se envía a la dirección IP privada de la cuenta de almacenamiento. Esta solicitud produce un error adecuado por muchas razones:
   • Azure Firewall está configurado para proteger el tráfico privado, por lo que controla la solicitud. A menos que Azure Firewall tenga una regla de red o aplicación para permitir el flujo, Azure Firewall bloquea la solicitud.
   • No es necesario usar Azure Firewall en el centro para proteger el tráfico privado. Por ejemplo, si la red admite tráfico privado entre regiones, el NSG en la subred del punto de conexión privado todavía está configurado para bloquear todo el tráfico que no provenga de los orígenes del ASG de proceso dentro de la red virtual que hospeda la carga de trabajo.

Resumen

En este artículo se presenta un escenario en el que un cliente de máquina virtual se conecta a la cuenta de Azure Storage a través del punto de conexión privado de la cuenta de almacenamiento. El punto de conexión está en la misma red virtual que el cliente. El resto del acceso a la cuenta de almacenamiento está bloqueado. Este escenario necesita un registro DNS en el flujo DNS que pueda resolver el nombre de dominio completo (FQDN) de la cuenta de almacenamiento en la dirección IP privada del punto de conexión privado.

La topología de red inicial de este escenario presenta dos desafíos:

• No es posible vincular una zona DNS privada con los registros DNS necesarios para la cuenta de almacenamiento al centro virtual.
• La vinculación de una zona DNS privada a la subred de carga de trabajo no funciona. La topología de red inicial requiere que el servidor DNS predeterminado y las reglas de enrutamiento fuercen el uso de Azure Firewall en el centro regional.

La solución propuesta es que el equipo de red empresarial implemente una extensión de centro de conectividad virtual para DNS. Esta extensión permite al equipo de red empresarial exponer servicios DNS compartidos a radios de carga de trabajo que los requieran.

Recursos relacionados

• ¿Qué es un punto de conexión privado?
• Configuración de DNS para puntos de conexión privados de Azure
• Integración de Private Link y DNS a gran escala
• Azure Private Link en una red de topología en estrella tipo hub-and-spoke
• DNS para recursos locales y de Azure
• Conectividad de la zona de aterrizaje de datos de una sola región
• Uso de Private Link para conectar redes a Azure Monitor
• Azure DNS Private Resolver
• Acceso con seguridad mejorada a aplicaciones web multiinquilino desde una red local
• Aplicación web altamente disponible con redundancia de zona de línea de base
• Tutorial: Creación de una infraestructura DNS de punto de conexión privado con Azure Private Resolver para una carga de trabajo local