Avertissement : Cet article a été traduit de l’anglais par un LLM. La précision n’est pas garantie. Vous pouvez lire l’article original en anglais.
L’auto-hébergement est formidable, mais il y a un problème : plus vous installez de nouveaux services, plus vous créez de surface d’attaque sur votre serveur, et plus vous devez être vigilant concernant les mises à jour et autres si vous ne voulez pas risquer d’être piraté.
Dans cet article, nous allons discuter d’un moyen d’apporter plus de sécurité à vos services auto-hébergés et d’être moins stressé par les mises à jour urgentes en ne les exposant pas à Internet tout en permettant un accès facile. Pour y parvenir, nous configurerons un serveur WireGuard, verrons comment s’y connecter, empêcherons les utilisateurs non connectés d’accéder à vos services, et nous assurerons que toutes les machines de votre réseau local peuvent accéder aux services hébergés sur votre serveur en utilisant pfSense.
Notez que je supposerai que votre serveur VPN et les services que vous voulez protéger sont sur le même serveur. Si ce n’est pas le cas, vous devriez ajuster un peu la configuration du pare-feu.
Installer le serveur WireGuard#
La première étape est d’installer le serveur WireGuard et de générer une paire de clés publique/privée.
sudo apt-get install wireguard
cd /etc/wireguard
umask 077
wg genkey > wg0.key
wg pubkey < wg0.key > wg0.pubNous pouvons ensuite créer un fichier /etc/wireguard/wg0.conf avec la configuration suivante. Nous utilisons le champ Address pour définir que les IP des clients connectés au VPN seront entre 10.90.0.2 et 10.90.0.254, mais vous pouvez utiliser ce que vous voulez (faites juste attention à ne pas utiliser une plage déjà utilisée).
[Interface]
PostUp = wg set %i private-key /etc/wireguard/%i.key
Address = 10.90.0.1/24
ListenPort = 51822Une fois cela fait, nous ajoutons un service systemd, démarrons le serveur et vérifions qu’il fonctionne correctement :
sudo systemctl enable wg-quick@wg0.service
sudo systemctl start wg-quick@wg0.service
sudo systemctl status wg-quick@wg0.serviceDans notre cas, nous ne voulons pas utiliser le VPN pour accéder à Internet, nous devons donc simplement ouvrir le port WireGuard pour que les clients puissent se connecter au serveur
sudo iptables -t filter -A INPUT -p udp --dport 51822 -j ACCEPTSi vous voulez pouvoir utiliser le VPN pour vous connecter à Internet, les commandes suivantes devraient fonctionner (eth0 doit être remplacé par le nom de l’interface que vous utilisez pour vous connecter à Internet)
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADEConfigurer un client#
Configuration côté client#
Maintenant, nous voulons tester si nous pouvons correctement nous connecter à notre serveur. Avec le client WireGuard, cliquer sur Add Empty Tunnel... devrait vous donner l’écran suivant (le client générera automatiquement une paire de clés pour vous).

Nous allons modifier la configuration pour qu’elle ressemble à ce qui suit (remplacez A.B.C.D par l’IP de votre serveur)
[Interface]
PrivateKey = KCMvn8yRUHBhI5RbIr/iZJn4X3BvjwsNdLmEDKFIaGg=
Address = 10.90.0.2/32
[Peer]
PublicKey = [Collez le contenu du fichier /etc/wireguard/wg0.pub du serveur]
AllowedIPs = 10.90.0.0/24
Endpoint = A.B.C.D:51822
PersistentKeepalive = 25Address sera l’IP de votre client dans le réseau VPN. L’option AllowedIPs nous permet de dire quelles adresses IP doivent être atteintes via le VPN. Ici, nous voulons juste accéder au réseau VPN, mais si nous voulions tout router via le VPN, nous devrions écrire 0.0.0.0/0.
Sauvegardez la configuration, mais la connexion ne fonctionnera pas encore, car nous devons autoriser notre client dans la configuration du serveur.
Configuration côté serveur#
La configuration côté serveur est assez légère. Nous devons simplement éditer notre fichier /etc/wireguard/wg0.conf et ajouter les lignes suivantes :
[Peer]
PublicKey = eF3ZRuLDG9Ih5yxTFLyGyosx4qlAvad388ITieSwL34=
AllowedIPs = 10.90.0.2/32AllowedIPs est l’adresse que nous voulons attribuer au client (ici 10.90.0.2) et la clé publique est celle que le client WireGuard a générée pour nous.
Une fois la configuration sauvegardée, nous devons redémarrer le serveur, et nous devrions ensuite pouvoir nous y connecter.
# Côté serveur
sudo systemctl restart wg-quick@wg0.service
# Côté client pour tester la connexion
ping 10.90.0.1
curl http://10.90.0.1 # Si vous avez un serveur web en cours d'exécutionSi vous ne voulez pas redémarrer le serveur WireGuard, vous avez la possibilité d’utiliser la commande wg. Notez que cela ne sauvegardera rien, vous devez donc toujours éditer le fichier de configuration. Sinon, la configuration sera perdue au prochain redémarrage du serveur.
# Pour ajouter un client
wg set wg0 peer "eF3ZRuLDG9Ih5yxTFLyGyosx4qlAvad388ITieSwL34=" allowed-ips 10.90.0.2/32
# Pour supprimer un client
wg set wg0 peer "eF3ZRuLDG9Ih5yxTFLyGyosx4qlAvad388ITieSwL34=" removeTirer parti de WireGuard#
Maintenant que nous avons un serveur fonctionnel, nous pouvons faire en sorte que les services ne soient pas accessibles depuis le monde extérieur.
La manière la plus sécurisée de gérer les choses serait de n’ouvrir les ports INPUT que pour SSH et WireGuard, car cela laisse très peu de surface d’attaque. Nous pouvons ensuite accéder à nos services à l’IP 10.90.0.1.
Mais disons que nous voulons partager quelque chose avec un tiers sans lui demander d’avoir un accès VPN. Pour ce genre de scénario, j’expose mon instance Apache à Internet, mais j’utilise la configuration Apache suivante dans mon Virtual Host. Elle exige soit d’être connecté via le VPN, soit de se connecter avec un utilisateur du groupe mygroup.
<Location />
Require all denied
AuthType Basic
AuthName "Password Required"
AuthUserFile "/path/to/htpasswd"
AuthGroupFile "/path/to/htgroup"
<RequireAny>
Require ip 10.90.0.0/24
Require group mygroup
</RequireAny>
</Location>Cela a l’avantage de ne pas m’embêter avec le BasicAuth quand j’utilise le serveur, tout en réduisant le risque que des acteurs malveillants exploitent quelque chose puisque c’est derrière un mot de passe.
Configuration de pfSense#
Tout cela est très bien, mais configurer WireGuard sur tous nos appareils est ennuyeux. Et si nous pouvions faire en sorte que tous les appareils de notre réseau domestique puissent accéder aux services que vous hébergez sur votre serveur ?
Si vous avez pfSense, vous pouvez effectivement le faire en créant un tunnel WireGuard et en faisant un peu de configuration de routage. (Vous pourriez aussi être intéressé par cet article sur la configuration de pfSense.)
Configurer un tunnel WireGuard#
D’abord, nous allons dans System/Package Manager/Available Packages et installons WireGuard.
Ensuite, nous configurerons la connexion dans VPN/WireGuard/Tunnels. Cliquez sur Add Tunnel, mettez l’adresse de l’interface comme 10.90.0.3/32 et générez une paire de clés. Sauvegardez l’interface, et connectez-vous à votre serveur pour ajouter un client avec cette clé publique et cette adresse IP (voir la partie précédente Configurer un client/Configuration côté serveur).

Après avoir créé l’interface, nous devrions voir cet écran dans la liste des tunnels.

Nous cliquerons ensuite sur l’icône Add Peer dans la colonne Actions et configurerons le Peer comme suit.

Sauvegardez et appliquez les modifications. N’oubliez pas non plus d’aller dans le menu Settings et d’activer WireGuard. Quand tout cela est fait, nous devrions pouvoir confirmer que le tunnel fonctionne dans le menu Status / Wireguard.
Router le trafic pertinent à travers WireGuard#
Maintenant que nous avons un tunnel fonctionnel, nous voulons rediriger tout le trafic vers 10.90.0.0/24.
Nous créerons une interface nommée WG1 dans Interfaces / Interface Assignments et la configurerons comme suit :


Notez que nous devons créer la passerelle en cliquant sur Add a new gateway et en lui donnant l’IP 10.90.0.3. Quand la modification de l’interface est sauvegardée, nous pouvons aller dans System / Routing / Gateways et confirmer qu’elle a été correctement créée.

Nous créerons ensuite une règle NAT sortante dans Firewall / NAT / Outbound. Nous devons nous assurer que cette règle est avant celles des interfaces atteignant Internet.

Enfin, dans Firewall / Rules / LAN, nous ajouterons la règle suivante. Comme pour le NAT, nous devons nous assurer qu’elle est avant vos règles redirigeant le trafic vers les passerelles WAN et VPN.

Résolveur DNS#
Si vous utilisez quelque chose de similaire à la configuration Apache que j’ai mentionnée précédemment, vous aurez un petit problème : votre entrée DNS pointera vers l’adresse IP du serveur plutôt que vers l’adresse VPN interne. Un moyen de corriger cela est d’utiliser le résolveur DNS de pfSense. Par exemple, si vous voulez que git.me.com et calendar.me.com soient atteints via le réseau VPN, vous pouvez ajouter un Host Override et le configurer comme suit.

Sources#
- Using the VPN as the default gateway (Ubuntu doc)
- Wireguard Client Addition without restart (ServerFault)
Crédits#
- Image de couverture par Peter Albanese sur Unsplash