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 Azure servicios PaaS 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 usan el nombre de dominio completo (FQDN) de un servicio para conectarse al servicio. Configura el DNS en tu red para resolver el FQDN del servicio a la dirección IP privada del punto de conexión privado.

El diseño de la red y, en particular, la configuración de DNS, son factores clave para admitir la conectividad de puntos de conexión privados con los servicios. Este artículo es uno de una serie de artículos que proporcionan instrucciones sobre cómo comprender el comportamiento de Private Link en entornos de WAN Virtual. Se presentan varios escenarios, incluidos ejemplos restringidos intencionadamente que se usan para ilustrar los desafíos comunes de DNS y enrutamiento. Incluso si ninguno de los escenarios coincide exactamente con su situación, debe poder adaptar los diseños para satisfacer sus necesidades.

Inicio de la topología de red

La topología de red inicial es la arquitectura base para todos los escenarios de esta serie. Es una red típica tipo hub-and-spoke que usa Azure Virtual WAN.

Figura 1: Inicio de la topología de red 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:

Es una red en estrella tipo hub-spoke que se implementa con Azure Virtual WAN.
Hay dos regiones, cada una con un centro virtual protegido que incluye Azure Firewall.
Cada centro virtual regional protegido tiene la siguiente configuración de seguridad para las conexiones de Azure Virtual Network:
- Tráfico de Internet: Seguridad mediante Azure Firewall: todo el tráfico a Internet fluye a través del firewall del hub regional.
- Tráfico privado: Protegido por Azure Firewall - Todo el tráfico inter-radio fluye a través del firewall del hub 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 DNS en el puerto 53. Reenvía las consultas a Azure DNS para los valores sin almacenar en caché.
- El firewall registra las evaluaciones de reglas y las solicitudes de proxy DNS a un área de trabajo de Log Analytics que se encuentra en la misma región. Este registro es un requisito de seguridad de red estándar.
Cada radio usa la dirección IP privada del firewall regional como servidor DNS. De lo contrario , la evaluación de la regla FQDN puede no estar sincronizada.

Enrutamiento de varias regiones

Intención de enrutamiento del hub de Virtual WAN y políticas de enrutamiento permiten controlar cómo fluye el tráfico entre hubs y si dicho tráfico se inspecciona mediante Azure Firewall u otra solución de seguridad.

De forma predeterminada, en una implementación de Virtual WAN de varios concentradores, el tráfico privado inter-hub no pasa por Azure Firewall. En su lugar, Azure utiliza su conectividad de centro a centro administrada por Virtual WAN incorporada, que se ejecuta en paralelo a las rutas de tráfico protegidas dentro de cada centro. Esto significa que el tráfico privado que se mueve entre centros no se inspecciona automáticamente.

Si necesita Azure Firewall para inspeccionar el tráfico privado entre centros de conectividad, puede habilitar este comportamiento configurando un Private Traffic routing policy y activando inter-hub inspection. Esto obliga a que el tráfico privado entre centros se reenvíe a través de Azure Firewall para su inspección.

Esta configuración es más avanzada y está fuera del ámbito de esta serie.

Adición de redes de satélite

Al agregar redes radiales, aplique las restricciones definidas en la topología de red inicial. Cada spoke se asocia a la tabla de rutas predeterminada de su centro regional, y Azure Firewall protege tanto el tráfico de internet como el privado. En la captura de pantalla siguiente se muestra un ejemplo de configuración:

Figura 2: Configuración de seguridad para las conexiones de red virtual en el hub virtual

Desafíos clave

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

Aunque Virtual WAN proporciona una experiencia de centro administrado, la contrapartida es que hay una capacidad limitada para influir en la configuración del centro virtual o agregarle componentes. Una topología centralizada tipo hub-spoke permite aislar las cargas de trabajo en extremos mientras se comparten servicios de red comunes, como los registros DNS, en el hub autoadministrado. Normalmente se vincula la zona DNS privada a la red del concentrador 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 los hubs de Virtual WAN, por lo que cualquier resolución DNS dentro del hub no reconoce las zonas privadas. En concreto, esto crea un problema para Azure Firewall, que actúa como proveedor DNS para redes de carga de trabajo y utiliza DNS para resolver nombres de dominio completos (FQDN).

Cuando se usan centros de Virtual WAN, puede parecer intuitivo vincular zonas DNS privadas a las redes virtuales de radio en las que las cargas de trabajo esperan resolución DNS. Sin embargo, como se indica en la arquitectura, el proxy DNS está habilitado en los firewalls regionales y todos los spokes deben usar su firewall regional como origen DNS. La consulta Azure DNS se origina desde el firewall del centro, no desde la red virtual de carga de trabajo, por lo que los vínculos de zona DNS privadas en la red de radio no se usan en la resolución.

Dado que los centros de WAN virtual no se pueden vincular a zonas de DNS privado, el enfoque recomendado para la resolución de DNS en escenarios de Private Link es Azure DNS Private Resolver, implementado en una red virtual de extensión de concentrador. Esto permite la resolución escalable de DNS privada(sensible a las zonas) para las cargas de trabajo conectadas a los hubs de Virtual WAN. En los artículos de seguimiento de esta serie se muestra cómo el solucionador privado dns completa la arquitectura.

Nota:

Para configurar el firewall regional como proveedor DNS del spoke, establezca el servidor DNS personalizado en la red virtual del spoke para que apunte a la dirección IP privada del firewall en lugar del valor normal de Azure DNS.

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

Las reglas de red de Azure Firewall admiten límites basados en FQDN para controlar con más precisión el tráfico de salida que no gestionan las reglas de aplicaciones. El proxy DNS debe estar habilitado para esta característica. 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.
El registro de solicitudes DNS beneficia a los equipos de seguridad. Azure Firewall tiene compatibilidad integrada con el registro de solicitudes DNS, así que asegurarse de que todos los recursos de satélite usen Azure Firewall como su proveedor DNS asegura una cobertura extensa 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 ejemplo siguiente es una configuración básica de punto de conexión privado. Una red virtual contiene un cliente que requiere un servicio PaaS a través de 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. El siguiente diagrama ilustra el flujo.

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

Descargar un archivo de 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 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 DNS privada está vinculada a la red privatelink.blob.core.windows.net 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 DNS privada 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 es 10.1.2.4.
La solicitud se enruta a través de Private Link a la cuenta de almacenamiento.

Este diseño funciona porque Azure DNS:

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

Escenario no operativo

El ejemplo siguiente es un intento naïve de usar puntos de conexión privados en la topología de red inicial. 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 servidor DNS, las solicitudes DNS se reenvía a Azure DNS desde el centro virtual, que no tiene una zona DNS privada vinculada. Azure DNS no sabe cómo resolver la consulta aparte de proporcionar el valor predeterminado, que es la dirección IP pública.

Figura 4: Intento naïve de usar puntos de conexión privados en la topología de red inicial

Descargar un archivo de Visio de esta arquitectura.

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

Al ejecutar el siguiente comando desde la máquina virtual se muestra que la máquina virtual está configurada para usar el firewall del centro de conectividad 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 habilitado el proxy DNS 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 a la dirección IP privada del punto de conexión privado debido a:
1. Una zona DNS privada no se puede vincular a un centro de Virtual WAN.
2. Azure DNS no es consciente de 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á actuando como proxy para las consultas DNS, podemos registrarlas. A continuación se muestran los registros de proxy DNS de Azure Firewall de ejemplo.
```
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 a la cuenta de almacenamiento.

Este comportamiento es normal. Es el problema que abordan los escenarios.

Escenarios

Las soluciones a este problema son similares, pero el examen de escenarios comunes de carga de trabajo muestra cómo cada solución cumple distintos requisitos. 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 inicial, pero difieren en sus requisitos de carga de trabajo. Los escenarios comienzan con un cliente que accede a un único servicio PaaS regional. Se vuelven incrementalmente más complejos y agregan 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 para cualquier recurso de Azure que tenga una NIC que esté expuesta en una red virtual, como los conjuntos de escalado de máquinas virtuales, los nodos de Azure Kubernetes Service o cualquier otro servicio que enrute de forma similar.

Importante

La implementación de Private Link para la cuenta de Azure Storage puede diferir de otros servicios paaS de maneras sutiles, pero se alinea bien con muchos otros servicios. Por ejemplo, algunos servicios quitan registros FQDN mientras se exponen a través de Private Link, lo que podría dar lugar a comportamientos diferentes, pero estas diferencias normalmente no son un factor en las soluciones para estos escenarios.

Cada escenario comienza con el estado final deseado y detalla la configuración necesaria para obtener de la topología de red inicial al estado final deseado. La solución utiliza el patrón de extensiones virtual hub, que expone los servicios compartidos como una extensión segura de un hub regional, junto con Azure DNS Private Resolver para la resolución de DNS para puntos de conexión privados en entornos de WAN Virtual. 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 dedicados en una sola región.

Comentarios

¿Le ha resultado útil esta página?