Apache Guacamole avec un reverse proxy basé sur pfSense, HAProxy et Let’s Encrypt
Sommaire
I. Présentation
Dans ce tutoriel, nous allons apprendre à publier un serveur Apache Guacamole via un reverse proxy ! Le serveur Apache Guacamole sera accessible en HTTPS, avec un certificat valide et gratuit obtenu auprès de Let's Encrypt. Pour cette démo, un pare-feu sous pfSense est utilisé et sur ce dernier nous installerons le reverse proxy HAProxy.
Si l'on reprend le schéma présenté au sein du tutoriel d'introduction, le reverse proxy va être mis en place sur l'équipement nommé "Pare-feu" sur le schéma ci-dessous. L'objectif sera d'accéder à Apache Guacamole via l'URL suivante : https://guaca.it-connect.tech/ - Sans avoir besoin d'ajouter "/guacamole/#/" à la fin de l'URL.
En fait, pour publier Apache Guacamole avec un reverse proxy, il y a deux solutions :
- S'appuyer sur un reverse proxy externe, comme c'est le cas ici puisque la fonction est hébergée par une autre machine (firewall)
- S'appuyer sur un reverse proxy local, que l'on installe directement sur le serveur Apache Guacamole (non abordé dans cet article)
Avant de lire cet article, il est recommandé de lire celui-ci :
Par ailleurs, en complément, voici un autre tutoriel où j'ai évoqué en détail la mise en place d'un reverse proxy HAProxy sur pfSense. Pour ce tutoriel, la configuration est similaire sauf que l'application derrière le reverse proxy est différente. C'est pour cette raison que c'est un peu moins détaillé dans cet article.
II. Configuration du pare-feu pfSense
A. Installation des paquets
Sur l'interface du pare-feu pfSense, il convient d'installer deux paquets : le paquet ACME pour la gestion du certificat Let's Encrypt et le paquet HAProxy pour le reverse proxy.
Pour installer ces paquets, accédez au menu suivant : System > Package Manager > Available Packages.
Ici, il conviendra de rechercher et d'installer les paquets cités précédemment. Ce qui donnera :
B. Certificat Let's Encrypt
La gestion du certificat s'effectue via : Services > Acme Certificates. Accédez à ce service via l'interface de pfSense.
- Créer une clé d'authentification
Commencez par nommez cette clé, par exemple "certs.it-connect.tech" (le nom DNS n'a pas besoin d'être résolvable) et choisissez "Let's Encrypt Production ACME v2" au niveau de l'option "ACME Server".
Cliquez sur le bouton "Create new account key" pour générer une clé d'authentification et cela va remplir le champ "Account key" juste au-dessus. Nous devons enregistrer cette clé, donc je vous invite à cliquer sur "Register ACME account key". Normalement, un petit icône validé doit venir s'afficher sur le bouton, comme ceci :
Cliquez sur "Save" et vous obtenez ceci dans "Account keys" :
- Demander le certificat
Cliquez sur l'onglet "Certificates" pour faire une demande de certificat via le bouton "Add". Là encore, un formulaire doit être complété. Indiquez un nom au certificat, ici "guaca.it-connect.tech", sélectionnez votre compte ACME créé précédemment et dans "Domain SAN list", indiquez bien le nom de domaine pour lequel vous souhaitez obtenir le certificat.
La méthode de validation "DNS-Manual" permet de valider que l'on est bien propriétaire du nom de domaine grâce à un enregistrement DNS de type "TXT" qu'il faudra créer.
Validez.
- Créer l'enregistrement DNS TXT
Dans l'onglet "Certificates", il y a une nouvelle entrée qui apparaît. Il s'agit du certificat, mais il n'a pas été généré pour le moment.
Cliquez sur le bouton "Issue". Du texte va s'afficher dans une zone sur fond vert. Ce qui est important, c'est de repérer la section où l'on vous indique l'enregistrement TXT à créer dans la zone DNS de votre domaine. Vous l'aurez compris, il faut créer l'enregistrement DNS avant de continuer (donc rendez-vous sur votre interface OVHcloud, Gandi, Ionos, etc...).
Voici un exemple :
- Demander le certificat Let's Encrypt
Une fois que c'est fait, vous pouvez demander votre certificat Let's Encrypt. Donc, cette fois-ci, cliquez sur le bouton "Renew" qui se situe juste à gauche du bouton "Issue".
Une nouvelle zone sur fond vert s'affiche, avec l'état de l'opération. Logiquement, on vous indique que le certificat a été généré avec succès et qu'il est désormais stocké en local sur le pare-feu.
Pour finir la partie certificat, cliquez sur l'onglet "General Settings" et cochez l'option "Cron Entry" pour activer la tâche planifiée (dans la crontab) afin de le renouveler automatiquement.
Ce certificat va pour voir être présenté au client qui voudront se connecter via guaca.it-connect.tech, afin de sécuriser la connexion, et cela sera fait par HAProxy. En parlant d'HAProxy, passons à la configuration du reverse proxy.
C. Reverse proxy HAProxy
Pour la configuration du reverse proxy, tout se joue dans : Services > HAProxy.
Il faut commencer par cocher l'option "Enable HAProxy" dans l'onglet "Settings" afin d'activer le service HAProxy sur le pare-feu. Cliquez sur "Save" en bas de page.
Ensuite, il y a deux parties à configurer :
- Le Backend, c'est ce qui se passe derrière le reverse proxy, cela correspond donc aux différents serveurs qui hébergent les ressources, ici, notre serveur Apache Guacamole avec le site guaca.it-connect.tech.
- Le Frontend, c'est ce qui se passe en frontal sur le reverse proxy, c'est-à-dire la partie publique. Ceci permet d'indiquer de quelle façon le reverse proxy doit se présenter aux clients, et surtout comment il doit traiter les requêtes. Il faudra lui indiquer comment gérer les requêtes à destination de "https://guaca.it-connect.tech".
Désormais, passons à la configuration.
- Créer un backend
Il faut commencer par créer un backend, ce qui consiste à déclarer le serveur Apache Guacamole : Backend > Add. Sous "Server list", il faut déclarer le serveur, de cette façon :
- Mode : Active (c'est un serveur actif dans le pool)
- Name : le nom de l'hôte pour s'y retrouver, en l'occurrence "srv-guacamole" pour reprendre le nom du serveur
- Forwardto : "Address+Port" puisque l'on va interroger ce serveur Web via son adresse IP et un numéro de port spécifique
- Address : l'adresse IP du serveur Apache Guacamole, pour ma part "192.168.99.12"
- Port : le port sur lequel est en ligne Apache Guacamole, à savoir 8080
Il n'est pas nécessaire d'effectuer d'autres modifications. Par défaut, la section "Health checking" est configurée pour que HAProxy vérifie en HTTP sur le port 8080 si notre serveur Apache Guacamole est bien en ligne.
Continuez à descendre dans la page et cliquez sur "Save".
- Créer un frontend
Basculez sur l'onglet "Frontend" et cliquez sur le bouton "Add".
Après avoir donné un nom, tel que "Acces-Guaca", configurez la section "External address".
- Listen address : choisissez "WAN address (IPv4)", car on va traiter les requêtes qui arrivent sur l'interface WAN du PfSense
- Port : indiquez "443", car on va publier notre site en HTTPS
- SSL Offloading : cochez cette option, car cela correspond à notre architecture, c'est-à-dire du HTTPS entre le reverse proxy et les clients, et du HTTP entre le reverse proxy et Guacamole. Le SSL Offloading correspond à ce processus du transformation du flux.
En complément, sélectionnez l'option "http / https (offloading)" pour la valeur "Type". Cela veut dire que le reverse proxy va travailler au niveau de la couche HTTP/HTTPS.
Passez à la section "Default backend, access control lists and actions".
Pour l'option "Access Control lists", ajoutez une ligne, c'est-à-dire une nouvelle règle (ACL). Comme ceci :
- Name : nom de l'ACL, par exemple "guaca".
- Expressions : on choisit "Host starts with:" (même si "Host matches:" fonctionne aussi), car on cherche à repérer la présence d'une URL qui commence par notre domaine dédié à Guacamole
- Value : on précise le nom du sous-domaine du site, à savoir "guaca.it-connect.tech"
Puis, vous devez indiquer ce que l'on doit faire lorsque cette règle matche en créant une nouvelle action dans "Actions", comme ceci :
- Action : on sélectionne "Use backend" et on choisit notre backend créé précédemment, cela permet d'utiliser notre Backend lorsque la requête va correspondre à l'ACL
- Condition acl names : on spécifie "guaca", car c'est le nom de l'ACL
Descendez dans la page. Cochez l'option "Use forwardfor option" pour ajouter le champ "X-Forwarded-For" à l'en-tête HTTP. Pour rappel, cela permettra au serveur Apache Guacamole de connaître l'adresse IP d'origine du client, et pas seulement l'adresse IP du serveur reverse proxy. C'est très important dans Apache Guacamole pour que les informations soient complètes au niveau du suivi des sessions. Sinon, ce sera toujours l'adresse IP du reverse proxy qui sera renseignée, ce qui est un problème, car on ne pourrait pas bien tracer les accès.
Descendez... jusqu'à la section "SSL Offloading" puisqu'il faut choisir le certificat au niveau de l'option "Certificate". Ici, sélectionnez le certificat Let's Encrypt créé précédemment.
Voilà, c'est terminé pour la configuration du Frontend. Cliquez sur "Save".
D. Port de gestion de pfSense
Pour que notre reverse proxy HAProxy traite les requêtes qui arrivent sur le port 443 de l'interface WAN de PfSense, il faut que l'on crée une règle de pare-feu. Le problème, c'est que par défaut le port 443 est utilisé par défaut pour l'interface d'administration. Afin d'éviter un conflit (et potentiellement d'exposer l'interface d'administration PfSense), on va modifier le port utilisé.
Sous le menu "System", cliquez sur "Advanced". Dans l'onglet "Admin Access", modifiez l'option "TCP port" pour définir un autre port. Par exemple, le port 8443. Validez et accédez de nouveau à votre PfSense en spécifiant le nouveau port à la fin de l'URL : https://<adresse-IP>:8443.
E. Règles de firewalls
Venons-en à la création de la règle de pare-feu pour HAProxy, ce dernier doit être en mesure de recevoir les requêtes sur le port 443. Pour cela, sous le menu "Firewall", cliquez sur "Rules" puis choisissez la zone "WAN".
Créez une nouvelle règle en cliquant sur le bouton "Add" et autorisez les flux HTTPS (443) vers le pare-feu afin qu'ils soient gérés par HAProxy. Dans le cas où HAProxy doit aussi gérer des requêtes HTTP, il conviendra de créer une règle similaire pour le port 80.
Ce qui donne la règle suivant :
Remarque : pour que nos flux HTTPS soient traités par notre reverse proxy, je ne veux pas voir de règles de NAT pour rediriger le port 443 vers le serveur interne. 😉 - Sinon, cela permettrait de bypasser le reverse proxy est d'atteindre directement le serveur Apache Guacamole, ce qui n'est pas le but : nous n'avons pas fait tout ça pour rien !
Le reverse proxy est prêt !
F. Utiliser un port personnalisé pour l'accès HTTPS (facultatif)
Dans cet exemple, l'accès sera effectué en HTTPS sur le port 443 qui est le port par défaut de ce protocole. Il est tout à fait possible de configurer un autre port, par exemple le port 40443. Pour cela, il y a deux modifications à effectuer :
- Dans HAProxy, le port du Frontend doit être modifié pour l'External address afin d'utiliser 40443 (ou autre chose) à la place de 443
- Dans les règles de pare-feu sur l'interface WAN, la règle créée précédemment pour le port 443 doit être modifiée pour spécifier le nouveau port à utiliser
Bien sûr, cette étape est facultative, mais c'est un moyen de masquer un peu plus l'application grâce au fait que l'on n’utilise pas un port par défaut. Mais, je rappelle que le reverse proxy va renvoyer vers notre serveur Apache Guacamole uniquement les requêtes sur l'URL "https://guaca.it-connect.tech" donc il faut connaître le nom de domaine de l'application.
III. Configuration d'Apache Guacamole
La dernière étape consiste à affiner la configuration du serveur Apache Guacamole ! Ensuite, ce sera l'heure de tester !
A. Tomcat9 et l'IP d'origine
Avec la configuration actuelle, et malgré l'activation de l'option pour gérer le champ "x-forwarded-for" dans l'en-tête HTTP, on obtiendrait ceci côté Apache Guacamole :
En fait, l'hôte distant serait toujours égal à l'adresse IP du reverse proxy, que ce soit avec un client du réseau local ou un client distant. Pour que l'adresse IP d'origine du client soit visible dans Apache Guacamole, il faut adapter la configuration de Tomcat.
Depuis la ligne de commande du serveur Apache Guacamole, éditez le fichier de configuration de Tomcat9.
sudo nano /etc/tomcat9/server.xml
L'objectif va être d'ajouté ce bout de code (indiqué dans la documentation officielle) :
<Valve className="org.apache.catalina.valves.RemoteIpValve"
internalProxies="192.168.99.1"
remoteIpHeader="x-forwarded-for"
remoteIpProxiesHeader="x-forwarded-by"
protocolHeader="x-forwarded-proto" />
La seule valeur à modifier, c'est celle du champ "internalProxies" où vous devez indiquer l'adresse IP de votre reverse proxy (correspondante à l'interface qui communique avec Guacamole). Ici, ce sera "192.168.99.1".
Ce bloc s'ajoute à la fin du fichier de configuration, à cet endroit pour être précis :
Sauvegardez et relancez le service Tomcat9.
sudo systemctl restart tomcat9
Suite à cette modification, c'est bien l'adresse IP d'origine du client qui est visible dans Apache Guacamole !
B. Supprimer "guacamole" dans l'URL
Dernier point de configuration : se débarrasser de "/guacamole/" dans l'URL pour que l'on soit en mesure d'accéder à Apache Guacamole via l'URL "https://guaca.it-connect.tech". Bien sûr, cette étape est facultative.
Pour cela, il faut renommer la WebApp d'Apache Guacamole, au niveau du répertoire de Tomcat9.
Commencez par accéder au répertoire des WebApps
cd /var/lib/tomcat9/webapps
Puis, arrêtez le service Tomcat9 :
sudo systemctl stop tomcat9
Actuellement, nous avons :
- Le fichier guacamole.war qui correspond à la WebApp de Guacamole
- Le répertoire guacamole qui contient les données de cette WebApp
- Le répertoire ROOT qui contient la page par défaut de Tomcat9
L'objectif va être de faire en sorte que "guacamole.war" devienne "ROOT.war" pour prendre la place de la page par défaut. Ainsi, on pourra accéder à son interface sans préciser de suffixe dans l'URL.
Commencez par supprimer le répertoire "guacamole" (attention, je dis bien le répertoire).
sudo rm guacamole/ -Rf
Puis, renommez le dossier "ROOT" en "ROOT-ORIGINAL" pour "libérer la place". Et, renommez la WebApp de Guacamole :
sudo mv ROOT/ ROOT-ORIGINAL/ sudo mv guacamole.war ROOT.war
Démarrez le service Tomcat9 :
sudo systemctl start tomcat9
En image, cela donne l'enchaînement de commandes suivant :
Désormais, suite à cette manipulation, Apache Guacamole est accessible en direct sans préciser "/guacamole/" :
IV. Tests : Apache Guacamole derrière un reverse proxy
Même si les copies d'écran précédentes prouvent qu'Apache Guacamole est bien accessible sur sa nouvelle adresse, via le reverse proxy et avec un certificat valide, vous devez bien sûr tester. En appliquant cette configuration, Apache Guacamole est accessible, aussi bien via le réseau local qu'en externe, à partir d'une URL unique.
La connexion entre le reverse proxy et le client est sécurisée via le protocole HTTPS et un certificat.
V. Conclusion
Suite à la lecture de ce tutoriel, vous êtes en mesure de publier un serveur Apache Guacamole derrière un reverse proxy basé sur le trio magique "pfSense + HAProxy + ACME" ! N'hésitez pas à regarder la vidéo ainsi que les liens intégrés en début d'articles pour avoir plus de précisions.
Sur IT-Connect, retrouvez d'autres tutoriels au sujet d'Apache Guacamole :
Merci infiniment pour cette présentation.
Est-il possible de déployer Apache guacamole dans une architecture HA avec synchronisation de session ?
Bonsoir les gars. quelqu’un a t’il une idée sur ce point?
Quand je vois ça je pleure : pfsense + apache + haproxy … tu met un nginx … et c’est marre. 90% des tutos ou je vois du pfsense, ça pourrait se faire avec des trucs bien plus Light.. et apache n’en parlons pas … à part pour ocsunventory ya aucun raison de pas utiliser nginx qui est plus simple et plus performant….
Hello,
Alors pour Nginx, pourquoi pas, mais dans le cas d’une infra où il y a un pfSense comme pare-feu (comme dans cette démo en fait), je ne vois pas ce qu’il y a de mauvais à utiliser HAProxy ?
+1
Bonjour Babar
et du coup? tu nous propose un tuto guacamole + nginx?
merci
Je peux proposer un tuto Apache, LetsEncrypt, Guacamole par contre. j’utilise ça depuis 10 ans environ 😉
bonjour j’ai une erreur, malgre que jai refait tout comme indique sur la video;
$Errors found while starting haproxy
[NOTICE] (43707) : haproxy version is 2.9-dev6-f75a369
[NOTICE] (43707) : path to executable is /usr/local/sbin/haproxy
[ALERT] (43707) : config : parsing [/var/etc/haproxy_test/haproxy.cfg:45] : ‘bind 192.168.1.100:433’ in section ‘frontend’ : ‘crt-list’ : unable to load certificate from file ‘/var/etc/haproxy_test/worksServer.pem’: no start line.
[ALERT] (43707) : config : Error(s) found in configuration file : /var/etc/haproxy_test/haproxy.cfg
[ALERT] (43707) : config : Fatal errors found in configuration.