Gérer son VPN WireGuard facilement avec Firezone
Sommaire
I. Présentation
Dans le monde des VPN nomades Open Source, OpenVPN s'est tapé la part du lion pendant de nombreuses années. Mais c'était sans compter sur Jason Donenfeld qui développa le protocole WireGuard. Celui-ci propose de plus grandes performances, un code moins lourd et une facilité d'administration, quoi de mieux?
Ce protocole est donc en pleine expansion, Free l'a d'ailleurs implémenté directement dans ses box de dernière génération.
Cela dit, la configuration en ligne de commande peut en rebuter certains, donc pour faciliter encore plus la création et le maintien des tunnels, des aficionados ont eu la très bonne idée de packager WireGuard avec une WebUI pour en faire un soft "user friendly" et utilisable de suite.
De plus, ils y ont ajouté la possibilité d'utiliser un fournisseur SSO compatible OpenID (Google, Azure AD, par exemple) et une gestion facilitée de nftables (attention, pour trafic sortant uniquement!)
Dans ce tutoriel, nous allons donc voir comment installer Firezone et créer nos tunnels VPN.
II. Installation de Firezone
Firezone est disponible sur Github ou sur leur site officiel. Il est compatible avec beaucoup de distributions Linux vous trouverez donc forcément celle qui vous convient. L'installation se fait simplement en une ligne, les développeurs proposant un script d'installation prêt à l'emploi.
Pour ma part, je vais faire cette installation sur Ubuntu server 22.04, mais vous pouvez prendre n'importe quelle distribution de la liste ci-dessus.
Tout d'abord, les prérequis :
- Les développeurs conseillent de démarrer avec 1 vCPU et 1 Go de RAM, et d'augmenter ces ressources en fonction du nombre d'utilisateurs.
- Si vous déployez Firezone en production, il vous faudra un enregistrement DNS ainsi qu'un certificat, il est possible bien sûr d'en installer un de chez Let's Encrypt.
- Enfin, il vous faudra ouvrir les ports 443 pour la WebUI et 51820 en UDP pour les tunnels.
Bien, passons maintenant à l'installation. Premièrement, on se connecte en SSH et on en profite pour mettre à jour les paquets :
sudo apt update && sudo apt upgrade -y
Maintenant que cela est fait, passons à l'installation à proprement parlé :
sudo -E bash -c "$(curl -fsSL https://github.com/firezone/firezone/raw/master/scripts/install.sh)"
Vous risquez d'voir une question :
WireGuard kernel module found, but not loaded. Load it now? (Y/n):
Bien entendu, il faut répondre oui ici.
Viennent ensuite les questions de personnalisation :
- Mail administrateur : rentrez le mail que vous souhaitez utiliser pour vous connecter à l'instance
- Choisissez si vous souhaitez recevoir des mails de la part de l'équipe de Firezone
Il vous suffira de taper la touche "Entrée "pour lancer l'installation.
Note : vérifiez si vous avez un dossier nommé "cron.hourly" dans votre répertoire "/etc". Si ce n'est pas le cas, créez-le, car l'installateur ne le fera pas et affichera une erreur.
À la fin de l'installation, il vous affichera l'adresse publique de la machine, votre identifiant et votre mot de passe. Bien entendu, vous pouvez tout à fait vous connecter en local, c'est ce que j'ai fait sans problème.
III. Configuration de Firezone
Connectez-vous donc avec vos identifiants (pensez à les noter!!), vous arriverez sur le dashboard de la solution :
Comme vous pouvez le constater, il s'est occupé de nous créer un profil VPN. Celui-ci est immédiatement utilisable, mais pour l'exemple, nous allons en créer un autre.
Pour cela, rien de plus simple : il suffit de cliquer sur le bouton "Add User".
Remplissez les informations, attention le mot de passe doit faire au minimum 12 caractères !
Une fois l'utilisateur créé, vous allez obtenir une page récapitulative. D'ici vous pourrez : réinitialiser le mot de passe de l'utilisateur, le désactiver, le promouvoir en admin ou encore le supprimer définitivement. Cela rend la gestion des utilisateurs beaucoup plus simple et intuitive !
Par contre, vous avez peut-être remarqué un bouton :
Ce dispositif permet de monitorer en temps réel qui est connecté et avec quoi. Sur la page de création du périphérique, nous allons pouvoir lui donner un nom, une description, mais également lui spécifier des adresses autorisées, des DNS, etc. À noter que l'assistant de création prend les réglages par défaut de Firezone, nous pouvons donc ici les modifier de manière spécifique pour un client particulier.
Pour l'instant, laissons tout par défaut et validons.
Note : les développeurs de Firezone préconisent de laisser le client générer sa propre configuration, ceci pour que sa clé privée ne soit affichée que pour lui. L'utilisateur peut donc tout à fait enregistrer son périphérique en se connectant à l'interface.
Une fois la validation effectuée, nous avons la clé privée qui s'affiche, ainsi qu'un QR code et la possibilité de télécharger le fichier de configuration :
Je l'affiche ici, car je ne réutiliserai pas cette configuration, mais il va de soi que c'est personnel ! Pensez bien à tout récupérer, car il sera impossible d’afficher à nouveau cette page!
Donc là plusieurs solution, si le client l'a généré lui-même, il peut tout à fait scanner le QR code avec son smartphone par exemple, c'est ce que j'ai fait :
Maintenant, si ce n'est pas déjà fait, il faut ouvrir les ports dans votre Firewall et rediriger le trafic vers votre serveur Firezone. Je ne détaillerais pas la manipulation, car elle diffère selon les fournisseurs, je vous laisse donc vous rapprocher du manuel. Pour ma part, je ne compte pas manager les comptes à distance, je n'ouvre donc que le port consacré au trafic de Wireguard à savoir le 51820 en UDP.
Une fois les ports ouverts, nous pouvons tester. Si le tunnel monte, nous verrons apparaître la ligne correspondante dans la section "Devices" sur le serveur :
Ici, je vois donc qui est connecté, d'où et le débit utilisé.
Pour la connexion depuis un poste, l'utilisation du QR code n'étant pas possible, il faut télécharger le client Wireguard disponible ici.
Une fois téléchargé, importez le fichier de configuration précédemment généré puis cliquer sur "Activer" pour lancer le tunnel.
IV. Filtrage des flux
Lors de la création de notre utilisateur, nous avons laissé toutes les options par défaut.
Mais il est possible d'en affiner certaines, dont les adresses autorisées pour les clients. En effet, de base, un tunnel VPN crée une connexion de un vers tous, c'est-à-dire que tous les périphériques du réseau cible seront accessibles. Dans un environnement de production, ce n'est pas souhaitable, car cela peut représenter un risque de sécurité.
Imaginons donc que je ne souhaite rendre disponible que l'interface Web de Firezone et un serveur en RDP.
Sur l'interface de Firezone, cliquez sur "Rules". Leur application est très simple : Allow ou Deny. On peut spécifier une adresse, une plage d'adresse, le ou les utilisateurs concernés ainsi que le protocole de couche 4 et le port, de qui faire quelque chose de très fin!
Donc, commençons par la règle pour l’accès à la WebUI de Firezone :
Bien, maintenant passons à celle concernant le RDP sur le serveur :
Parfait, maintenant, si on teste, on est OK, on a bien accès aux services, mais qu'en est-il des autres services ? Exemple avec mon NAS :
Oups... Et oui, nous avons spécifié des adresses autorisées, mais aucune interdite! Comme je veux qu'aucune autre adresse ne soit atteignable via le tunnel, je renseigne la plage en entier en "Deny" :
Bien sûr je spécifie tous les protocoles, comme ça, rien ne sera accessible à part ce que j'ai autorisé.
Si je vérifie maintenant, je n'ai plus accès à mon NAS :
Note : si votre Firezone est sur un hyperviseur, celui-ci restera atteignable, même si vous le spécifiez dans les adresses interdites. Cela est sûrement dû au fait du "partage" de la carte réseau, je n'ai pas encore creusé, mais sachez-le...
V. Split Tunneling
La manipulation précédente est dans le cas où vous souhaitez que tout le trafic des clients passe dans le tunnel, ce qui peut être une bonne chose si vous bénéficiez d'un UTM avec des fonctionnalités de sécurité avancées (Proxy DNS, filtrage web, etc). Par contre, vous souhaitez peut-être que vos clients n’accèdent qu'aux ressources spécifiées via VPN, mais utilisent leur propre connexion pour le reste (Internet par exemple) c'est ce qu'on appelle le split tunneling.
Pour le mettre en place, il faut modifier les adresses autorisées dans les paramètres du site, section "Defaults".
Note : toute modification dans cette section entraînera la nécessité de régénérer les configurations!
Nous allons donc spécifier les adresses accessibles via le tunnel, donc pour moi 192.168.1.34 et 192.168.1.55 :
Si jamais vos utilisateurs utilisent un nom de ressources, n'oubliez pas non plus de spécifier vos DNS internes, sans quoi ils ne pourront pas faire la résolution!
Maintenant que c'est fait, j'ai bien toujours accès à mes ressources, mais en revanche, si je vais sur whatsmyip.org, je constate que mon adresse publique est bien celle de l'endroit où je me trouve, et plus celle du serveur VPN ! Il s'agit donc bien d'un tunnel VPN en mode "split tunneling".
VI. Conclusion
Nous avons vu comment, de manière simple et "user friendly" configurer des tunnels VPN à destination de télétravailleurs ou travailleurs nomades, en utilisant la solution Wireguard au travers de Firezone.
Firezone est prometteur, car il démocratise l'utilisation de Wireguard, augmentant ainsi la sécurité des connexions.
En complément, vous trouverez la doc ici, elle est relativement complète (même si certaines parties mériteraient un peu plus d'explications...).
Pour aller plus loin, si vous ouvrez votre interface Web sur Internet, n'hésitez pas à sécuriser votre serveur avec Crowdsec : les tutos sont disponibles sur IT-Connect !
Bonjour,
Merci pour cet article super interessant.
Etant un utilisateur de Firezone, je vous donne quelques tips de sécurisation si vous souhaitez le publier sur Internet.
Comme l’explique Florian, il vaut mieux créer un autre utilisateur et désactiver l’admin de base
Par contre, il faut activer l’authentification multi-facteur (OTP) sur l’utilisateur qui se connectera a l’instance Firezone.
Il est possible également de changer le port de communication de la WEB UI de Firezone par défaut en 443 sur un autre port pour des questions de sécurités.
Tout ce passe dans le dossier: /var/opt/firezone > Dossier Nginx et conf-enabled. Ce fichier recense la config de communication de Firezone, et le port à modifier se trouve la.
Relancez ensuite le service Nginx et le tour est joué.
Vous pouvez même y adjoindre en frontal un Crowdsec avec un bouncer Firewall pour les petits malins qui font des scans de port et des attaques DOS, ils seront blacklistés de suite. (Articles très interessants sur ce site)
Encore merci pour ce tuto
Bonjour,
Evidemment pour moi .. cela ne fonctionne pas. 🙂
Le VPn est bien monté (utilisé le script install.sh (sachant que j’avais déjà installé wireguard)), donc pas de souci côté wireguard, mais côté firezone … il vaut mieux mettre quelle adresse IP ? La publique, la locale ? et surtout, comment est géré le https ? (certificat letsencrypt généré en parallèle par mes soins) mais pas pris en compte.
Au secours! 🙂
Merci pour une idée
Bonjour Erwann,
Firezone se base sur Nginx pour la partie Web, donc le certificat est à déclarer dans le fichier de configuration du site (/etc/nginx/site-avialable), n’oubliez pas de redémarrer Nginx après!
Sinon, pour la question sur l’IP, je ne comprends pas bien. Vous parlez de l’IP à renseigner pour accéder à Firezone où celle à renseigner pour les clients VPN?
Si c’est la première, alors peut importe, vous pouvez bien sur y accéder en local si vous êtes dans le même réseau ou à distance, à condition bien sur d’avoir ouvert les ports correspondant dans le pare-feu du site.
Si c’est al deuxième, ce sera toujours l’IP publique, sinon les clients ne pourrons jamais se connecter.
Bonjour Florian
Merci pour le retour.
J’ai tenté l’installation via docker et via le deb. Pour ce dernier, il n’arrive pas créer sa base sur un postrgres vierge et ouvert sur la planète. Donc lui, je l’efface.
En revanche, pour la version docker, je pensais que le nginx était embarqué, il faut donc en installer un en parallèle (ce que je trouve personnellement pas top côté sécu).
Pour l’IP, je parlais de celle du « gestionnaire », le wireguard a forcément une patte sur le net mais la gui, j’hésite. J’avoue que ca me soucie de laisser une GUI ouverte sur le net. Même si plusieurs vérifications sont faites, c’est quand même derrière un accès à un réseau .
Merci en tout cas, je regarde ca de plus près.
Erwann
Un truc qui m’échappe c’est qu’il est écrit « de base, un tunnel VPN crée une connexion de un vers tous, c’est-à-dire que tous les périphériques du réseau cible seront accessibles. »
et juste après vous expliquez comment autoriser certains flux. C’est contradictoire.
Pourquoi autoriser des flux si tout est ouvert par défaut ?!
Bonjour,
Pas de contradiction ici. Comme expliqué de base un VPN va autoriser la connexion vers tous les périphériques du LAN distant.
D’un point de vue sécurité c’est pas génial car en cas d’infection ou d’attaque, toutes les machines seront exposées.
C’est pour cela que j’explique comment autoriser des flux vers les ressources nécessaires (et donc pas conséquent interdire ceux non nécessaire).
N’hésitez pas si vous avez d’autres questions !
Bonjour Florian,
Tt d’abord Remerciements pour l’excellent travail que vous faites sur ce site IT-Connect car les articles sont en général de Qualité 😉
Pour ma part voici ma config avant mes – petites – questions.
Internet (Free ULTRA) BackBone en 192.168.x.y Router (OpenWRT/Lede) Réseau Perso en 10.a.b.c par exemple
Mon Pi3 est déjà fonctionnel sur le BackBone et accessible depuis le Net et configuré de manière à permettre à mon Android d’atteindre depuis l’extérieur (en 5G) mon HA caché derrière le Router…
Jusque là rien de très compliqué.
1) Est-il possible d’ajouter la surcouche FireZone sur cette installation déjà existante ?
2) Dans mon cas quel serait le véritable intérêt -si ce n’est d’éviter la gestion nftables à la mano- d’installer le talentueux FireZone ?
Voilà.
Tous mes Remerciements en attendant votre retour.
Bonjour Jee’L,
Merci pour les compliments!
Pour votre question, je ne vois pas bien l’intérêt, et Firezone ne permet pas de manipuler nftables mais offre un serveur VPN Wireguard, ce que fait déjà la Freebox par ailleurs.
Je ne sais pas ce qu’il y a sur le Rpi mais s’il est déjà accessible depuis l’extérieur et permet d’accéder à votre réseau interne…
A moins que ce RPi propose justement un serveur VPN « fait main », auquel cas je comprends la gestion de nftables pour les accès. Alors là oui, installer Firezone dessus pourra faciliter la mise en œuvre.
Bien sur si ces messieurs de chez Free se décident un jour à permettre l’ajout de routes statiques sur la Freebox, tout ceci ne sera plus necéssaire…