Conexiones VPN Azure con sistemas Windows

En esta ocasión, nos íbamos a valer de unas pequeñas líneas de script en Powershell para poder generar adecuadamente certificados tanto para el servicio como para los equipos clientes.

Generando certificados

Lo primero de todo era que, teniendo los conocimientos para hacerlo, tuviéramos desplegados varios recursos en Azure, pero principalmente tres:

Una “puerta de enlace de red virtual”; no es sino un dispositivo especial que actuará como puerta de enlace para proveernos de acceso a los recursos de Azure.

Una red virtual con dos subredes, una con una configuración que queramos, y otra para la “puerta de enlace de red virtual”.

Una dirección IP pública asociada a la puerta de enlace de red virtual.

En este caso, íbamos a tener también una máquina virtual Ubuntu en Azure para poder tratar de acceder mediante el programa “putty.exe”.

Luego, iniciaríamos el “entorno de script integrado de Powershell” (“Powershell ISE”) para ejecutar inicialmente este script, el cual serviría para crear un certificado auto-firmado y guardarlo en el almacén de certificados de nuestro equipo:

Las dos marcas que veis en rojo serían los campos que nosotros podríamos cambiar: el primero lo rellenaríamos con un nombre que quisiéramos, sea el de nuestra empresa, organización, etc.; y el segundo es la ruta en la que se almacenará. En ambos casos, habíamos escogido un nombre de prueba y lo almacenaríamos en la cuenta de equipo local, concretamente en la parte de “certificados personales”.

Una vez terminado, ejecutaríamos este otro script, que lo que haría sería crear un certificado de equipo cliente firmado por el anterior certificado:

En esta ocasión, además de marcar el campo “CN” para llamarlo como queramos, veríais que también hay marcada una sección de script. Básicamente, lo que haría sería extraer el “thumbprint” (o “huella digital”) para, con el tercer script, exportarlo a un equipo distinto al que estamos almacenando el certificado de cliente. Os podréis imaginar que tal técnica nos iba a permitir generar certificados para los equipos de nuestra organización.

Ejecutaríamos el tercer script para exportar el certificado cliente en un fichero .PFX cifrado con una contraseña:

En la primera marca escribimos una contraseña, y en la segunda la ruta en la que exportamos el fichero.

Hecho todo lo anterior, íbamos a proceder a exportar tanto el certificado autofirmado al servicio de Azure como el certificado cliente a otro equipo.

Exportando los certificados

Pues bien, a partir de aquí abriríamos una consola de administración (Tecla Windows + R y escribimos “mmc.exe”), añadimos el complemento de certificados de la cuenta de equipo local, y buscaríamos el certificado autofirmado, que debería estar en “Certificados (Equipo local)\Personal\Certificados”:

Como podréis ver, lo que íbamos a hacer era exportar primero el certificado autofirmado, sin la clave privada y escogiendo el formato “Base-64 encoded X.509 (.CER)”, a un archivo. Una vez realizada la exportación, iríamos a ver el contenido del archivo con el comando “type”:

A nosotros nos interesaba solo la parte marcada en blanco, que nos iba a servir para la “puerta de enlace de red virtual” en Azure.

Iniciamos sesión en Azure, fuimos al recurso mencionado antes y seleccionamos la opción “Configuración de punto a sitio” (en inglés, “Point-to-site configuration”):

Si os fijáis, habíamos rellenado el campo “Grupo de direcciones” para implementar una subred para los clientes que fueran conectando; y en el campo “Datos de certificado público” pegamos precisamente el contenido del archivo que habíamos exportado inicialmente, le pusimos un nombre, y guardamos arriba a la izquierda. Al terminar, podríamos descargar el cliente VPN, el cual nos vale para cualquier equipo.

A continuación, buscamos el archivo del certificado cliente:

Y lo haríamos llegar al equipo cliente que quisiéramos. Nos vale cualquier método, pero siempre cuidando que sea seguro. Como este despliegue fue una prueba de concepto, lo enviamos por FTP.

Estando en ese otro equipo, habíamos aprovechado también para descargar el cliente de VPN y el programa “putty.exe”:

Hicimos doble clic en el archivo .PFX para instalar el certificado cliente en el almacén de certificados del equipo y haríamos también doble clic en el archivo del cliente VPN. La instalación del certificado era muy simple, fue solo introducir la contraseña y marcar la opción “Seleccionar automáticamente el almacén de certificados según el tipo de certificado”. En el caso del cliente VPN, crearía una conexión de tipo VPN “host-to-site” en el “Centro de redes y recursos compartidos”.

Podíamos comprobar que ambos procesos se realizaron correctamente invocando una consola de administración para ver los certificados “del usuario”:

Y haciendo clic en el icono del monitor en la barra de tareas abajo a la derecha para ver la conexión VPN creada:

Probando la conexión

Hicimos clic en la conexión VPN y seleccionamos la opción “Conectar”. Se nos abrió una ventana de conexión, hicimos clic en “Conectar” de nuevo, y si todo había salido bien, estaríamos conectados, pudiendo verificar que habíamos recibido una IP del servicio en Azure:

Había que tener en cuenta que, dado que la conexión VPN era segura, no era necesario tener creado un grupo de seguridad para permitir y/o denegar accesos a los recursos según qué puerto:

Por tanto, pudimos ver que, en efecto, estábamos conectados con una máquina, ajena a la infraestructura de Azure, pero como si estuviera en la propia red local de la plataforma.

Observaciones

Es obvio que, aún pudiendo desplegar VPNs con claves pre-compartidas (“Pre-Shared-Keys”) como habíamos visto anteriormente, el uso de certificados iba a permitir un más amplio margen de seguridad y, por qué no decirlo, también un control exhaustivo de quién/es se conecta/n a la red de la organización.

Un administrador de TI podría “emitir diferentes certificados para diferentes usuarios”, haciendo que un usuario determinado sea capaz de acceder solo a los recursos que dicho administrador le permitiera (por la razón que fuera). Así, se podrían aislar recursos de los usuarios, a modo de VLANs en entornos locales.

La única limitación de esta técnica es el hecho de que solo podamos implementar un único espacio de direcciones, por lo que, a la hora de desplegar la “puerta de enlace de red virtual”, el administrador deberá escoger uno acorde a la cantidad de usuarios que, dado el momento, deban acceder a la VPN.