Solución para gestión remota con OpenVPN, TigerVNC y Guacamole – PART 1

Los días de pandemia han llevado a que muchas empresas se enfoquen en la continuidad de sus labores desde los hogares, mediante el tele-trabajo. Ante la necesidad de seguir trabajando, desde un ambiente seguro, siempre que sea necesario, ha llevado al autor de este artículo a realizar un estudio profundo sobre diversas herramientas del Software Libre (SWL) que permitan realizar una gestión segura de la red. Sin embargo, aun cuando la necesidad impere, el mismo ha de cumplir con estrictos requerimientos en seguridad, para hacer que la información de gestión no se vea comprometida. Pudieran abrirse todo un debate alrededor de este artículo, sobre el por qué haber seleccionado una solución u otra, habiendo otras quizá mejores, como sería el caso de WireGuard para la VPN. Quisiera aclarar que este tutorial es una implementación práctica del proyecto de gestión remota de mi empresa y que según su especialista de seguridad informática y del MININT, sólo podía usar las últimas versiones de OpenVPN y OpenSSL. Ante dichos requerimiento, comencé a enarbolar una solución que les vendrá de «perlas» a aquellos administradores que quieran gestionar la red desde cualquier punto de la red, de manera segura.

1.    ¿Qué es lo que se busca con este tutorial?

En este tutorial analizaremos una aplicación práctica en la que se logra gestión remota de la red con encriptación de los datos de extremo a extremo, mediante un túnel VPN o HTTPS, según de dónde provenga la conexión. El siguiente escenario de red nos muestra la distribución de estos servidores y los posibles accesos a estos para la gestión remota:

Este estudio les será de mucha ayuda para el caso de una red gestionada por varios administradores, desde dentro y fuera de la misma, pues permitirá la gestión por individual para cada administrador, sin entorpecer el trabajo de uno con el del otro. Mientras que si se trata de una red administrada por un único administrador, le serviría más la parte de la conectividad VPN para el acceso remoto, pues la gestión de la red aislada a través del host “tservice” puede ser resuelta con una VPN dedicada a esto desde la LAN y WAN1, aunque no se descarta la posibilidad de implementar el RDG Guacamole, permitiendo así una escalabilidad en la gestión de la red aislada.

NOTA: No es obligatorio el uso de dos cortafuegos en la infraestructura de la red, pero al menos uno de ellos es recomendado, para aislar los servidores de la DMZ de los de la GI. En este tutorial se tratan conceptos propios, como el relacionado a la red aislada. Cuando se haga referencia a dicho término, se refiere a la red de virtualización, almacenamiento y gestión de almacenamiento, que no debe estar enrutada por la red pública.

Para el caso del host “vpn”:

  • Host sobre el cual se encuentra el servidor “ovpn10” (para TUN10) y “ovpn11” (para TUN11).
  • Controlará el acceso remoto desde internet, mediante TUN10 y TUN11. El host “tservice” será un cliente más del host “vpn” para TUN10 y TUN11.
  • El TUN10 túnel garantizará la comunicación entre clientes (opción “client-to-client” requerida en el OpenVPN), para que los administradores que accedan desde la WAN2, con una dirección IP dentro del TUN10, puedan acceder al “tservice” por la IP obtenida por este, dentro del mismo túnel. De esta manera se completaría el camino cifrado de extremo a extremo, sin comprometer la información de gestión. Se re quiere una cuenta en el Directorio Activo, además de los certificados y llaves necesarias, para poder autenticarse satisfactoriamente en el “ovpn10”.
  • El TUN11 servirá con el mismo propósito, pero su autenticación será por PAM, usuarios del sistema del propio host “vpn” que serán creados para este servicio. Estos usuarios son aquellos casos a los que se les quiere dar acceso a la red aislada de la empresa y no pertenecen directamente a ella, lo cual implicaría que no tengan una cuenta en el AD y por ello, la necesidad de usar otro método de autenticación y otro túnel VPN (no puede haber dos métodos de autenticación habilitados en uno mismo).

Para el caso del host “tservice”:

  • Permite gestionar los nodos de virtualización y almacenamiento, sirviendo como intermediario.
  • Cuenta con un entorno grafico para acceder vía web a los WebGUI de los nodos de virtualización y almacenamiento.
  • Tiene instalado el servicio Guacamole, que funciona como RDG (Remote Desktop Gateway). El trafico web está encriptado con TLSv1.2 y TLSv1.3, permitiendo los cifrados de tipo AEAD y PFS. El servidor web tiene redirección permanente de HTTP a HTTPS para los usuarios fuera del TUN10 y TUN11 y en los túneles solo se usará TLSv1.3 para el tráfico web.
  • También cuenta con un servidor VNC, para que, desde Guacamole se pueda hacer conexiones de escritorio remoto, usando su cliente VNC integrado.
  • La red de los nodos de virtualización y almacenamiento se encuentran en una red aislada. A dicha red sólo tiene acceso el host “tservice”, y con el uso de las herramientas anteriormente mencionadas, se podrán gestionar remotamente y de forma segura, desde otros puntos de la red pública (LAN, WAN1 y WAN2).
  • Seguridad para los diferentes tipos de accesos al cliente web de Guacamole (tomcat9), desde la red pública:

1.1.       Datos

Versiones del sistema y principales paquetes:

 Sistema Operativo de los hosts “vpn” y “tservice”: Debian 10.8

  • openvpn: 2.5.0, por repos de Bullseye (Debian 11 o testing)
  • easy-rsa: 3.0.6, por repos de Buster (Debian 10)
  • openssl: 1.1.1i, por repos de Bullseye
  • libssl-dev: 1.1.1i, por repos de Bullseye
  • openjdk: 11.0.9.1, por repos de Buster
  • guacamole: 1.3.0, por fuentes
  • tigervnc: 1.9.0, por repos de Buster

NOTA: Tratar de usar las mismas versiones u otras mas actuales de los paquetes indicados anteriormente.

Datos de red pública:

  •  vpn: 192.168.130.103
  • tservice: 192.168.120.50

Datos de red privada TUN10:

  • vpn: 192.168.254.1
  • tservice: 192.168.254.50

Datos de red privada TUN11:

  • vpn: 192.168.253.1
  • tservice: 192.168.253.50

2.    Configuraciones en host “vpn”

En este apartado, se procederá con la configuración del servicio de VPN, basado en la propuesta de OpenVPN. Se usará una configuración estricta en la seguridad, según los requerimientos del órgano de la seguridad en nuestro país (Cuba), por el MININT, al momento de ser redactado este documento.

Por la estructura en la que se configurará el TUN10, si llegase a ser necesario en el futuro, el host “vpn” tendrá una estructura de directorios capaz de albergar varias instancias de openvpn de manera simultánea, siempre y cuando los recursos hardware del servidor lo permitan. Basta solamente con repetir el procedimiento para un nuevo “ovpnXY” y TUNXY.

2.1.       Instalación de OpenVPN

Habilitamos el reenvío de paquetes de manera permanente:

Creamos los directorios raíz de cada uno de los servidores ovpn:

Directorio para configurar la reservación de IP por el tunel ovpnXY:

Directorio para albergar las herramientas para la PKI:

Directorio que albergará la ca, certificado y llaves del servidor:

Instalamos OpenSSL y libssl1.1 (1.1.1d), easy-rsa (3.0.6-1) y openvpn (2.4.7-1) por los repos oficiales de Buster:

Los repos de Buster no vienen con OpenSSL 1.1.1i ni sus librerías. Para ello apuntaremos momentáneamente a los repos de Bullseye e instalaremos dichos paquetes:

Instalación de OpenSSL (1.1.1i) y sus librerías actualizadas

Verificamos la versión instalada:

Debe devolver algo, como lo siguiente:

Instalación de OpenVPN (2.5.0-1) y su módulo de autenticación LDAP:

Verificamos la versión instalada de openvpn:

Debe devolver algo, como lo siguiente:

Comentamos los repos de Bullseye y volvemos actualizar el listado:

Creamos el siguiente enlace simbólico:

2.2.       Configuración de la PKI

Copiar el directorio “/usr/share/easy-rsa/” y pegarlo en “/etc/openvpn/server/ovpnXY/easy-rsa”:

Acceder al directorio “/etc/openvpn/server/ovpn10/easy-rsa/”:

Usamos el fichero “vars.example”:

Editamos el fichero “vars”:

Modificamos las siguientes líneas, según el entorno de la red:

Inicializando la PKI:

Debe devolver lo siguiente:

Copiamos el fichero “openssl-easyrsa.cnf” al nuevo directorio creado para la PKI:

Construimos la ca sin contraseña:

Debe devolver lo siguiente:

Generamos el parámetro DH:

Debe devolver al final lo siguiente:

Generamos la llave del servidor “ovpn10” sin contraseña:

Debe devolver lo siguiente:

Copiar los archivos del servidor:

Hasta aquí se encuentra configurada la PKI para “ovpn10”.

NOTA: Para el “ovpn11” se debe hacer lo mismo, respetando sus directorios y nombre de CA:

2.3.       Instancia OpenVPN en modo servidor con autenticación LDAP

Editando el fichero de configuración del servidor “onvpn10”:

Adaptando a su entorno:

Generamos la llave especificada en los ficheros de configuración anterior, para autenticación HMAC:

Se quiere configurar autenticación LDAP para el TUN10, ya que los usuarios que vayan a hacer uso de este túnel, son usuarios del AD. Para ello, debemos seguir los pasos que se explican en esta sección.

NOTA: Se requiere haber instalado el módulo de autenticación de LDAP para OpenVPN “openvpn-auth-ldap”

Copiamos el siguiente ejemplo de configuración de la documentación:

Editamos el fichero:

Lo modificamos, según los datos de su red. En este caso se trata de un AD basado en Samba4, por tanto, usaremos los esquemas para la autenticación contra su LDAP. En este caso no usaremos una conexión cifrada con el LDAP:

Instalamos las herramientas necesarias para encuestar el LDAP y hacer unas pruebas de conexión con el servicio:

Verificamos que podamos obtener información del LDAP del AD:

Si se ponen los datos correctamente, podremos ver la información solicitada.

Habilitamos los servicios para que inicie con el sistema la instancia openvpn:

Debe devolver lo siguiente:

Iniciamos los servicios de cada instancia openvpn:

Hasta este punto, la instancia “ovpn10” se encuentra lista para ser inicializada y esperando por conexiones provenientes de los clientes.

Con el comando “ifconfig” podemos verificar la interfaz virtual iniciada para TUN10.

2.4.       Instancia OpenVPN en modo servidor con autenticación PAM

Editando el fichero de configuración del servidor “onvpn11”:

Adaptando a su entorno:

Generamos la llave especificada en los ficheros de configuración anterior, para autenticación HMAC:

Como usaremos autenticación PAM, creamos el usuario con el siguiente comando:

Creamos la contraseña para el usuario creado:

Debe devolver lo siguiente:

Habilitamos los servicios para que inicie con el sistema la instancia openvpn:

Debe devolver lo siguiente:

Iniciamos los servicios de la instancia openvpn:

Hasta este punto, la instancia “ovpn11” se encuentra lista para ser inicializada y esperando por conexiones provenientes de los clientes.

Con el comando “ifconfig” podemos verificar la interfaz virtual iniciada para TUN11.

2.5.       Emisión de certificados auto-firmados

Este apartado se explica cómo generar certificados auto-firmados. En esta ocasión se utiliza como ejemplo la emisión de los certificados el usuario “tservice”, el cual será el usuario que use el host “tservice” para establecer una conexión con las instancias openvpn del TUN10 y TUN11. Este host requiere establecer conexiones por ambos túneles, para que pueda dar acceso a los usuarios, tanto del AD como los de PAM que están dentro de las instancias de VPN.

Creamos los ficheros para el host “tservice”, donde reservaremos su dirección IP en los túneles.

Accedemos al directorio donde se encuentra la PKI de ovpn10:

Generamos el certificado para el cliente “tservice” con contraseña. De esta manera el cliente del servidor deberá tener una cuenta, en este caso en el AD (autenticación LDAP en para el TUN10), la CA, los certificados y llaves del cliente, y la contraseña del certificado:

Debe devolver lo siguiente:

Accedemos al directorio donde se encuentra la PKI de ovpn11:

Generamos el certificado para el cliente “tservice”, esta vez para el TUN11.

Debe devolver lo siguiente:

Copiamos los certificados del usuario “tservice”, para el TUN10, al directorio especificado por el servidor:

Copiamos los certificados del usuario “tservice”, para el TUN11, al directorio especificado por el servidor:

Obtener los archivos para el cliente (“ca.crt”, “tservice.key”, “tservice.crt”, “ta.key”). Los archivos a copiar se encuentran en los siguientes directorios:

  • Para TUN10:
    • /etc/openvpn/server/ovpn10/auth/ca.crt
    • /etc/openvpn/server/ovpn10/auth/ta.key
    • /etc/openvpn/server/ovpn10/auth/tservice.key
    • /etc/openvpn/server/ovpn10/auth/tservice.crt
  • Para TUN11:
    • /etc/openvpn/server/ovpn11/auth/ca.crt
    • /etc/openvpn/server/ovpn11/auth/ta.key
    • /etc/openvpn/server/ovpn11/auth/tservice.key
    • /etc/openvpn/server/ovpn11/auth/tservice.crt

Lo importante es copiar dichos ficheros y hacérselos llegar al cliente, mediante un canal seguro. Para el caso del usuario “tservice” usamos el comando “scp” para hacerle llegar de manera segura los ficheros.

Copiando los certificados del usuario “tservice” para TUN10:

Copiando los certificados del usuario “tservice” para TUN11:

¿De cuánta utilidad te ha parecido este contenido?

¡Haz clic en una estrella para puntuar!

Promedio de puntuación 5 / 5. Recuento de votos: 6

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Ing. Telecomunicaciones y Electrónica; 1er Especialista en Redes de ECASA Nivel Central

Sé el primero en comentar

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*