Microsoft Azure Files: Migración, Conexión Privada vía Private Link utilizando DNS Privados para Clientes VPN en Azure

Según vayamos avanzando en la migración de nuestros servicios On-Premises o IaaS al Cloud (Azure, Amazon, etc…), nos van surgiendo diferentes necesidades que debemos ser capaces de ir técnicamente solventando. En esta ocasión, voy a comentar como implementar una solución de carpetas compartidas en Azure Files con integración con nuestro ADDS, “publicación” DFS  y como los clientes ubicados en diferentes ubicaciones (Azure, On-Premises, Clientes VPN) pueden conectarse utilizando los enlaces privados de Azure.

Me voy a centrar “únicamente” en la conexión privada (Azure Private Link) desde las diferente ubicaciones de los usuarios, donde jugará un papel importante nuestros servidores DNS. Por lo que, algunas configuraciones no las trataré en este artículo pero si os dejo los enlaces a diferentes artículos que había publicado anteriormente donde hablo de ello:

• Azure Private Link: configuración del Private Link
• Microsoft Azure: Infraestructura VDI con Azure Files, DFS, GPOs y Licenciamiento Usuarios Automático: integración de una cuenta de almacenamiento con nuestro ADDS
• Microsoft Azure: Always On VPN + Windows 10 Pro + GPO: configuración de los clientes VPN con Azure
• Moviendo nuestros servicios y máquinas virtuales a Azure (Parte II): configuración de una VPN Site-to-Site entre Azure y On-Premises
• Microsoft Azure: VPN S2S en Alta Disponibilidad desde On-Premises ajustando Pesos de Rutas en Azure: configuración de Alta Disponibilidad de una VPN Site-to-Site de Azure

Dicho esto, antes de nada os voy a mostrar como va creciendo nuestra topología y vamos incluyendo nuevos servicios, en este caso la migración de nuestros File Server (On-Premises o IaaS) y la integración con el resto de servicios:

Los objetivos a conseguir son los siguientes:

• Migración de un file server a una carpeta compartida de Azure utilizando Azure Files Sync
• Conectar vía Private Link a los usuarios utilizando DNS Privados de Azure y una GPO para configurar DNS NRPT para los clientes VPN

Como os había comentado, no voy a comentar como configurar una cuenta de almacenamiento para tener carpetas compartidas, voy a partir de la base que es algo que ya tenemos configurado (lo explico aquí :Microsoft Azure: Infraestructura VDI con Azure Files, DFS, GPOs y Licenciamiento Usuarios Automático). Por lo que me voy a centrar en como migrar nuestro File Server a nuestra cuenta de almacenamiento vía SMB pero utilizando un servicio de sincronización como es Azure File Server, pero antes de nada aquí os dejo un texto de Microsoft de que es Azure Files Sync:

Use Azure File Sync para centralizar los recursos compartidos de archivos de su organización en Azure Files sin renunciar a la flexibilidad, el rendimiento y la compatibilidad de un servidor de archivos local. Azure File Sync transforma Windows Server en una caché rápida de los recursos compartidos de archivos de Azure. Puede usar cualquier protocolo disponible en Windows Server para acceder a sus datos localmente, como SMB, NFS y FTPS.

Antes de empezar con las configuraciones, revisar si cumplís los requisitos previos:

1. Un recurso compartido de archivos de Azure en la misma región en la que quiere implementar Azure File Sync. Para más información, consulte:
   • Disponibilidad en regiones de Azure File Sync.
   • Creación de un recurso compartido de archivos para obtener una descripción paso a paso sobre cómo crear un recurso compartido de archivos.
2. Al menos una instancia de Windows Server o un clúster de Windows Server compatible para la sincronización con Azure File Sync. Para más información sobre las versiones compatibles de Windows Server y los recursos del sistema recomendados, consulte Consideraciones sobre el servidor de archivos de Windows.

Si ya cumplimos todos los requisitos, veamos el proceso de configuración de Azure File Sync. Lo primero desde el Portal de Azure creamos nuestro recurso de Azure File Sync:

Ahora especificamos la suscripción, grupo de recursos, nombre de del servicio de sincronización y la región:

Asignamos etiquetas (opcional pero recomendable):

Antes de completar el proceso nos muestra un resumen del mismo, si está todo correcto, pulsamos en Crear.

El proceso no durará más de 1min, es algo que se implementa muy rápidamente.

Una vez que ya tenemos el servicio creado, lo primero que haremos será crear un Grupo de Sincronización, el cual se utilizará para definir las características de replicación de alguna de las carpetas a migrar:

Ahora definimos los siguientes campos:

• Nombre del grupo de sincronización: especificamos un nombre identificativo de lo que vamos a migrar (contenido de las carpetas por ejemplo)
• Suscripción: elegimos nuestra suscripción
• Cuenta de almacenamiento: elegimos la cuenta de almacenamiento donde tenemos nuestras carpetas compartidas que vamos a utilizar para mantener sincronizadas con los recursos de On-Premises/IaaS
• Recurso compartido de Archivos de Azure: elegimos la carpeta compartida que hemos creado en la cuenta de almacenamiento y queremos mantener sincronizada

Una vez que tengamos todo cubierto, pulsamos en Crear:

En cuestión de segundos ya tenemos nuestro grupo de sincronización, esto debemos hacerlo con todas las carpetas que queramos mantener sincronizadas:

Ahora tenemos que registrar nuestros servidores de ficheros en el servicio de Azure Files Sync, para ello desde la sección de Servidores Registrados nos descargamos el agente de Azure Files Sync en cada servidor que queremos conectar con dicho servicio:

Este proceso no tiene nada, simplemente descargamos el fichero para nuestra versión de Windows:

 

Paso importante, definir una ventana de revisión de actualización automática del Agente de Azure Files Sync:

Una vez que finalice el proceso de instalación, pulsaremos en Finish:

Ahora nos solicita que iniciemos sesión, para ello, pulsamos en Sign In:

Una vez que hayamos introducido nuestras credenciales (a ser posible con el Rol de Global Administrator) elegimos la suscripción, Grupo de Recursos, el servicio de sincronización donde vamos a registrar nuestro servidor y pulsamos en Register:

Si todo está correcto, veremos algo parecido a esto indicando que se ha completado correctamente el registro:

Si ahora volvemos al Portal de Azure y a la sección de Servidores registrados dentro desde nuestro recurso de Azure Files Sync veremos que ya tenemos nuestros servidor registrado:

Ahora, debemos indicarle las carpetas que queremos replicar, para ello, pulsamos sobre el servidor registrado y pulsamos en Agregar punto de conexión al servidor. Debemos elegir el servidor registrado (podemos tener varios servidores registrados) y la ruta de acceso local de la carpeta en el servidor y pulsamos en Crear:

Se inicia el proceso de la creación del punto de conexión:

Se habilita la sincronización:

Ahora ya tenemos el primero punto de conexión configurado, de momento en estado Pendiente:

En cuestión de unos minutos se cambia el estado a Cargar y descargar:

Si pulsamos en la punto de conexión de servidor podemos ver los detalles del estado, ahora como estamos en Cargar y descargar vemos que está ya sincronizando los ficheros y nos indica los que quedan pendientes de sincronizar (es un proceso bidireccional):

Pues con esto ya tenemos configurada nuestra cuenta de almacenamiento sincronizándose con la carpeta local de nuestro servidor de ficheros, los usuarios podrán conectarse vía SMB al servidor y seguir trabajando con los ficheros y los usuarios que van por la cuenta de almacenamiento de Azure verán dichos documentos actualizados (el revés más de lo mismo).

Además, tenemos la posibilidad de ir viendo la evolución desde el mismo grupo de sincronización:

Ahora es cuestión de tiempo, esperar a que termine de migrar y que tengamos ambos escenarios 100% sincronizados. Pues ahora toca realizar algunas configuraciones para que todos los equipos puedan llegar a la carpeta compartida de Azure Files, la cual tiene como ruta por defecto \\nombredecuenta.files.core.windows.net\carpeta. Claramente, queremos y debemos llegar a vía Private Link que para eso lo hemos configurado previamente (Azure Private Link) además con la configuración de DNS privados:

Por lo que, para que los clientes se puedan conectar utilizando la IP Privada, los equipos deben ser capaces de resolver (DNS) el nombre de la cuenta de almacenamiento  nombredecuenta.files.core.windows.net con esta IP Privada. Para esto, sino utilizamos los DNS de Azure en nuestros clientes no será posible, porque si tenemos un Directorio Activo (ADDS), los equipos tendrán como servidores DNS los servidores DNS que tengamos en nuestro Directorio Activo, por lo que no serán capaces de resolver la IP interna del Private Link y no podrán conectarse.

Tenemos varias posibilidades para que los equipos puedan resolver la IP interna del nombre de la cuenta de almacenamiento:

• Modificar el fichero HOST del equipo
• Utilizar como servidor DNS la IP de Azure (168.63.129.16): ¿Qué es la dirección IP 168.63.129.16?
• Configurar Reenviadores Condicionales
• Configurar una Zona DNS para files.core.windows.net

Claramente modificar el fichero HOST o configurar el DNS de Azure teniendo un  ADDS no es lo más recomendable, por lo que para que los clientes puedan resolver la IP interna de la cuenta de almacenamiento nuestros servidores DNS internos tienen que ser capaces de resolver el nombre de la cuenta de almacenamiento con la IP Privada del Private Link.

Podemos hacerlo de varias formas:

• Reenviadores Condicionales: permite que todas las peticiones DNS xxx.files.core.windows.net las resolverá la IP del servidor DNS de Azure:

• Nueva Zona: smbcuenta.privatelink.file.core.windows.net: con esta configuración debemos tener en cuenta que si tenemos más Private Links para más cuentas de almacenamiento debemos acordarnos de crear manualmente dichas cuentas con la IP del Private Link. La zona la tendremos que crear conociendo los nombres de las zonas privadas o públicas de cada servicio: https://docs.microsoft.com/es-es/azure/private-link/private-endpoint-dns. En el caso de las Azure Files estos son los nombres de dichas zonas:

Y la configuración de nuestra zona es la siguiente:

Como todos los clientes conectados localmente en alguna de las sedes conectadas vía VPN (a excepción de los clientes VPN con Split-Tunneling) a Azure tienen como servidor DNS la IP de alguno de los servidores DNS de nuestro ADDS, podrán resolver correctamente la IP del Private Link puesto que los servidores DNS lo resolverán sin problema la IP del FQDN de la cuenta de almacenamiento.

A continuación os muestro la resolución de nombres por un equipo con los servidores DNS de nuestro ADDS:

Y ahora os muestro un equipo que tiene DNS Públicos (8.8.8.8, 1.1.1.1), como vemos resuelve la IP Pública de la cuenta de almacenamiento (la cual tenemos filtrada para que nadie se conecte por la parte pública)

Pues hasta aquí todo normal, los equipos de la red privada tienen como servidores DNS los servidores DNS de nuestro ADDS y con la configuración de nuestros servidores DNS resuelve sin problema. Para ello, nos hemos apoyado en configurar o bien una zona o reenviadores condicionales (utilizando la IP del servidor DNS de Azure: 168.63.129.16).

Pero ahora tenemos que hacer que los clientes VPN resuelvan correctamente la zona DNS privatelink.file.core.windows.net para que sea capaz de encontrar el nombre de la cuenta de cuenta de almacenamiento para acceder vía Private Link. A priori podéis pensar que con la configuración que hemos realizado será suficiente, pero ya os digo que no si tenéis configurado Split-Tunneling y/o Split-DNS los equipos no serán capaces de resolver el nombre de la cuenta.

Antes de continuar vamos a refrescar los siguientes términos:

• Split-Tunneling: definir que tráfico va por el túnel VPN y que tráfico va directo a Internet. Esto nos permite que los clientes VPN solo envíen tráfico por la VPN que va dirigido a alguno de los servicios internos y el resto (Internet) por su propia conexión a Internet.
• Split-DNS: esto nos permite que estando conectado por la VPN el equipo resuelva los registros del propio dominio mediante el túnel VPN (host internos) y el resto directamente con los DNS configurados en su interface de red.

Como es muy común que los clientes VPN tengan configurado Split-Tunneling, evitando así que todo el tráfico de los clientes VPN sea por la VPN para evitar saturaciones de las líneas de datos de las empresas, también es muy probable que tengamos Split-DNS para que podamos implementar de “forma correcta” el Split-Tunneling y tengamos una correcta resolución DNS.

Dicho esto, si tenemos un equipo conectado vía VPN (SSTP, IKEv2, etc.. ) con Split-DNS y Split-Tunneling, el equipo resolverá DNS internos cuando quiera resolver nombres del propio dominio del equipo, pero los nombres de dominio externos lo hará utilizando los propios DNS que tenga el equipo. Como esto es así, cuando el equipo quiera resolver el registro cuenta.file.core.windows.net (CNAME cuenta.privatelink.file.core.windows.net) lo hará siempre  vía servidores DNS públicos  y por lo tanto obtendrá la IP Pública de la cuenta de almacenamiento y no podrá conectarse porque recordar que lo tenemos filtrado por motivos de seguridad.

Para estos casos, la solución es crear una GPO y configurar la resolución de nombres basadas en políticas: (The NRPT). La configuración es muy sencilla, creamos y editamos una GPO  y vamos a Computer Configuration – Windows Settings – Name Resolution Policy y añadimos  las siguientes configuraciones (cada uno con sus servidores DNS internos):

Una vez que esta configuración se  aplique a los equipos, lo que estén conectados por VPN ahora serán capaces de enviar las consultas de resolución de las cuentas de almacenamiento a los servidores internos. De esta forma, las consultas de nombres de dominio externos a la zona del dominio del ADDS, serán respondidas por los servidores internos y los clientes podrán conectarse a los recursos compartidos vía Private Link:

Como vemos es sencillo, “simplemente” debemos entender como funcionan los diferentes servicios (DNS, Azure Files, Private Link) y tirar de recursos para aplicar configuraciones que nos ofrecen robustez, sencillez y éxito en el objetivo que nos habíamos planteado incialmente.

Ahora, como siempre, os toca probarlo a vosotros!!