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

En esta segunda parte veremos las configuraciones referentes al host «tservice» y cómo se configurará OpenVPN como cliente en Linux (para el tservice) y en Windows para la estaciones de trabajo de los administradores (en caso de usar Windows). También se analizará la instalación y configuración de Guacamole como Remote Desktop Gateway (RDG) en Linux.

1.    Configuraciones en host “tservice”

En este apartado se configurará el host para que sirva de intermediario entre la red aislada y la red pública. Para el uso de estas herramientas por parte de los usuarios que acceden desde sus terminales móviles y, por tanto, desde el TUN10, será necesario configurar al host “tservice” para que forme parte de esta red. Esto posibilitará que con la debida configuración del servidor, realizada anteriormente, usuarios del TUN10 y el host “tservice”, puedan verse entre ellos y poder así, brindar el servicio a los mismos.

1.1.       Entorno gráfico ligero XFCE

Necesitamos que “tservice” tenga un entorno visual de escritorio, para que una vez se acceda a éste por RDP o por VNC, se pueda ejecutar el navegador y acceder a su vez a la red aislada de gestión. En este caso usaremos el escritorio XFCE, el cual como indica la documentación oficial, su objetivo es “ser visualmente atractivo y fácil de usar”.

Instalamos, opcionalmente, el terminal de gnome:

Si desde la consola local (no desde SSH) ejecutamos el siguiente comando, podremos iniciar el entorno escritorio XFCE:

Al seleccionar la opción predeterminada XFCE se encuentra listo para que trabajemos sobre él.

Una vez reiniciado el sistema se perderán los cambios y XFCE no iniciará. Para habilitarlo con el inicio del sistema, ejecutamos la siguiente línea:

Debe devolver lo siguiente:

Con esto nuestro sistema iniciara con entorno de escritorio XFCE.

Podemos instalar Firefox para usarlo como navegador por defecto:

1.2.       Implementación y configuración de TigerVNC

Existen varios servidores VNC disponibles en Linux. En este caso usaremos «TigerVNC», porque funciona mejor con Guacamole. TigerVNC es una bifurcación de TightVNC, totalmente de código abierto, con desarrollo y debate que se realiza a través de listas de correo de acceso público y repositorios. Esta aplicación se preocupa especialmente del desempeño y la función de mostrar pantalla (escritorio) remotamente:

Instalamos el TigerVNC:

Corremos el siguiente comando para iniciar el servidor VNC:

Cuando «TigerVNC» inicia por primera vez, solicita una contraseña VNC y almacena el dichero de la contraseña en el directorio «~/.vnc». Esta debe tener una longitud no más de 8 caracteres:

Note el «:1» que nos devuelve en la salida después del hostname. Esto significa que el servidor estará corriendo en el puerto TCP 5901 (5900+1). Se pueden tener varias instancias, siempre y cuando se cumpla que :X especifique el puerto para 590X (5900+X).

El servidor «TigerVNC» no se instala con ninguna unidad de servicio de systemd. Para hacer que inicie con el sistema, creamos el servicio:

Agregamos lo siguiente:

Creamos el directorio «/home/root:

Detenemos la actual instancia del servidor VNC:

Iniciamos el servicio con «systemd»:

Habilitamos el servicio con el inicio del sistema:

Verificamos su estado:

El servidor TigerVNC estará escuchando en el puerto 5901:

Debe devolver lo siguiente:

1.2.1.   Múltiples instancias de VNC y múltiples perfiles de Firefox

Pensando en la gestión de múltiples sesiones, será necesario que TigerVNC inicie varias instancias por un puerto diferente, cada una. Esto lo haremos con el objetivo de que, cuando se haga una conexión a cada una de estas instancias, se muestre un escritorio para cada una, sin interrumpir el trabajo de las demás.

Habilitamos que inicien con el sistema varias instancias VNC para el localhost:

Verificamos las instancias iniciadas:

Debe devolver lo siguiente:

Abrimos el navegador y accedemos al gestor de perfiles de Firefox, con el comando, mostrado en la imagen:

Siguiendo este mismo procedimiento, se crea los demás perfiles de Firefox, hasta llegar a los 7 requeridos (total de administradores de red):

  • franco.diaz
  • naylet.carballo
  • maybel
  • danilo.noa
  • mairela.usatorres
  • pavel
  • mayra.perez

De esta manera, cada vez que un usuario se conecte a una instancia VNC del localhost, podrá ejecutar su propio navegador sin interrumpir el trabajo de otro administrador que esté administrando simultáneamente desde el Firefox. Para ello, es necesario que se ejecute desde la consola (genoma-terminal, en este caso), dentro de cada sesión VNC, el comando que permitirá lanzar el gestor de perfiles de Firefox:

O simplemente ejecutar la aplicación desde el entorno gráfico. Cualquiera de las dos vías nos llevara a donde queremos:

Nos abrirá una instancia de Firefox para el perfil “franco.diaz”, en este caso:

Lo anterior significa que, cada usuario podrá trabajar individualmente con su perfil de Firefox, siendo el usuario del sistema “root” quien ejecute siempre el programa.

Es importante resaltar, el desempeño que pueda tener el servidor con tantos perfiles de Firefox ejecutándose simultáneamente y varias instancias VNC. Siempre probar y analizar su consumo, por si es necesario dotar al servidor de mayores recursos hardware.

1.3.       Implementación y configuración de Guacamole

Guacamole es un RDG (Remote Desktop Gateway) sin cliente dedicado. Soporta protocolos estándar como SSH, VNC, RDP. Gracias a HTML5, una vez Guacamole es instalado en un servidor, todo lo que se necesita para acceder a los escritorios es un navegador. Se trata de una solución de software libre que nos permitirá gestionar remotamente nuestros servidores vía web.

1.3.1.  Servidor Guacamole

Instalar paquetes de dependencia:

Descargamos el servidor de Guacamole y lo descompactamos:

Accedemos al directorio y lo preparamos para la compilación:

Compilamos el servidor:

Instalamos el servidor:

Actualizamos la cache del sistema de las bibliotecas instaladas:

Recargamos «systemd», para que pueda encontrar el servicio «guacd» (demonio proxy Guacamole), instalado en el directorio «/etc/init.d»:

Iniciamos el servicio:

Habilitamos auto-inicio con el sistema:

Verificamos su estado:

El servicio debe estar funcionando y escuchando por la IP 127.0.0.1 y puerto 4822:

Debe devolver lo siguiente y confirmar lo dicho anteriormente:

Creamos el directorio y fichero de configuración de Guacamole:

Agregamos las siguientes líneas al fichero, que ya vienen por defecto habilitadas en el servicio, pero que, de esta manera, podremos editar cuando la necesidad lo requiera:

1.3.2.  Cliente web para Guacamole

La aplicación web de Guacamole está escrita en Java, así que necesitaremos instalar lo siguiente:

Habilitamos su inicio con el sistema:

Apache Tomcat escuchara en el puerto 8080:

Debe devolver lo siguiente y confirmar lo dicho anteriormente:

Descargamos la aplicación web de Guacamole:

Movemos el fichero al directorio de la aplicación web:

Reiniciamos tomcat9 y guacd:

1.3.3.  MariaDB para Guacamole

Instalamos MariaDB:

Aseguramos la instalación de MariaDB:

Respondemos según convenga:

  • Enter current password for root (enter for none): ENTER
  • Set root password? [Y/n] y
  • New password: *****
  • Re-enter new password: *****
  • Remove anonymous users? [Y/n] y
  • Disallow root login remotely? [Y/n] y
  • Remove test database and access to it? [Y/n] y
  • Reload privilege tables now? [Y/n] y

Creamos la DB y el usuario:

En color blanco se especifican los comandos necesarios para la creación de la DB, el usuario y sus permisos:

Descargamos la extensión «jdbc-extension», para el uso de la autenticación por DB, en este caso MariaDB. Esto será necesario para poder autenticarnos con el usuario de administración de Guacamole “guacadmin”:

Importamos la DB:

Tras especificar la contraseña root de MariaDB, se importará la DB.

Instalamos la extensión, moviendo al directorio de extensiones:

Instalación del driver JDBC, para que Guacamole se conecte correctamente a la DB:

Creamos el directorio para el driver en guacamole y lo agregamos a dicho directorio:

1.3.4.  Ajustes para autenticación por LDAP

Para que Guacamole pueda autenticar usuarios LDAP, primero hay que configurar la autenticación por MySQL/MariaDB, para acceder con el usuario de administración

Agregamos lo siguiente:

Descargamos el plugin de Guacamole para autenticación por LDAP y la descompactamos:

Movemos el plugin al directorio de extensiones de Guacamole:

Agregamos la configuración de autenticación LDAP al fichero de Guacamole:

Agregamos lo siguiente:

El servidor LDAP estará integrado en un AD (Samba4) y no se usará método de encriptación alguno para la comunicación entre el LDAP y el Guacamole.

NOTA: En el servidor AD necesitamos crear el grupo «Tservice» para los usuarios que vayan a hacer uso del Guacamole:

Creamos el usuario “guacadmin” en el AD:

Agregamos al grupo creado, los usuarios del AD que vayan a hacer uso del Guacamole:

Reiniciamos Tomcat y y el servidor de Guacamole:

Accedemos al cliente web de Guacamole:

http://192.168.120.50:8080/guacamole

Nos autenticamos con el usuario de administración:

  • Usuario: guacadmin
  • Contraseña: guacadmin

Nos recibe la página inicial del servicio:

Nos desplazamos a la esquina superior derecha, damos clic en la ventana desplegable y click sobre “Configuración”:

Accedemos a la pestaña “Usuarios” para gestionar los permisos de los usuarios LDAP:

Vemos cómo Guacamole identifica los usuarios miembros del grupo “Guacamole” del AD para Guacamole. Ahora accedemos en el usuario del AD “usuario1.apellido”:

En este caso estaremos ajustando permisos para un usuario del AD con permisos de administración en Guacamole:

Damos click en “Guardar” para aplicar los cambios.

Ahora ya podremos acceder Guacamole con el usuario del AD “usuario1.apellido” y tener permisos de administración sobre el servicio:

Con esto realizado ya nos encontramos en condiciones de configurar conexiones. A continuación, se muestra un ejemplo de la configuración para una conexión por VNC (para acceder por escritorio remoto) al propio servidor “tservice”:

Vamos a la sección “Inicio” para acceder a las conexiones disponibles para el usuario:

En este caso aparecerán todas las conexiones habilitadas para este usuario:

Al intentar acceder a la conexión con nombre “tservice”, que está configurada para VNC, nos deberá pedir automáticamente la contraseña configurada en TigerVNC para hacer uso de la instancia 1 del servidor VNC (habíamos especificado vncadmin):

Se puede configurar la conexión VNC para que guarde la contraseña de acceso a la instancia del TigerVNC especificada.

Tras una autenticación exitosa, nos debe mostrar el escritorio de XFCE, entorno gráfico configurado para el host “tservice”:

Gucamole nos permite interactuar con algunas herramientas mediante la combinación de teclas “Crtl+Shift+Alt” (para acceder a ellas y para ocultarlas también). Podremos incluso, pegar texto usando la combinación “Crtl+Shift+v”. La barra de herramientas desplegable nos permite también subir y descargar ficheros, si el usuario tiene permitido el servicio SFT para la conexión.

1.3.5.  Asegurando el acceso al cliente web con HTTPS

Apache Tomcat se encuentra escuchando por el puerto 8080. Para tener una forma más sencilla de acceder al Guacamole, instalaremos Nginx y lo configuraremos como un proxy inverso, para que se acceda por el nombre de dominio “guacamole.empresa.midominio.cu” (se necesita una entrada en el DNS) para la IP del host “tservice” de cara a la red pública. Se redireccionará el tráfico de HTTP a HTTPS, cuando se intente acceder con nombre de servidor “guacamole.empresa.midominio.cu”.

Instalamos Nginx:

Configuramos un bloque de configuración para Guacamole:

Respondemos según convenga, lo resaltado en color blanco:

Generamos el parámetro DH. Con 2048 bits debería ser suficientes, pero por requerimientos de la empresa, lo llevaremos a su máximo valor, al tratarse de un acceso que pudiera ser desde internet (aun cuando sea un acceso desde una VPN):

Creamos un nuevo fragmento de configuración de Nginx en el directorio “/etc/nginx/snippets”:

Agregamos lo siguiente:

Crearemos otra pequeña configuración que defina algunas opciones SSL:

Agregamos lo siguiente:

Creamos el bloque de configuración de Nginx para Prometheus:

Agregamos lo siguiente:

Habilitamos la configuración:

Verificamos que la configuración no tenga errores de sintaxis:

Si todo está bien, debe devolvernos lo siguiente, ignorando la advertencia que nos indica:

Esta configuración en particular arroja una advertencia ya que nuestro certificado auto-firmado no puede usar el engrapado SSL. Esto se espera y nuestro servidor aún puede cifrar las conexiones correctamente, por lo que obviamos la advertencia.

Modificaremos el fichero de configuración principal de Nginx, para implementar algunas medidas de seguridad extra:

Deshabilitamos que Nginx envíe su versión en las paginas de error o en las cabeceras del servidor, y también deshabilitamos la compresión por gzip, modificando las siguientes líneas:

Reiniciamos el servicio:

El servidor web Nginx está funcionando ahora como proxy inverso para Guacamole:

https://guacamole.empresa.midominio.cu

NOTA: Se recomienda cerrar el puerto 8080 de cara a la red empresarial.

Para el caso de los usuarios que acceden por el VPN, el proxy inverso no funcionará, ya que desde el TUN10 no se tiene acceso por enrutamiento al DNS, con toda intensión, pues no se desea que lo tengan. La única opción que hay para proteger las credenciales de estos usuarios al acceder al cliente web de Guacamole, es configurar Tomcat para que funcione por el 8443 para HTTPS. Así como Tomcat usa 8080 para alejarse del puerto 80, también da la posibilidad a las conexiones cifradas mediante el 8443, alejándose el 443.

Lo primero será crear el certificado en formato “jks” para Java.

NOTA: Tomcat usa tres diferentes implementaciones de SSL:

  • JSSE: Implementación provista como parte de “Java runtime”.
  • JSSE: Implementación que usa el OpenSSL.
  • APR: implementación, que usa el motor por defecto de OpenSSL.

Generamos el certificado para ser usado por JSSE:

Respondemos las preguntas, acorde a una información que sea lógica para el usuario que revise el certificado:

Editamos el siguiente fichero:

Localizamos en el fichero “JSSE style configuration is used below” y después del primer “–>” que le sigue, agregamos lo siguiente debajo de esa flecha:

Reiniciamos tomcat9:

Tomcat deberá estar escuchando ahora por el 8080 (para HTTP) y el 8443 (para HTTPS):

Debe devolver algo, como lo siguiente:

Con esto configurado, se resuelve el problema de los usuarios dentro del TUN10, los cuales podrán acceder al Guacamole mediante el siguiente enlace:

https://192.168.254.50:8443/guacamole

 

Siendo “192.168.254.50” la dirección IP fija del “tservice”, por dentro del TUN10. Lo mismo sucederá por el TUN11, pero con la IP “192.168.253.50”.

NOTA: Se recomienda cerrar el puerto 8080 para el TUN10 y el TUN11.

 

1.4.       Instancias OpenVPN en modo cliente

Se repetirá el mismo procedimiento realizado en el host “vpn” para la instalación de OpenVPN.

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:

Agregamos los repos de Bullseye:

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

Instalación de OpenVPN (2.5.0-1):

Comentamos los repos de Bullseye y volvemos actualizar el listado:

Creamos el siguiente enlace simbólico:

Directorio que albergará la ca, certificado y llaves para cliente:

Creamos el fichero de configuración de OpenVPN para TUN10:

Agregamos lo siguiente:

Creamos el fichero de configuración de OpenVPN para TUN11:

Agregamos lo siguiente:

En este caso, lo habilitaremos las instancias de openvpn como un servicio, pues para el host “tservice” se trata de clientes y se debe autenticar en cada caso, con su contraseña del AD para el TUN10 y con la del usuario PAM creado en el “vpn” para el TUN11.

Reiniciamos openvpn:

Iniciando conexión VPN contra “ovpn10”:

Ponemos las credenciales y estaremos conectados con el TUN10.

Para iniciar la conexión el con el segundo túnel, necesitamos abrir una nueva consola ssh y hacer lo propio, pero para el “ovpn11”:

Al cerrar la consola se cerrará la conexión en cada túnel, por lo que las conexiones no debemos hacerla desde un cliente SSH, sino de forma local, usando la interfaz grafica de XFCE y abriendo dos consolas para ejecutar las instancias ovpn. Esto habrá que hacerlo cada vez que se reinicie el servidor. A continuación muestro una imagen con lo anteriormente dicho:

1.5.       Agregados opcionales

Si el host “tservice” accede a plataformas de virtualización basadas en tecnología de VMware ESXi, entonces es necesario preparar el host para que pueda visualizar correctamente el “vSphere Web Client”. En caso de que se cuente con versiones antiguas de ESXi, como pudieran ser las que necesitan Flash Player para poder visualizar bien el cliente web y el VMware Remote Console (VMRC) para ejecutar consolas de las maquinas virtuales desde el cliente web.

Usar Flash Player dentro del host “tservice” no supone un riesgo de seguridad, pues lo va a usar el navegador del host “tservice”, el cual será solamente ejecutado por el usuario “root” desde el entorno gráfico XFCE. Será necesario instalar el descontinuado y no recomendado programa, si no se desea actualizar la plataforma de virtualización o no se pueda en dicho momento. Acceder al entorno visual XFCE del host “tservice” solo será posible visualizarse si se conecta localmente al host o si se accede a través del TigerVNC, habiéndose autenticado previamente en el Guacamole.

Descargar el Flash Player del siguiente no oficial de Adobe (no se puede descargar del sitio oficial por estar EOL):

Desempaquetamos el programa:

Movemos la extensión al directorio de plugins de Firefox:

Copiamos lo siguiente:

Reiniciar el navegador y acceder al sitio con Flash Player. Habilitar el plugin cuando lo pida.

https://iuware.iu.edu/api/file/3518

Con lo anterior hecho, ya se puede acceder a versiones antiguas del vSphere Web Client.

Ahora se necesita instalar el VMRC. Para ello, primero descargamos el programa:

  • Sitio oficial de VMware (requiere estar registrado)

https://my.vmware.com/en/web/vmware/downloads/details?downloadGroup=VMRC1200&productId=974

  • Sitio alternativo

https://iuware.iu.edu/api/file/3518

En este caso usaremos el sitio alternativo:

Le damos permisos de ejecución al programa:

Ejecutamos el instalador:

Respondemos según convenga y finalizamos la instalación. Con lo anterior completado, el host “tservice” estará preparado para, desde el navegador, ejecutar el programa VMRC, siempre que lo requiera vSphere Web Client.

2.    Cliente OpenVPN en Windows

En este caso nos situaremos en el caso para los usuarios poseedores de un terminal móvil de la empresa, que accedan por el APN de la misma, ejecuten la VPN desde una PC, que está conectada por anclaje USB al terminal o por un hotspot. Aunque también es posible conectarse desde el propio terminal de la empresa (generalmente Android) usando la aplicación para móviles, seremos prácticos en este casso y es que, gestionar la red desde un móvil es un poco incómodo comparado con una estación de trabajo.

Lo primero será descargar el programa del siguiente enlace:

https://swupdate.openvpn.org/community/releases/OpenVPN-2.5.0-I601-amd64.msi

Ejecutamos el instalador y seguimos los pasos de las imágenes:

Tras la instalación, el programa nos alerta de que no poseemos ninguna configuración inicial:

Creamos el siguiente fichero “C:\Program Files\OpenVPN\config\client.ovpn” con permisos de administración y agregamos el siguiente contenido:

Una vez copiados los certificados y llaves necesarias para la conexión al mismo directorio “config”, iniciamos la conexión. Veremos que nos pedirá autenticación para el usuario. Dicha contraña deberá coincidir con la especificada para el usuario de sistema en el servidor que lo albergue como usuario PAM:

Tras introducir correctamente la contraseña nos pedirá la contraseña para el certificado:

Una vez conectado al servidor, si nos paramos encima del icono del cliente en la barra del menú Inicio, nos mostrará el nombre del servidor al que nos hemos conectado, la fecha de conexión y la dirección IP obtenida:

Verificamos en el adaptador de red que se activa para la conexión VPN con el “ovpn10”:

Ignorar el siguiente mensaje de los logs del cliente:

¿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: 5

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

Sobre Franco Diaz Hurtado 27 artículos
Ing. Telecomunicaciones y Electrónica; 1er Especialista en Redes de ECASA Nivel Central

3 comentarios

  1. Firefox 67.0 Firefox 67.0 Windows 10 x64 Edition Windows 10 x64 Edition
    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

    Hola Franco!! muy bueno y aclarador tu articulo, me ha servido de guia para montar un guacamole. Todo me ha funcionado excepto poder loguearme en la web con las credenciales por defecto guacadmin (guacadmin) recibo el error Usuario invalido, sin embargo si lo logro con cualquier usuario del AD. Alguna sugerencia? pues hay trabajo que hacer mediante la interfaz web y no logro entrar con privilegios administrativos a ella.

  2. Firefox 87.0 Firefox 87.0 Windows 10 x64 Edition Windows 10 x64 Edition
    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

    Hola Sandra, me alegro que el artículo le haya sido bastante aclarador. Debes crear el usuario «guacadmin» en el AD, con las mismas credenciales por defecto. Esto debe poder solucionar su problema.
    Saludos

  3. Firefox 67.0 Firefox 67.0 Windows 10 x64 Edition Windows 10 x64 Edition
    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

    Hola Franco, probé eso y no resolví. Como lo solucione fue eliminando en el MySQL la BD guacamole_db, el usuario y los privilegios creados. Luego repetí este paso y la importación de la BD: cat guacamole-auth-jdbc-1.3.0/mysql/schema/*.sql | mysql -u root -p guacamole_db
    Con esto me funcionó todo ok.

Dejar una contestacion

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