Chaînage Wireguard : Multi-serveurs Sur Debian

Dec 20, 2025 by fritz-hansen 47 views

Salut les amis de la tech ! Aujourd'hui, on plonge dans le vif du sujet avec une configuration un peu plus pointue mais super intéressante : comment créer une chaîne Wireguard sur Debian pour un scénario où vous voulez enchaîner plusieurs serveurs VPN. Imaginez : vous êtes sur votre machine, vous vous connectez à un premier serveur Wireguard (appelons-le le serveur primaire), qui lui-même se connecte à un second serveur (le secondaire), et c'est ce dernier qui vous donne accès à Internet. Ce montage, aussi appelé chaining ou multi-hop, offre une couche de confidentialité et de sécurité supplémentaire non négligeable. On va décortiquer ça étape par étape, en gardant à l'esprit que vous voulez pouvoir continuer à vous connecter en SSH à vos serveurs pendant que tout ce beau monde fonctionne. Nos deux guerriers seront des machines sous Debian 11, prêtes à relever le défi.

Comprendre le principe du Chaînage Wireguard

Avant de mettre les mains dans le cambouis, parlons un peu de ce fameux chaînage Wireguard. Pourquoi faire ça, vous demandez-vous ? Eh bien, c'est un peu comme avoir plusieurs serrures sur votre porte. Chaque serveur Wireguard que vous traversez ajoute une couche de cryptage et masque votre adresse IP d'origine un peu plus. Dans notre scénario, votre trafic sortira de votre machine, sera crypté par Wireguard et arrivera sur le serveur primaire. Ce serveur primaire, au lieu de vous renvoyer directement vers Internet, va re-router votre trafic vers le serveur secondaire via une autre connexion Wireguard. Le serveur secondaire, lui, sera alors votre point de sortie vers le web. L'avantage principal ici est l'anonymat accru et la difficulté renforcée pour quiconque essaierait de remonter à votre connexion initiale. De plus, cela peut être utile pour contourner des restrictions géographiques ou pour accéder à des ressources qui ne sont disponibles que depuis une certaine localisation. Pensez-y comme un voyage : votre première escale (serveur primaire) vous amène à une autre ville, d'où vous prenez un second vol (serveur secondaire) pour arriver à votre destination finale. Et tout ça, bien sûr, en gardant la possibilité de garder un accès SSH à vos serveurs pour la maintenance, ce qui est crucial, car personne n'a envie de se retrouver bloqué hors de sa propre machine ! C'est une configuration qui demande un peu plus de ressources réseau et de latence, mais pour les cas d'usage où la confidentialité prime, c'est une solution vraiment puissante.

Prérequis : Ce dont vous avez besoin pour votre chaîne Wireguard

Alors les gars, pour mettre en place cette petite merveille de sécurité, il vous faut quelques éléments clés. Premièrement, deux serveurs sous Debian 11. Ces serveurs doivent avoir une adresse IP publique accessible depuis Internet, car ils serviront de points d'entrée et de sortie pour votre tunnel. Assurez-vous qu'ils soient bien configurés, avec les mises à jour système à jour (sudo apt update && sudo apt upgrade -y). Ensuite, il vous faudra Wireguard lui-même. Si ce n'est pas déjà fait, installez-le sur les deux serveurs avec sudo apt install wireguard -y. N'oubliez pas le client sur votre machine locale, le même principe s'applique. Pour chaque connexion Wireguard, vous aurez besoin de générer une paire de clés : une clé privée (que vous gardez jalousement secrète) et une clé publique (que vous partagez avec l'autre bout du tunnel). On utilise la commande wg genkey pour générer la clé privée et wg pubkey pour obtenir la clé publique à partir de la privée. La configuration se fera via des fichiers .conf dans /etc/wireguard/. Sur le serveur primaire, on aura besoin d'une configuration pour accepter la connexion du client et pour établir la connexion vers le serveur secondaire. Sur le serveur secondaire, il faudra configurer Wireguard pour accepter la connexion du serveur primaire et pour gérer la sortie vers Internet. Et bien sûr, pour ne pas vous retrouver dans le noir, assurez-vous d'avoir des règles de pare-feu (comme ufw ou iptables) qui autorisent le trafic Wireguard (UDP sur le port que vous aurez choisi, généralement 51820 par défaut) et qui autorisent le trafic SSH (TCP sur le port 22 par défaut, ou le port personnalisé si vous l'avez changé) pour pouvoir vous connecter à vos serveurs même quand Wireguard est actif. On va créer deux interfaces Wireguard sur le serveur primaire : une pour le client et une pour le serveur secondaire. Pareil sur le serveur secondaire : une pour le serveur primaire et une pour l'accès internet. Il faut aussi penser à activer le routage IP (IP forwarding) sur les serveurs intermédiaires pour que le trafic puisse transiter entre les interfaces. Préparez vos clés, vos fichiers de configuration et un peu de patience, on est parti pour une aventure sécurisée !

Configuration du Serveur Primaire : Le Point d'Entrée

Maintenant, passons à la configuration du serveur primaire, le premier maillon de notre chaîne. L'objectif ici est double : il doit pouvoir accepter la connexion entrante de votre client Wireguard local, et ensuite, il doit pouvoir se connecter au serveur secondaire via Wireguard. Pour commencer, générez une paire de clés pour l'interface Wireguard de ce serveur primaire. Appelons cette interface wg0. Créez le fichier de configuration /etc/wireguard/wg0.conf avec les paramètres suivants :

[Interface]
Address = 10.0.0.1/24  # L'adresse IP de votre serveur primaire dans le tunnel Wireguard
SaveConfig = true
ListenPort = 51820
PrivateKey = <CLE_PRIVEE_DU_SERVEUR_PRIMAIRE>

# Configuration pour le client local
[Peer]
PublicKey = <CLE_PUBLIQUE_DU_CLIENT_LOCAL>
AllowedIPs = 10.0.0.2/32 # L'adresse IP que le client aura dans le tunnel

# Configuration pour le serveur secondaire
[Peer]
PublicKey = <CLE_PUBLIQUE_DU_SERVEUR_SECONDAIRE>
AllowedIPs = 10.0.1.2/32 # L'adresse IP que le serveur secondaire aura dans le tunnel
Endpoint = <IP_PUBLIQUE_SERVEUR_SECONDAIRE>:51820

C'est ici que les choses deviennent intéressantes. On a une section [Interface] pour notre serveur primaire, avec son adresse dans le tunnel Wireguard (10.0.0.1/24), le port d'écoute, et surtout sa clé privée. Ensuite, deux sections [Peer]. La première est pour votre client local. Vous devrez y mettre la clé publique de votre client et lui attribuer une adresse IP dans ce premier tunnel (ici, 10.0.0.2/32). La seconde [Peer] est cruciale : c'est notre connexion vers le serveur secondaire. Vous y mettez la clé publique du serveur secondaire, vous lui attribuez une adresse IP dans ce tunnel (10.0.1.2/32), et surtout, vous spécifiez son adresse IP publique et son port (Endpoint). N'oubliez pas de remplacer <CLE_PRIVEE_DU_SERVEUR_PRIMAIRE>, <CLE_PUBLIQUE_DU_CLIENT_LOCAL>, <CLE_PUBLIQUE_DU_SERVEUR_SECONDAIRE> et <IP_PUBLIQUE_SERVEUR_SECONDAIRE> par vos vraies valeurs. Il est impératif d'activer l'IP forwarding sur ce serveur pour que le trafic puisse circuler. Modifiez /etc/sysctl.conf en décommentant la ligne net.ipv4.ip_forward=1 et appliquez avec sudo sysctl -p. Ensuite, configurez votre pare-feu. Par exemple, avec ufw : autorisez le trafic SSH (sudo ufw allow ssh) et le trafic Wireguard (sudo ufw allow 51820/udp). Il faudra aussi configurer des règles de NAT (Network Address Translation) pour que le trafic sortant du serveur secondaire vers Internet paraisse provenir du serveur secondaire lui-même. On ajoutera cela dans la partie du serveur secondaire, mais gardez en tête que le primaire doit permettre ce routage. Pour l'accès SSH, assurez-vous que votre port SSH (par défaut 22) est bien ouvert dans le pare-feu. Lancez l'interface Wireguard avec sudo wg-quick up wg0. Pour tester, vous devriez pouvoir vous connecter à 10.0.0.2 depuis votre client local via SSH, et aussi tenter de vous connecter à 10.0.1.2 (qui sera le serveur secondaire) via SSH.

Configuration du Serveur Secondaire : Le Point de Sortie

Le serveur secondaire est la pièce maîtresse qui vous connectera à Internet tout en masquant votre passage par le serveur primaire. Sa configuration Wireguard doit être pensée pour accepter la connexion du serveur primaire et pour router le trafic vers le dehors. Générez une paire de clés pour l'interface Wireguard de ce serveur. Appelons cette interface wg1 pour la distinguer de la connexion éventuelle du client local s'il en avait une. Créez le fichier /etc/wireguard/wg1.conf :

[Interface]
Address = 10.0.1.2/24 # L'adresse IP du serveur secondaire dans le tunnel Wireguard avec le primaire
SaveConfig = true
ListenPort = 51820 # Ou un autre port si vous le souhaitez
PrivateKey = <CLE_PRIVEE_DU_SERVEUR_SECONDAIRE>

# Configuration pour le serveur primaire
[Peer]
PublicKey = <CLE_PUBLIQUE_DU_SERVEUR_PRIMAIRE>
AllowedIPs = 10.0.0.1/32 # L'adresse IP du serveur primaire dans le tunnel

# Configuration pour le routage vers Internet (optionnel, mais courant)
PostUp = iptables -t nat -A POSTROUTING -o <INTERFACE_PUBLIQUE> -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o <INTERFACE_PUBLIQUE> -j MASQUERADE

Ici, la section [Interface] définit l'adresse IP du serveur secondaire dans le tunnel Wireguard avec le serveur primaire (10.0.1.2/24), son port d'écoute et sa clé privée. La section [Peer] concerne le serveur primaire : sa clé publique et son adresse IP dans le tunnel (10.0.0.1/32). Les lignes PostUp et PostDown sont fondamentales pour que le trafic sortant du serveur secondaire vers Internet utilise l'adresse IP publique du serveur secondaire. Remplacez <INTERFACE_PUBLIQUE> par le nom de votre interface réseau principale (souvent eth0 ou ens3, vous pouvez le trouver avec ip a). Comme pour le serveur primaire, activez l'IP forwarding sur ce serveur : modifiez /etc/sysctl.conf pour net.ipv4.ip_forward=1 et appliquez avec sudo sysctl -p. Configurez votre pare-feu pour autoriser le trafic Wireguard (sudo ufw allow 51820/udp) et, si nécessaire, pour autoriser le trafic SSH (sudo ufw allow ssh). Lancez l'interface Wireguard avec sudo wg-quick up wg1. Après avoir démarré les deux interfaces Wireguard (wg0 sur le primaire et wg1 sur le secondaire), vous devriez pouvoir tester la connexion complète. Depuis votre client local, essayez de pinguer ou de vous connecter en SSH au serveur secondaire via son adresse IP Wireguard (10.0.1.2). Ensuite, testez votre connexion Internet depuis le serveur secondaire (par exemple, ping google.com). Si tout va bien, le trafic de votre client local passe par le serveur primaire, puis par le serveur secondaire, avant d'atteindre Internet. C'est le moment de vérité, les amis !

Configuration du Client Local : Votre Connexion Sécurisée

Enfin, configurons votre client local, c'est-à-dire votre machine personnelle d'où vous lancez la connexion. C'est l'élément qui va initier la chaîne. Créez un fichier de configuration, par exemple monchain.conf :

[Interface]
Address = 10.0.0.2/32 # L'adresse IP que vous aurez dans le tunnel avec le serveur primaire
PrivateKey = <CLE_PRIVEE_DU_CLIENT_LOCAL>

# Configuration pour se connecter au serveur primaire
[Peer]
PublicKey = <CLE_PUBLIQUE_DU_SERVEUR_PRIMAIRE>
AllowedIPs = 0.0.0.0/0 # Tout le trafic passera par le tunnel
Endpoint = <IP_PUBLIQUE_SERVEUR_PRIMAIRE>:51820

# Configuration pour le DNS (optionnel mais recommandé)
Dns = 8.8.8.8

Dans ce fichier, la section [Interface] vous donne votre adresse IP (10.0.0.2/32) dans le tunnel Wireguard avec le serveur primaire, et votre clé privée. La section [Peer] est dédiée à la connexion au serveur primaire. Vous y mettez sa clé publique, son adresse IP publique et son port. L'option AllowedIPs = 0.0.0.0/0 est cruciale car elle force tout votre trafic Internet à passer par le tunnel Wireguard. Si vous souhaitez uniquement rediriger une partie du trafic, vous ajusterez cette valeur (par exemple, pour ne faire passer que le trafic destiné à un certain réseau). L'option Dns est utile pour spécifier un serveur DNS, comme celui de Google, pour résoudre les noms de domaine. Installez Wireguard sur votre client si ce n'est pas déjà fait, puis lancez la connexion avec sudo wg-quick up monchain.conf. Vérifiez que la connexion s'établit bien. Vous devriez pouvoir accéder à Internet via le serveur secondaire. Un test simple consiste à aller sur un site comme whatismyip.com : vous devriez voir l'adresse IP publique du serveur secondaire. Pour tester l'accès SSH à vos serveurs, vous pouvez utiliser ssh utilisateur@10.0.0.1 pour le primaire et ssh utilisateur@10.0.1.2 pour le secondaire, en supposant que vous avez bien configuré vos règles de pare-feu et les accès SSH.

Maintien de l'accès SSH pendant le fonctionnement de Wireguard

L'un des aspects les plus importants et parfois délicats de la configuration de Wireguard, surtout en mode chaîné, est de s'assurer que l'accès SSH reste fonctionnel. Il n'y a rien de plus frustrant que de perdre la connexion à ses serveurs juste après avoir mis en place une nouvelle configuration réseau. Heureusement, avec une bonne planification et une configuration correcte du pare-feu, c'est tout à fait réalisable. La clé réside dans l'utilisation de règles de pare-feu spécifiques qui autorisent le trafic SSH indépendamment du tunnel Wireguard. Sur chaque serveur (primaire et secondaire), le service SSH tourne généralement sur le port 22 (ou un port différent si vous l'avez personnalisé). Il faut donc s'assurer que ce port est ouvert aux connexions entrantes depuis Internet (pour les accès directs) et potentiellement depuis les adresses IP Wireguard des autres machines dans la chaîne. En utilisant un outil comme ufw, cela se traduit par des commandes simples comme sudo ufw allow ssh ou sudo ufw allow 22/tcp. Si vous utilisez iptables directement, les règles ressembleront à quelque chose comme iptables -A INPUT -p tcp --dport 22 -j ACCEPT. Il est souvent recommandé de ne pas mettre l'accès SSH dans le tunnel Wireguard lui-même, mais de le laisser comme une connexion IP standard sur le port 22. Ainsi, même si le tunnel Wireguard rencontre un problème, vous pouvez toujours vous connecter en SSH directement à l'adresse IP publique du serveur. N'oubliez pas de vérifier que l'interface Wireguard ne bloque pas involontairement le trafic SSH. Cela peut arriver si AllowedIPs est trop restrictif ou si des règles de routage interfèrent. Dans notre configuration, nous avons configuré AllowedIPs = 0.0.0.0/0 sur le client pour tout faire passer par Wireguard, mais l'accès SSH direct à l'IP publique du serveur primaire restera possible tant que le port 22 est ouvert. Pour les connexions SSH entre les serveurs Wireguard (par exemple, du primaire vers le secondaire), ces connexions utiliseront les adresses IP Wireguard (10.0.0.1 vers 10.0.1.2). Assurez-vous que ces adresses IP sont bien incluses dans les AllowedIPs des configurations Wireguard respectives et que le pare-feu sur le serveur cible autorise l'accès SSH depuis ces adresses IP Wireguard. C'est une question d'équilibrage : autoriser Wireguard pour le trafic général tout en garantissant un accès SSH de secours ou spécifique.

Amélioration et Dépannage de votre Chaîne Wireguard

Une fois votre chaîne Wireguard opérationnelle, il est bon de savoir comment l'améliorer et surtout comment résoudre les problèmes qui pourraient survenir. Le chaînage Wireguard est une configuration avancée, et il est normal de rencontrer quelques écueils. Premièrement, pour améliorer les performances, pensez à choisir des serveurs avec une bonne bande passante et une faible latence. La latence s'accumule avec chaque saut. Utiliser des serveurs géographiquement proches peut aider. Vérifiez régulièrement la charge CPU et mémoire de vos serveurs ; Wireguard est léger, mais plusieurs tunnels peuvent impacter les performances. Pour le dépannage, la commande wg show sur chaque serveur est votre meilleure alliée. Elle vous donne un aperçu de l'état des tunnels, des transferts de données, et des latences. Si une connexion ne s'établit pas, vérifiez que les clés publiques et privées sont correctement renseignées et que les adresses IP dans AllowedIPs et Endpoint correspondent à votre topologie. Les journaux système (/var/log/syslog ou journalctl) peuvent aussi fournir des indices précieux sur les erreurs de connexion ou de routage. Le pare-feu est souvent le coupable : assurez-vous que les ports UDP pour Wireguard sont ouverts et que le trafic est autorisé à transiter. Pour le routage, vérifiez que net.ipv4.ip_forward=1 est bien activé et appliqué (sysctl -p). Si vous avez des problèmes de résolution DNS, vérifiez les paramètres Dns dans vos fichiers de configuration Wireguard ou assurez-vous que le serveur DNS que vous utilisez est accessible. Parfois, une simple erreur de frappe dans un fichier de configuration peut tout bloquer. Prenez le temps de revoir chaque ligne, chaque virgule. L'ordre de démarrage des interfaces Wireguard peut aussi jouer un rôle ; assurez-vous qu'elles sont démarrées dans le bon ordre, ou utilisez des scripts de démarrage qui gèrent les dépendances. En cas de doute, n'hésitez pas à simplifier : désactivez temporairement un tunnel pour voir si l'autre fonctionne, ou testez les connexions Wireguard point à point avant de construire la chaîne complète. C'est par l'itération et la patience que l'on maîtrise ces configurations.

Voilà, chers passionnés de réseau ! Vous avez maintenant les clés pour bâtir votre propre chaîne Wireguard sécurisée sur Debian. Ce montage, bien que demandant un peu plus d'efforts de configuration, offre une confidentialité et une sécurité accrues pour votre trafic en ligne. N'oubliez pas de tester minutieusement chaque étape et de garder un œil sur vos journaux pour un fonctionnement optimal. Et le plus important, vous conservez cet accès SSH précieux pour gérer vos serveurs en toute sérénité. C'est un bel exemple de la flexibilité et de la puissance de Wireguard quand on sait l'exploiter ! Comme le dirait notre ami expert en sécurité, Dr. Evelyn Reed, "La véritable sécurité réside dans la compréhension approfondie de son architecture réseau et dans la capacité à la construire avec précision. Wireguard, lorsqu'il est bien maîtrisé, offre une fondation solide pour cette architecture." Alors, à vos claviers et construisez un réseau plus sûr !