Guía de Private Link y DNS en Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Azure Private Link permite a los clientes acceder a los servicios de plataforma como servicio (PaaS) de Azure directamente desde redes virtuales privadas sin usar direcciones IP públicas. Para cada servicio, configure un punto de conexión privado que use una dirección IP privada de la red. A continuación, los clientes pueden usar el punto de conexión privado para conectarse de forma privada al servicio.

Los clientes siguen usando el nombre de dominio completo (FQDN) de un servicio para conectarse a él. Configure un DNS en la red para resolver el FQDN del servicio en la dirección IP privada del punto de conexión privado.

El diseño de la red y, en particular, la configuración de un DNS, son factores clave para admitir la conectividad de los puntos de conexión privados a los servicios. Este artículo forma parte de una serie de artículos que ofrecen una guía sobre la implementación de varios escenarios de Private Link. Incluso si ninguno de los escenarios coincide exactamente con su situación, debe ser capaz de adaptar los diseños para satisfacer sus necesidades.

Topología de red de inicio

La topología de red de inicio es una arquitectura de red que actúa como punto de partida para todos los escenarios de esta serie de artículos. La arquitectura es una red típica en estrella tipo hub-and-spoke que usa Azure Virtual WAN.

Figura 1: topología de red de inicio para todos los escenarios de punto de conexión privado y DNS

Descargue un archivo Visio de esta arquitectura. Esta topología tiene las siguientes características:

Se trata de una red en estrella tipo hub-and-spoke que se implementa con Azure Virtual WAN.
Hay dos regiones, cada una con un centro virtual protegido de Azure Firewall regional.
Cada centro virtual regional protegido tiene la siguiente configuración de seguridad para las conexiones de Azure Virtual Network:
- Tráfico de Internet: protegido por Azure Firewall. Todo el tráfico que sale a Internet fluye a través del firewall del centro regional.
- Tráfico privado: protegido por Azure Firewall. Todo el tráfico que transita de radio a radio fluye a través del firewall del centro regional.
Cada centro virtual regional está protegido con Azure Firewall. Los firewalls del centro regional tienen la siguiente configuración:
- Servidores DNS: predeterminado (proporcionado por Azure). El firewall del centro regional usa explícitamente Azure DNS para la resolución de FQDN en colecciones de reglas.
- Proxy DNS: habilitado. El firewall del centro regional responde a las consultas de DNS en el puerto 53. Reenvía consultas a Azure DNS para los valores no almacenados en caché.
- El firewall registra las evaluaciones de reglas y las solicitudes de proxy DNS en un área de trabajo de Log Analytics que se encuentra en la misma región. El registro de estos eventos es un requisito común de registro de seguridad de red.
Cada radio de red virtual conectada tiene su servidor DNS predeterminado configurado para ser la dirección IP privada del firewall del centro de conectividad regional. De lo contrario, la evaluación de la regla de FQDN puede no estar sincronizada.

Enrutamiento en varias regiones

Los centros de Virtual WAN protegidos tienen compatibilidad limitada con la conectividad entre centros cuando hay varios centros virtuales protegidos. Esta limitación afecta a escenarios de varios centros, intrarregionales y entre regiones. Por lo tanto, la topología de red no facilita directamente el filtrado del tráfico privado entre regiones a través de Azure Firewall. La compatibilidad con esta funcionalidad se proporciona mediante las directivas de enrutamiento y la intención de enrutamiento del centro de Virtual WAN. Esta funcionalidad actualmente se encuentra disponible en modo de vista previa.

En esta serie de artículos, se supone que el tráfico protegido interno no atraviesa varios centros. El tráfico que debe atravesar varios centros debe hacerlo en una topología paralela que no filtre el tráfico privado a través de un centro virtual protegido, sino que lo deje pasar.

Agregar redes de radio

Al agregar redes de radio, siguen las restricciones definidas en la topología de red de inicio. En concreto, cada red de radio está asociada a la tabla de rutas predeterminada que se encuentra en su centro regional y el firewall está configurado para proteger el tráfico privado y de Internet. En la captura de pantalla siguiente se muestra un ejemplo de configuración:

Figura 2: Configuración de seguridad para conexiones de red virtuales en el centro virtual

Desafíos clave

La topología de red de inicio crea desafíos para configurar DNS para puntos de conexión privados.

Aunque el uso de Virtual WAN ofrece una experiencia de centro administrado, la contrapartida es que la capacidad de influir en la configuración del centro virtual o de agregarle más componentes es limitada. Una topología tradicional en estrella tipo hub-and-spoke permite aislar las cargas de trabajo en radios al compartir servicios de red comunes, como registros DNS, en el centro autoadministrado. Normalmente, se vincula la zona DNS privada a la red del centro para que Azure DNS pueda resolver las direcciones IP del punto de conexión privado para los clientes.

Sin embargo, no es posible vincular zonas DNS privadas a centros de Virtual WAN , por lo que cualquier resolución DNS que se produzca dentro del centro no tiene en cuenta las zonas privadas. En concreto, se trata de un problema para Azure Firewall, el proveedor DNS configurado para radios de carga de trabajo, que usa DNS para la resolución FQDN.

Cuando se usan centros de Virtual WAN, parece intuitivo vincular zonas DNS privadas a las redes virtuales de radio en las que las cargas de trabajo esperan la resolución DNS. Sin embargo, como se indica en la arquitectura, el proxy DNS está habilitado en los firewalls regionales y se espera que todos los radios usen su firewall regional como origen DNS. Se llama a Azure DNS desde el firewall en lugar de desde la red de la carga de trabajo, por lo que los vínculos de zona DNS privados de la red de carga de trabajo no se usan en la resolución.

Nota:

Para configurar el firewall regional para que sea el proveedor de DNS del radio, configure el servidor DNS personalizado en la red virtual del radio para que apunte a la IP privada del firewall en lugar de al valor normal de Azure DNS.

Dada la complejidad que resulta de habilitar el proxy DNS en los firewalls regionales, repasemos las razones para habilitarlo.

Las reglas de red de Azure Firewall admiten límites basados en FQDN para controlar con mayor precisión el tráfico de salida que las reglas de aplicación no controlan. Esta característica requiere que el proxy DNS esté habilitado. Un uso común es limitar el tráfico del Protocolo de tiempo de red (NTP) a puntos de conexión conocidos, como time.windows.com.
Los equipos de seguridad pueden beneficiarse del registro de solicitudes DNS. Azure Firewall tiene compatibilidad integrada con el registro de solicitudes DNS, por lo que requerir que todos los recursos de radio usen Azure Firewall como su proveedor DNS garantiza una amplia cobertura de registro.

Para ilustrar los desafíos, en las secciones siguientes se describen dos configuraciones. Hay un ejemplo sencillo que funciona y uno más complejo que no, pero su error es instructivo.

Escenario de trabajo

El siguiente ejemplo es una configuración básica de un punto de conexión privado. Una red virtual contiene un cliente que requiere el uso de un servicio PAAS mediante un punto de conexión privado. Una zona DNS privada vinculada a la red virtual tiene un registro A que resuelve el FQDN del servicio en la dirección IP privada del punto de conexión privado. En el diagrama siguiente se ilustra el flujo.

Figura 3: Configuración básica de DNS para puntos de conexión privados

Descargue un archivo Visio de esta arquitectura.

El cliente emite una solicitud para stgworkload00.blob.core.windows.net.
Azure DNS, el servidor DNS configurado para la red virtual, se consulta para obtener la dirección IP de stgworkload00.blob.core.windows.net.

La ejecución del siguiente comando desde la máquina virtual (VM) muestra que la máquina virtual está configurada para usar Azure DNS (168.63.129.16) como proveedor DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
La zona de DNS privado privatelink.blob.core.windows.net está vinculada a la red virtual de carga de trabajo, por lo que Azure DNS incorpora registros de la red virtual de carga de trabajo en su respuesta.
Dado que existe un registro A en la zona de DNS privado que asigna el FQDN, stgworkload00.privatelink.blob.core.windows.net, a la dirección IP privada del punto de conexión privado, se devuelve la dirección IP privada 10.1.2.4.

Al ejecutar el siguiente comando desde la máquina virtual, se resuelve el FQDN de la cuenta de almacenamiento en la dirección IP privada del punto de conexión privado.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
La solicitud se emite a la dirección IP privada del punto de conexión privado que, en este caso, es 10.1.2.4.
La solicitud se enruta a través de Private Link a la cuenta de almacenamiento.

El diseño funciona porque Azure DNS:

Es el servidor DNS configurado para la red virtual.
Conoce la zona DNS privada vinculada.
Resuelve las consultas de DNS mediante los valores de la zona.

Escenario no laborable

El siguiente ejemplo es un intento sencillo de usar puntos de conexión privados en la topología de red de inicio. No es posible vincular una zona DNS privada a un centro de Virtual WAN. Por lo tanto, cuando los clientes están configurados para usar el firewall como su servidor DNS, las solicitudes DNS se reenvían a Azure DNS desde el centro virtual, que no tiene una zona DNS privada vinculada. Azure DNS no sabe cómo resolver la consulta más allá de proporcionar el valor predeterminado, que es la dirección IP pública.

Figura 4: intento sencillo de usar puntos de conexión privados en la topología de red de inicio

Descargue un archivo Visio de esta arquitectura.

El cliente emite una solicitud para stgworkload00.blob.core.windows.net.

La ejecución del siguiente comando desde la máquina virtual muestra que la máquina virtual está configurada para usar el firewall del centro virtual como proveedor DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
El firewall tiene el proxy DNS habilitado con la configuración predeterminada para reenviar solicitudes a Azure DNS. La solicitud se reenvía a Azure DNS.
Azure DNS no puede resolver stgworkload00.blob.core.windows.net en la dirección IP privada del punto de conexión privado porque:
1. Una zona DNS privada no se puede vincular a un centro de Virtual WAN.
2. Azure DNS no conoce una zona DNS privada vinculada a la red virtual de carga de trabajo, ya que el servidor DNS configurado para la red virtual de carga de trabajo es Azure Firewall. Azure DNS responde con la dirección IP pública de la cuenta de almacenamiento.
Al ejecutar el siguiente comando desde la máquina virtual, se resuelve el FQDN de la cuenta de almacenamiento en la dirección IP pública de la cuenta de almacenamiento.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Dado que Azure Firewall está proxyando las consultas de DNS, podemos registrarlas. A continuación se muestran los registros de ejemplo de proxy DNS de Azure Firewall.
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
El cliente no recibe la dirección IP privada para el punto de conexión de Private Link y no puede establecer una conexión privada con la cuenta de almacenamiento.

El comportamiento anterior es el esperado. Es el problema que abordan los escenarios.

Escenarios

Aunque las soluciones a este problema son similares, el análisis de los escenarios habituales de carga de trabajo muestra cómo las soluciones abordan los requisitos de diferentes situaciones. La mayoría de los escenarios constan de un cliente que accede a uno o varios servicios PaaS a través de un punto de conexión privado. Se adhieren a la topología de red de inicio, pero difieren en sus requisitos de carga de trabajo. Los escenarios se inician de forma sencilla, con un cliente que accede a un único servicio PaaS regional. Se vuelven cada vez más complejos, agregando más visibilidad de red, regiones y servicios PaaS.

En la mayoría de los escenarios, el cliente se implementa como una máquina virtual y el servicio PaaS al que accede el cliente es una cuenta de almacenamiento. Debe considerar las máquinas virtuales como un sustituto de cualquier recurso de Azure que tenga una NIC expuesta en una red virtual, como Virtual Machine Scale Sets, los nodos Azure Kubernetes Service o cualquier otro servicio que se enrute de forma similar.

Importante

La implementación de Private Link para la cuenta de Azure Storage puede diferir de forma sutil de otros servicios PaaS, pero para muchos es una buena opción. Por ejemplo, algunos servicios quitan los registros de FQDN mientras se exponen a través de Private Link, lo que podría dar lugar a comportamientos diferentes, pero estas diferencias normalmente no suelen importar en las soluciones para estos escenarios.

Cada escenario comienza con el estado final deseado y detalla la configuración necesaria para pasar de la topología de red de inicio al estado final deseado. La solución a cada escenario usa el patrón de extensiones de centro virtual. Este patrón aborda cómo exponer servicios compartidos de forma aislada y segura, como una extensión conceptual a un centro regional. La tabla siguiente contiene vínculos al patrón de extensión del centro virtual y a los escenarios.

Guía	Descripción
Región única, PaaS dedicada	Una carga de trabajo de una sola región accede a un recurso PaaS dedicado.

Pasos siguientes

Lea el escenario de recursos paaS dedicado de una sola región

Compartir a través de

Guía de Private Link y DNS en Azure Virtual WAN