Uso de Private Link en Virtual WAN

Azure Private Link es una tecnología que le permite conectar ofertas de plataforma como servicio de Azure mediante la conectividad de direcciones IP privadas exponiendo puntos de conexión privados. Con Azure Virtual WAN, puede implementar un punto de conexión privado en una de las redes virtuales conectadas a cualquier concentrador virtual. Este vínculo privado proporciona conectividad a cualquier otra red virtual o rama conectada a la misma Virtual WAN.

Antes de empezar

En los pasos de este artículo se da por hecho que ha implementado una instancia de Virtual WAN con uno o más concentradores y al menos dos redes virtuales conectadas a Virtual WAN.

Para crear una nueva WAN virtual y un nuevo centro, siga los pasos que se describen en los siguientes artículos:

• Creación de una instancia de Virtual WAN
• Creación de un centro de conectividad
• Conectar una red virtual a un concentrador

Consideraciones de enrutamiento con Private Link en Virtual WAN

La conectividad del punto de conexión privado tiene estado. Cuando se establece una conexión a un punto de conexión privado desde Virtual WAN, el tráfico se enruta por uno o varios saltos de tráfico mediante diferentes componentes de Virtual WAN (por ejemplo, enrutador de centro virtual, puerta de enlace de ExpressRoute, VPN Gateway, Azure Firewall o NVA). El tráfico exacto de saltos se basa en las configuraciones de enrutamiento de Virtual WAN. En segundo plano, la capa de red definida por el software de Azure envía todos los paquetes relacionados con un único flujo de cinco tuplas a una de las instancias de back-end que atiende diferentes componentes de Virtual WAN. El tráfico enrutado de manera asimétrica (por ejemplo, el tráfico correspondiente a un único flujo de cinco tuplas enrutado a instancias de back-end diferentes) no es compatible y se quita mediante la plataforma Azure.

Durante los eventos de mantenimiento en la infraestructura de Virtual WAN, las instancias de back-end se reinician de manera individual, lo que puede provocar problemas de conectividad intermitentes en el punto de conexión privado, ya que el mantenimiento de la instancia del flujo no está disponible temporalmente. Se puede producir un problema similar cuando Azure Firewall o el enrutador del centro de conectividad virtual se escala horizontalmente. Se puede equilibrar la carga del mismo flujo de tráfico en una nueva instancia de back-end diferente de la que actualmente atiende el flujo.

Para mitigar el impacto de los eventos de mantenimiento y escalado horizontal en el tráfico de Private Link o punto de conexión privado, tenga en cuenta los procedimientos recomendados siguientes:

• Configure el valor de tiempo de espera de TCP de la aplicación local entre 15 y 30 segundos. Un valor de tiempo de espera de TCP más pequeño permitirá que el tráfico de la aplicación se recupere más rápidamente de los eventos de mantenimiento y escalado horizontal. Como alternativa, pruebe otros valores de tiempo de espera de aplicación para determinar el adecuado en función de los requisitos.
• Realice un cambio de escala previo de los componentes de Virtual WAN para controlar las ráfagas de tráfico y evitar que se produzcan eventos de escalado automático. Para el enrutador del centro virtual, puede establecer las unidades de infraestructura de enrutamiento mínimas en el enrutador del concentrador para evitar el escalado durante las ráfagas de tráfico.

Por último, si usa conectividad local entre Azure y el entorno local mediante VPN o ExpressRoute, asegúrese de que el dispositivo local está configurado para usar el mismo túnel VPN o el mismo enrutador de Microsoft Enterprise Edge que el próximo salto para cada cinco tuplas correspondiente al tráfico del punto de conexión privado.

Creación de un punto de conexión de vínculo privado

Puede crear un punto de conexión de vínculo privado para muchos servicios diferentes. En este ejemplo, usaremos Azure SQL Database. Puede encontrar más información sobre cómo crear un punto de conexión privado para una instancia de Azure SQL Database en Inicio rápido: Creación de un punto de conexión privado mediante Azure Portal. La siguiente imagen muestra la configuración de red de Azure SQL Database:

Después de crear la instancia de Azure SQL Database, puede comprobar que la dirección IP del punto de conexión privado examine los puntos de conexión privados:

Al hacer clic en el punto de conexión privado que hemos creado, debería ver su dirección IP privada y su nombre de dominio completo (FQDN). El punto de conexión privado debe tener una dirección IP en el intervalo de la red virtual (10.1.3.0/24):

Comprobación de la conectividad de la misma red virtual

En este ejemplo, se comprobará la conectividad a la instancia de Azure SQL Database desde una máquina virtual de Linux con las herramientas de MS SQL instaladas. El primer paso consiste en comprobar que la resolución de DNS funciona y que el nombre de dominio completo de Azure SQL Database se resuelve en una dirección IP privada, en la misma red virtual donde se ha implementado el punto de conexión privado (10.1.3.0/24):

nslookup wantest.database.windows.net

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

Como puede ver en la salida anterior, el nombre de dominio completo wantest.database.windows.net está asignado a wantest.privatelink.database.windows.net y que la zona DNS privada creada a lo largo del punto de conexión privado se resolverá en la dirección IP privada 10.1.3.228. Al examinar la zona DNS privada, se confirmará que hay un registro A para el punto de conexión privado asignado a la dirección IP privada:

Después de comprobar la resolución de DNS correcta, podemos intentar conectar a la base de datos:

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"

10.1.3.75

Como puede ver, usamos una consulta SQL especial que nos proporciona la dirección IP de origen que SQL Server ve desde el cliente. En este caso, el servidor ve el cliente con su dirección IP privada (10.1.3.75), lo que significa que el tráfico viaja desde la red virtual directamente hasta el punto de conexión privado.

Establezca las variables username y password para que coincidan con las credenciales definidas en la instancia de Azure SQL Database para que los ejemplos de esta guía funcionen.

Conexión desde otra red virtual

Ahora que una red virtual de Azure Virtual WAN tiene conectividad con el punto de conexión privado, todas las demás redes virtuales y ramas conectadas a Virtual WAN también pueden tener acceso a ella. Debe proporcionar conectividad a través de cualquiera de los modelos admitidos por la Azure Virtual WAN, como el escenario universal o el escenario de la red virtual de servicios compartidos, por mencionar dos ejemplos.

Cuando tenga conectividad entre la red virtual o la rama en la red virtual donde se ha implementado el punto de conexión privado, deberá configurar la resolución de DNS:

• Si se conecta al punto de conexión privado desde una red virtual, puede usar la misma zona privada que se creó con la instancia de Azure SQL Database.
• Si se conecta al punto de conexión privado desde una rama (VPN de sitio a sitio, VPN de punto a sitio o ExpressRoute), debe usar la resolución DNS local.

En este ejemplo, nos estamos conectando desde una red virtual diferente. Primero adjuntaremos la zona DNS privada a la nueva red virtual para que las cargas de trabajo puedan resolver el nombre de dominio completo de Azure SQL Database en la dirección IP privada. Esto se hace a través de la vinculación de la zona DNS privada a la nueva red virtual:

Ahora, todas las máquinas virtuales de la red virtual conectada deberían resolver correctamente el nombre de dominio completo de Azure SQL Database en la dirección IP privada del vínculo privado:

nslookup wantest.database.windows.net

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

Para comprobar de nuevo que esta red virtual (10.1.1.0/24) tiene conectividad con la red virtual original en la que se configuró el punto de conexión privado (10.1.3.0/24), puede comprobar la tabla de rutas efectiva en cualquier máquina virtual de la red virtual:

Como puede ver, hay una ruta que apunta a la red virtual 10.1.3.0/24 inyectada por las puertas de enlace de red virtual de Azure Virtual WAN. Ahora ya podemos probar la conectividad a la base de datos:

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"

10.1.1.75

En este ejemplo, hemos visto que la creación de un punto de conexión privado en una de las redes virtuales conectadas a una instancia de Virtual WAN proporciona conectividad al resto de redes virtuales y ramas de dicha instancia.

Pasos siguientes

Para más información sobre Virtual WAN, consulte las preguntas más frecuentes.