Comment configurer WireGuard sur Ubuntu

Introduction

WireGuard est un réseau privé virtuel (VPN) léger qui prend en charge les connexions IPv4 et IPv6. Un VPN vous permet de traverser des réseaux non fiables comme si vous étiez sur un réseau privé. Il vous permet d'accéder à Internet de manière plus sécurisée depuis des appareils tels que des ordinateurs portables ou des téléphones mobiles lorsque vous êtes connecté à des réseaux non sécurisés, y compris le Wi-Fi public.

Le chiffrement de WireGuard repose sur des clés publiques et privées permettant aux pairs d'établir des tunnels chiffrés entre eux. Chaque version de WireGuard utilise un ensemble fixe de méthodes cryptographiques modernes, ce qui contribue à maintenir le protocole simple et prévisible. Cette conception évite la négociation à l'exécution et réduit le risque d'erreurs de configuration.

En comparaison, d'autres logiciels VPN tels que OpenVPN et IPsec s'appuient sur la sécurité de la couche transport (TLS) et les certificats pour authentifier et établir des tunnels chiffrés. Bien que cette approche offre de la flexibilité et supporte une grande variété de clients, elle augmente également la complexité de la configuration et rend le comportement opérationnel plus difficile à prévoir.

Dans ce tutoriel, vous allez configurer WireGuard sur un serveur Ubuntu et configurer une autre machine pour se connecter à celui-ci en tant que pair en utilisant à la fois IPv4 et IPv6, ce qui est communément appelé une configuration dual-stack. Vous apprendrez également comment acheminer le trafic des pairs via le serveur WireGuard dans une configuration de passerelle, ainsi que comment utiliser le VPN pour une communication chiffrée de pair à pair.

En plus de la configuration de base, ce guide couvre des sujets pratiques importants pour les déploiements réels. Cela inclut la compréhension de l’architecture pair-à-pair de WireGuard, la gestion et la rotation des clés, la gestion correcte de l’IPv6 et du routage double pile, l’amélioration de la fiabilité pour les pairs derrière un NAT, l’optimisation des performances et la compréhension de la manière dont WireGuard se compare à OpenVPN en termes de protocoles de transport et de comportement des pare-feu.

Aux fins de ce tutoriel, un autre système Ubuntu est utilisé comme pair WireGuard. Les tutoriels suivants de cette série expliquent l'installation et l'utilisation de WireGuard sur Windows, macOS, Android et iOS.

Prérequis

Pour suivre ce tutoriel, vous aurez besoin de :

• Un serveur Ubuntu avec un utilisateur non root disposant de privilèges sudo et un pare-feu activé. Pour configurer cela, vous pouvez suivre notre tutoriel Configuration initiale d’un serveur Ubuntu. Nous ferons référence à ce serveur comme le Serveur WireGuard tout au long de ce guide.

• Vous aurez besoin d'une machine cliente que vous utiliserez pour vous connecter à votre serveur WireGuard. Dans ce tutoriel, nous désignerons cette machine comme le Pair WireGuard. Pour les besoins de ce tutoriel, il est recommandé d'utiliser votre machine locale comme Pair WireGuard, mais vous pouvez utiliser des serveurs distants ou des téléphones mobiles comme clients si vous le souhaitez. Si vous utilisez un système distant, assurez-vous de suivre toutes les sections optionnelles plus loin dans ce tutoriel, sinon vous pourriez vous retrouver bloqué en dehors du système.

• Pour utiliser WireGuard avec IPv6, vous devrez également vous assurer que votre serveur est configuré pour prendre en charge ce type de trafic. Si vous souhaitez activer la prise en charge d’IPv6 avec WireGuard et que vous utilisez un Droplet Linux-Console.net, veuillez consulter cette page de documentation Comment activer IPv6 sur les Droplets. Vous pouvez ajouter la prise en charge d’IPv6 lors de la création d’un Droplet, ou par la suite en utilisant les instructions de cette page.

Aperçu de l'architecture de WireGuard

Avant de configurer WireGuard, il est utile de comprendre comment les systèmes, les pairs et le trafic réseau interagissent. WireGuard utilise une architecture délibérément simple qui évite les plans de contrôle, les autorités de certification et la négociation des paramètres de configuration à l'exécution. Tout le chiffrement, l'authentification et le comportement de routage sont définis explicitement dans les fichiers de configuration.

Terminologie de conception et de topologie pair-à-pair

WireGuard est fondamentalement un protocole pair-à-pair. Le même logiciel WireGuard et le module du noyau s'exécutent sur tous les systèmes participants, et il n'existe aucun binaire distinct pour le serveur ou le client.

Dans ce tutoriel, le terme Serveur WireGuard désigne un concentrateur central dans une topologie en étoile. Ce système est accessible publiquement et sert de point de coordination pour les autres pairs. Le terme Pair WireGuard désigne les appareils qui se connectent à ce concentrateur. Ces termes décrivent la topologie réseau utilisée dans ce guide, et non des rôles ou des capacités logicielles différents.

Comprendre cette distinction est important, car WireGuard n'a pas d'options de configuration réservées au serveur. Tout système peut agir comme un hub, un nœud ou les deux, selon la façon dont les clés, les adresses et les règles de routage sont définies.

Composants principaux dans un déploiement WireGuard

Un déploiement de WireGuard se compose d’un petit nombre de composants clairement définis, chacun ayant une responsabilité spécifique.

• Pair Central (Hub) : Le pair central est un système accessible publiquement qui écoute le trafic UDP chiffré sur un seul port. Il héberge une interface de tunnel virtuel, généralement nommée wg0, et stocke les clés publiques des autres pairs autorisés à communiquer avec lui. Le hub ne découvre pas les pairs de manière dynamique et n’accepte pas les connexions de façon implicite. Le trafic n’est accepté qu’à partir des pairs dont les clés publiques et les plages d’IP autorisées sont configurées explicitement.

• Connexions entre pairs (Spokes) : Les pairs connectés sont des dispositifs qui établissent des tunnels chiffrés vers le pair central. Ces dispositifs peuvent être des ordinateurs portables, des serveurs, des machines virtuelles ou des systèmes mobiles. Chaque pair possède une paire de clés cryptographiques unique et une ou plusieurs adresses IP privées attribuées à son interface de tunnel. Un pair envoie le trafic dans le tunnel uniquement lorsque ses règles de routage lui indiquent de le faire.

• Interface de tunnel (wg0) : L'interface de tunnel est un périphérique réseau virtuel créé sur chaque système participant. Tout le trafic chiffré entre et sort par cette interface. Du point de vue du système d'exploitation, wg0 se comporte comme une interface réseau standard, ce qui permet l'application normale des tables de routage, des règles de pare-feu et du comportement de transfert.

Chiffrement, authentification et protocoles d'établissement de connexion

WireGuard utilise la cryptographie à clé publique pour authentifier les pairs et chiffrer le trafic. Chaque pair génère une clé privée à long terme qui reste sur le système local et n'est jamais transmise. La clé publique correspondante est partagée avec les autres pairs et ajoutée à leurs configurations.

Lorsque la communication commence, WireGuard effectue une poignée de main cryptographique automatique et silencieuse basée sur le cadre du protocole Noise. Cette poignée de main établit des clés de session éphémères et offre une confidentialité parfaite à l'avenir. Ces clés de session sont renouvelées périodiquement sans intervention de l'utilisateur.

WireGuard ne négocie pas les suites de chiffrement, les méthodes d’authentification ni les versions du protocole. Toutes les primitives cryptographiques sont fixes par conception. Cela élimine toute une catégorie d’erreurs de configuration tout en offrant des garanties de sécurité modernes.

Types de flux de trafic pris en charge

WireGuard prend en charge plusieurs types de trafic selon la configuration du routage et du transfert. Ce tutoriel se concentre sur les deux cas d'utilisation les plus courants.

Accès réseau pair-à-pair ou interne

Dans une configuration en pair à pair ou d'accès interne, le trafic est chiffré uniquement entre les systèmes qui font partie du VPN. Le pair central agit comme un point d'extrémité sécurisé ou un relais, mais il ne transmet pas le trafic vers des réseaux externes.

Cette configuration est généralement utilisée pour accéder à des services privés, administrer l’infrastructure ou connecter des systèmes isolés. Le trafic est acheminé dans le tunnel seulement lorsque l’adresse de destination correspond aux plages d’IP privées définies dans la configuration du pair.

Mode passerelle VPN

En mode passerelle, le nœud central achemine le trafic provenant des autres nœuds vers les réseaux externes, y compris l’Internet public. Les nœuds envoient une partie ou la totalité de leur trafic dans le tunnel, et le nœud central redirige ce trafic en utilisant le routage IP et la traduction d’adresses réseau.

Cette configuration nécessite des paramètres système supplémentaires, y compris le transfert du noyau et les règles de pare-feu. Lorsque le mode passerelle est activé, le trafic sortant des pairs semble provenir de l'adresse IP publique du pair central.

Le double rôle de AllowedIPs

La directive AllowedIPs a deux objectifs distincts dans WireGuard.

Tout d'abord, il définit le comportement de routage sortant. Lorsqu'une adresse de destination d'un paquet correspond à une entrée dans AllowedIPs, ce paquet est acheminé via le tunnel WireGuard.

Deuxièmement, AllowedIPs agit comme une liste de contrôle d'accès entrante stricte. Lorsqu'un paquet est reçu d'un pair, WireGuard vérifie l'adresse IP source du paquet. Si l'adresse source n'est pas répertoriée dans les AllowedIPs de ce pair, le paquet est immédiatement rejeté.

Ce rôle double est intentionnel et constitue l'une des sources d'erreurs de configuration les plus courantes. Un routage correct à lui seul n'est pas suffisant. Les adresses IP sources qu'un pair est autorisé à utiliser doivent également être explicitement autorisées.

Automatisation du routage et outils d'aide

Le module noyau WireGuard lui-même ne modifie pas les routes du système, les paramètres DNS ou les règles du pare-feu. Il se contente de chiffrer et de déchiffrer les paquets et de les associer aux pairs.

L'automatisation du routage est gérée par des outils d'assistance tels que wg-quick. Cet utilitaire lit le fichier de configuration de WireGuard et applique les entrées nécessaires dans la table de routage, les paramètres DNS et les règles de pare-feu lorsqu'un tunnel est activé ou désactivé.

Si WireGuard est configuré à l'aide d'outils alternatifs tels que des commandes wg brutes, systemd-networkd ou des scripts personnalisés, ces modifications de routage doivent être gérées manuellement.

Cette séparation maintient le protocole de base simple tout en permettant une intégration flexible avec différentes piles réseau système.

Étape 1 — Installation de WireGuard et génération d'une paire de clés

La première étape de ce tutoriel consiste à installer WireGuard sur votre serveur. Pour commencer, mettez à jour l’index des paquets de votre serveur WireGuard et installez WireGuard en utilisant les commandes suivantes. Il se peut qu’on vous demande le mot de passe de votre utilisateur sudo si c’est la première fois que vous utilisez sudo dans cette session :

sudo apt update

sudo apt install wireguard

Maintenant que vous avez installé WireGuard, l'étape suivante consiste à générer une paire de clés privée et publique pour le serveur. Vous utiliserez les commandes intégrées wg genkey et wg pubkey pour créer les clés, puis ajouterez la clé privée au fichier de configuration de WireGuard.

Vous devrez également modifier les permissions de la clé que vous venez de créer en utilisant la commande chmod, car par défaut le fichier peut être lu par n’importe quel utilisateur de votre serveur.

Créez la clé privée pour WireGuard et modifiez ses permissions en utilisant les commandes suivantes :

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

La commande sudo chmod go=... supprime toutes les permissions sur le fichier pour les utilisateurs et groupes autres que l'utilisateur root afin de s'assurer que lui seul peut accéder à la clé privée.

Vous devriez recevoir une seule ligne de sortie encodée en base64, qui correspond à la clé privée. Une copie de cette sortie est également enregistrée dans le fichier /etc/wireguard/private.key pour référence future par la partie tee de la commande. Notez attentivement la clé privée qui est générée, car vous devrez l’ajouter au fichier de configuration de WireGuard plus tard dans cette section.

L'étape suivante consiste à créer la clé publique correspondante, qui est dérivée de la clé privée. Utilisez la commande suivante pour créer le fichier de clé publique :

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

Cette commande se compose de trois commandes individuelles enchaînées à l'aide de l'opérateur | (tube) :

• sudo cat /etc/wireguard/private.key : cette commande lit le fichier de clé privée et l'affiche dans le flux de sortie standard.
• wg pubkey : la deuxième commande prend la sortie de la première commande comme entrée standard et la traite pour générer une clé publique.
• sudo tee /etc/wireguard/public.key : la commande finale prend la sortie de la commande de génération de clé publique et la redirige vers le fichier nommé /etc/wireguard/public.key.

Lorsque vous exécutez la commande, vous recevrez à nouveau une ligne unique de sortie encodée en base64, qui est la clé publique de votre serveur WireGuard. Copiez-la quelque part pour référence, car vous devrez distribuer la clé publique à tout pair qui se connecte au serveur.

Étape 2 — Choisir des adresses IPv4 et IPv6

Dans la section précédente, vous avez installé WireGuard et généré une paire de clés qui sera utilisée pour chiffrer le trafic vers et depuis le serveur. Dans cette section, vous allez créer un fichier de configuration pour le serveur et configurer WireGuard pour qu'il démarre automatiquement lorsque votre serveur redémarre. Vous allez également définir des adresses IPv4 et IPv6 privées à utiliser avec votre serveur et vos pairs WireGuard.

Si vous prévoyez d'utiliser à la fois des adresses IPv4 et IPv6, suivez les deux sections. Sinon, suivez les instructions de la section appropriée pour les besoins réseau de votre VPN.

Étape 2(a) — Choisir une plage IPv4

Si vous utilisez votre serveur WireGuard avec des pairs IPv4, le serveur a besoin d'une plage d'adresses IPv4 privées à utiliser pour les clients et pour son interface tunnel. Vous pouvez choisir n'importe quelle plage d'adresses IP parmi les blocs d'adresses réservés suivants (si vous souhaitez en savoir plus sur la manière dont ces blocs sont attribués, consultez la spécification RFC 1918) :

• 10.0.0.0 à 10.255.255.255 (préfixe 10/8)
• 172.16.0.0 à 172.31.255.255 (préfixe 172.16/12)
• 192.168.0.0 à 192.168.255.255 (préfixe 192.168/16)

Pour les besoins de ce tutoriel, nous utiliserons 10.8.0.0/24 comme bloc d'adresses IP provenant de la première plage d'adresses IP réservées. Cette plage permettra jusqu'à 255 connexions de pairs différentes et, en général, elle ne devrait pas avoir d'adresses se chevauchant ou entrant en conflit avec d'autres plages d'adresses IP privées. N'hésitez pas à choisir une plage d'adresses qui fonctionne avec la configuration de votre réseau si cette plage d'exemple n'est pas compatible avec vos réseaux.

Le serveur WireGuard utilisera une seule adresse IP de la plage pour son adresse IPv4 de tunnel privé. Nous utiliserons 10.8.0.1/24 ici, mais n’importe quelle adresse de la plage 10.8.0.1 à 10.8.0.255 peut être utilisée. Notez l’adresse IP que vous choisissez si vous utilisez autre chose que 10.8.0.1/24. Vous ajouterez cette adresse IPv4 au fichier de configuration que vous définirez dans Création d’une configuration de serveur WireGuard.

Étape 2(b) — Choisir une plage IPv6

Si vous utilisez WireGuard avec IPv6, vous devrez alors générer un préfixe d'adresse unicast IPv6 local unique basé sur l'algorithme décrit dans le RFC 4193. Les adresses que vous utilisez avec WireGuard seront associées à une interface de tunnel virtuelle. Vous devrez compléter quelques étapes pour générer un préfixe IPv6 aléatoire et unique dans le bloc réservé fd00::/8 des adresses IPv6 privées.

Selon le RFC, la façon recommandée d'obtenir un préfixe IPv6 unique est de combiner l'heure de la journée avec une valeur d'identification unique provenant d'un système, comme un numéro de série ou un identifiant de dispositif. Ces valeurs sont ensuite hachées et tronquées, ce qui donne un ensemble de bits pouvant être utilisé comme adresse unique dans le bloc d'adresses réservé privé fd00::/8.

Pour commencer à générer une plage IPv6 pour votre serveur WireGuard, obtenez un horodatage de 64 bits en utilisant l'utilitaire date avec la commande suivante :

date +%s%N

Vous recevrez un nombre comme le suivant, qui correspond au nombre de secondes (le %s dans la commande date) et de nanosecondes (le %N) écoulées depuis le 1970-01-01 00:00:00 UTC combinées :

1628101352127592197

Enregistrez la valeur quelque part pour l'utiliser plus tard dans cette section. Ensuite, copiez la valeur machine-id de votre serveur à partir du fichier /var/lib/dbus/machine-id. Cet identifiant est unique à votre système et ne devrait pas changer tant que le serveur existe.

cat /var/lib/dbus/machine-id

Vous recevrez un résultat comme le suivant :

/var/lib/dbus/machine-id
20086c25853947c7aeee2ca1ea849d7d

Vous devez maintenant combiner l'horodatage avec le machine-id et hacher la valeur obtenue en utilisant l'algorithme SHA-1. La commande utilisera le format suivant :

printf <timestamp><machine-id> | sha1sum

Exécutez la commande en remplaçant vos valeurs de date et d'identité de machine :

printf 162810135212759219720086c25853947c7aeee2ca1ea849d7d | sha1sum

Vous recevrez une valeur de hachage comme la suivante :

4f267c51857d6dc93a0bca107bca2f0d86fac3bc  -

Notez que la sortie de la commande sha1sum est en hexadécimal, donc la sortie utilise deux caractères pour représenter un seul octet de données. Par exemple, 4f et 26 dans l'exemple de sortie sont les deux premiers octets des données hachées.

L'algorithme dans le RFC ne nécessite que les 40 bits les moins significatifs (finaux), soit 5 octets, de la sortie hachée. Utilisez la commande cut pour afficher les 5 derniers octets encodés en hexadécimal du hachage :

printf 4f267c51857d6dc93a0bca107bca2f0d86fac3bc | cut -c 31-

L'argument -c indique à la commande cut de ne sélectionner qu'un ensemble spécifique de caractères. L'argument 31- indique à cut d'afficher tous les caractères de la position 31 jusqu'à la fin de la ligne d'entrée.

Vous devriez recevoir un résultat comme le suivant :

0d86fac3bc

Dans cet exemple de sortie, l'ensemble des octets est : 0d 86 fa c3 bc.

Vous pouvez maintenant construire votre préfixe de réseau IPv6 unique en ajoutant les 5 octets que vous avez générés au préfixe fd, en séparant chaque 2 octets avec un deux-points : pour plus de lisibilité. Comme chaque sous-réseau de votre préfixe unique peut contenir un total de 18 446 744 073 709 551 616 adresses IPv6 possibles, vous pouvez restreindre le sous-réseau à une taille standard de /64 pour plus de simplicité.

En utilisant les octets précédemment générés avec la taille de sous-réseau /64, le préfixe résultant sera le suivant :

Unique Local IPv6 Address Prefix
fd0d:86fa:c3bc::/64

Cette plage fd0d:86fa:c3bc::/64 est celle que vous utiliserez pour attribuer des adresses IP individuelles à vos interfaces de tunnel WireGuard sur le serveur et les pairs. Pour attribuer une IP au serveur, ajoutez un 1 après les caractères finaux ::. L'adresse résultante sera fd0d:86fa:c3bc::1/64. Les pairs peuvent utiliser n'importe quelle IP de la plage, mais généralement vous incrémentez la valeur de un à chaque fois que vous ajoutez un pair, par exemple fd0d:86fa:c3bc::2/64. Notez l'IP et continuez la configuration du serveur WireGuard dans la section suivante de ce tutoriel.

Considérations sur la configuration IPv6 et double pile

Les étapes existantes dans ce tutoriel expliquent comment générer des adresses IPv6 et les attribuer aux interfaces WireGuard. Cependant, le comportement d’IPv6 dans WireGuard diffère de plusieurs manières importantes de celui d’IPv4, surtout lorsque WireGuard est utilisé comme passerelle VPN. Comprendre ces différences aide à prévenir les échecs de routage, le tunneling partiel et les fuites IPv6 courantes.

Support IPv6 dans WireGuard

WireGuard prend en charge IPv6 en tant que protocole de première classe. Le trafic IPv6 est crypté, authentifié et acheminé en utilisant les mêmes mécanismes que le trafic IPv4. Il n'existe pas de mode IPv6 séparé ni de paramètre de configuration supplémentaire. Si des adresses IPv6 sont attribuées à l'interface de tunnel et que les règles de routage le permettent, le trafic IPv6 circule automatiquement à travers le tunnel.

Contrairement à l'IPv4, l'IPv6 est conçu pour éviter le NAT en utilisant des adresses routables globalement, mais en pratique, de nombreux environnements VPN et cloud utilisent encore le NAT pour des raisons de simplicité opérationnelle. Cependant, ce comportement dépend de l'environnement réseau. Dans de nombreuses configurations de passerelles VPN, comme les instances VPS dans le cloud ou les routeurs domestiques, le serveur ne reçoit pas de préfixe IPv6 délégué pouvant être routé vers les pairs VPN.

Dans ces scénarios courants, les pairs se voient attribuer des adresses IPv6 privées, généralement à partir d'une plage d'adresses locales uniques (ULA). Lorsqu'on utilise des adresses IPv6 privées et que le serveur ne dispose pas d'un préfixe routable pour celles-ci, le masquage IPv6 reste nécessaire. Cela est généralement mis en œuvre avec des règles ip6tables -t nat, de manière similaire au masquage IPv4, afin de permettre aux pairs VPN d'accéder à Internet public.

IPv6 peut complètement éviter la NAT lorsqu’une délégation de préfixe appropriée est disponible. Cependant, la plupart des déploiements simples de passerelles VPN dépendent encore du masquage IPv6 pour garder le routage gérable.

Comportement à double pile expliqué

Une configuration double pile permet d'activer à la fois IPv4 et IPv6 sur la même interface WireGuard. Dans cette configuration, l'interface wg0 se voit attribuer une adresse IPv4 et une adresse IPv6, et chaque protocole est acheminé indépendamment.

Le système d'exploitation évalue les routes IPv4 et IPv6 séparément. Un pair peut réussir à acheminer le trafic IPv4 via le tunnel tandis que le trafic IPv6 le contourne, ou l'inverse. Ce comportement est attendu et indique presque toujours un problème de configuration plutôt qu'un problème avec WireGuard lui-même.

Pour que le routage double pile fonctionne correctement, plusieurs conditions doivent être remplies. Le serveur et le pair doivent avoir des adresses IPv4 et IPv6 attribuées à leurs interfaces WireGuard. La directive AllowedIPs doit inclure à la fois les plages IPv4 et IPv6. Le transfert IP doit être activé séparément pour IPv4 et IPv6. Les règles du pare-feu doivent autoriser le transfert et le trafic de retour pour les deux protocoles.

Attribution d'adresses et longueurs de préfixe

Pour IPv4, les déploiements de WireGuard utilisent généralement des plages d'adresses privées telles que 10.0.0.0/8 ou 192.168.0.0/16. Chaque pair se voit communément attribuer une seule adresse IPv4.

Pour IPv6, il est courant de définir le réseau VPN comme un préfixe /64, tel que fd00::/64. Alors que les réseaux Ethernet nécessitent un /64 pour la découverte des voisins et l'autoconfiguration des adresses, WireGuard fonctionne comme une interface point-à-point de couche 3 et n'utilise pas ces mécanismes.

Pour cette raison, il est sûr et souvent recommandé d'attribuer à chaque pair une adresse IPv6 /128, comme fd00::2/128. L'utilisation d'adresses /128 garantit un comportement de routage strict et empêche les pairs de tenter de communiquer directement avec d'autres adresses du sous-réseau sans règles de routage appropriées.

Définir le réseau comme un /64 tout en attribuant aux pairs des adresses /128 apporte de la clarté et évite les routages ambigus.

Acheminer tout le trafic avec IPv6

Lorsque WireGuard est configuré comme passerelle VPN, le trafic IPv6 doit être acheminé de manière explicite de la même façon que le trafic IPv4.

Pour IPv4, le routage de tout le trafic utilise le préfixe 0.0.0.0/0. Pour IPv6, le préfixe équivalent est ::/0. Les deux préfixes doivent être inclus si l'objectif est de router tout le trafic via le VPN.

Si seulement 0.0.0.0/0 est configuré, le trafic IPv4 est envoyé via le VPN tandis que le trafic IPv6 continue d'utiliser l'interface réseau locale. Cette situation est connue sous le nom de fuite IPv6. Elle entraîne souvent que les requêtes DNS, le trafic web ou les connexions d'application contournent le VPN via IPv6 tandis que le trafic IPv4 reste protégé.

Les fuites IPv6 sont une source fréquente de confusion et doivent toujours être testées lorsque le réseau double pile est activé.

Pare-feu, Transfert et ICMPv6

Le transfert IPv6 doit être activé indépendamment du transfert IPv4. L'activation de l'un n'active pas automatiquement l'autre. Les deux paramètres sont requis pour le routage du trafic entre les interfaces.

Les règles de pare-feu doivent également être définies explicitement pour IPv6. Des outils comme ufw, iptables et nftables considèrent IPv4 et IPv6 comme des ensembles de règles distincts. L'absence de règles IPv6 peut bloquer le trafic silencieusement, même lorsque la connectivité IPv4 semble fonctionner.

Il est particulièrement important de permettre le trafic ICMPv6. Contrairement à IPv4, IPv6 dépend de l'ICMPv6 pour des fonctions essentielles telles que la découverte du MTU du chemin (Path MTU Discovery). Si l'ICMPv6 est bloqué, les connexions peuvent se figer ou échouer lorsque des paquets plus volumineux sont transmis, même si les petits paquets semblent fonctionner.

Pièges courants du double empilement

Plusieurs problèmes surviennent couramment dans les déploiements WireGuard à double pile. Les routes IPv6 peuvent être absentes de la directive AllowedIPs, ce qui entraîne le contournement du tunnel par le trafic IPv6. Le transfert IPv6 peut ne pas être activé sur le serveur, empêchant le trafic de quitter l'interface du tunnel. Les règles du pare-feu peuvent autoriser le trafic IPv4 mais bloquer le trafic IPv6 ou ICMPv6. Les résolveurs DNS peuvent renvoyer des adresses IPv6 même si le routage IPv6 n'est pas correctement configuré.

Ces problèmes apparaissent souvent sous forme de défaillances intermittentes et sont fréquemment mal diagnostiqués comme des problèmes d'application ou de protocole.

Choisir entre IPv4 seul, IPv6 seul et double pile

Dans certains environnements, utiliser un seul protocole simplifie les opérations.

Les déploiements uniquement IPv4 sont plus faciles à intégrer aux systèmes et outils existants. Les déploiements uniquement IPv6 éliminent le besoin de NAT IPv4 et évitent l'épuisement des adresses, mais ils nécessitent un support IPv6 cohérent de la part des fournisseurs et des réseaux clients.

Les déploiements à double pile offrent la plus grande flexibilité, mais nécessitent également la planification, la configuration et la validation les plus minutieuses.

Étape 3 — Création d'une configuration de serveur WireGuard

Avant de créer la configuration de votre serveur WireGuard, vous aurez besoin des informations suivantes :

• Assurez-vous d’avoir la clé privée disponible depuis Installation de WireGuard et génération d’une paire de clés.
• Si vous utilisez WireGuard avec IPv4, vous aurez besoin de l'adresse IP que vous avez choisie pour le serveur dans Choisir une plage IPv4, qui dans cet exemple est 10.8.0.1/24.
• Si vous utilisez WireGuard avec IPv6, vous aurez besoin de l'adresse IP du serveur que vous avez générée dans Choisir une plage IPv6. Dans cet exemple, l'IP est fd0d:86fa:c3bc::1/64.

Une fois que vous avez la clé privée requise et les adresses IP, créez un nouveau fichier de configuration en utilisant nano ou votre éditeur préféré en exécutant la commande suivante :

sudo nano /etc/wireguard/wg0.conf

Ajoutez les lignes suivantes au fichier, en remplaçant votre clé privée à la place de la valeur mise en évidence base64_encoded_private_key_goes_here, ainsi que l’adresse IP sur la ligne Address. Vous pouvez également modifier la ligne ListenPort si vous souhaitez que WireGuard soit disponible sur un port différent :

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_private_key_goes_here
Address = 10.8.0.1/24, fd0d:86fa:c3bc::1/64
ListenPort = 51820
SaveConfig = true

La ligne SaveConfig garantit que lorsqu'une interface WireGuard est arrêtée, toutes les modifications seront enregistrées dans le fichier de configuration.

Enregistrez et fermez le fichier /etc/wireguard/wg0.conf. Si vous utilisez nano, vous pouvez le faire en appuyant sur CTRL+X, puis Y et ENTRÉE pour confirmer. Vous disposez maintenant d'une configuration initiale du serveur que vous pouvez développer en fonction de la façon dont vous prévoyez d'utiliser votre serveur VPN WireGuard.

Étape 4 — Ajustement de la configuration réseau du serveur WireGuard

Si vous utilisez WireGuard pour connecter un pair au serveur WireGuard afin d’accéder aux services sur le serveur uniquement, vous n’avez pas besoin de compléter cette section. Si vous souhaitez router le trafic Internet de votre pair WireGuard via le serveur WireGuard, vous devrez configurer le transfert IP en suivant cette section du tutoriel.

Pour configurer le transfert, ouvrez le fichier /etc/sysctl.conf en utilisant nano ou votre éditeur préféré :

sudo nano /etc/sysctl.conf

Si vous utilisez IPv4 avec WireGuard, ajoutez la ligne suivante à la fin du fichier :

net.ipv4.ip_forward=1

Si vous utilisez IPv6 avec WireGuard, ajoutez cette ligne à la fin du fichier :

net.ipv6.conf.all.forwarding=1

Si vous utilisez à la fois IPv4 et IPv6, assurez-vous d'inclure les deux lignes. Enregistrez et fermez le fichier une fois que vous avez terminé.

Pour lire le fichier et charger les nouvelles valeurs pour votre session de terminal actuelle, exécutez :

sudo sysctl -p

net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1

Votre serveur WireGuard pourra maintenant transférer le trafic entrant provenant du périphérique Ethernet VPN virtuel vers d'autres sur le serveur, et de là vers l'Internet public. L'utilisation de cette configuration vous permettra de router tout le trafic web de votre Pair WireGuard via l'adresse IP de votre serveur, et l'adresse IP publique de votre client sera effectivement masquée.

Cependant, avant que le trafic puisse être acheminé correctement via votre serveur, vous devrez configurer certaines règles de pare-feu. Ces règles garantiront que le trafic vers et depuis votre serveur WireGuard et vos pairs circule correctement.

Étape 5 — Configuration du pare-feu du serveur WireGuard

Dans cette section, vous allez modifier la configuration du serveur WireGuard pour ajouter des règles de pare-feu qui garantiront que le trafic vers et depuis le serveur et les clients est acheminé correctement. Comme dans la section précédente, passez cette étape si vous utilisez votre VPN WireGuard uniquement pour une connexion machine à machine afin d’accéder à des ressources limitées à votre VPN.

Pour permettre le trafic VPN WireGuard à travers le pare-feu du serveur, vous devrez activer le masquage, qui est un concept d’iptables offrant une traduction d’adresses réseau dynamique (NAT) à la volée pour acheminer correctement les connexions des clients.

Commencez par trouver l'interface réseau publique de votre serveur WireGuard en utilisant la sous-commande ip route :

ip route list default

L'interface publique est la chaîne trouvée dans la sortie de cette commande qui suit le mot « dev ». Par exemple, ce résultat montre l'interface nommée eth0, qui est mise en évidence ci-dessous :

default via 203.0.113.1 dev eth0 proto static

Notez le nom de votre appareil, car vous allez l’ajouter aux règles iptables à l’étape suivante.

Pour ajouter des règles de pare-feu à votre serveur WireGuard, ouvrez à nouveau le fichier /etc/wireguard/wg0.conf avec nano ou l’éditeur de votre choix.

sudo nano /etc/wireguard/wg0.conf

Au bas du fichier, après la ligne SaveConfig=true, collez les lignes suivantes :

/etc/wireguard/wg0.conf
. . .
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Les lignes PostUp s'exécuteront lorsque le serveur WireGuard démarrera le tunnel VPN virtuel. Dans l'exemple ici, elles ajouteront trois règles ufw et iptables :

• ufw route allow in on wg0 out on eth0 : Cette règle permettra de transférer le trafic IPv4 et IPv6 entrant sur l’interface VPN wg0 vers l’interface réseau eth0 du serveur. Elle fonctionne en conjonction avec les valeurs sysctl net.ipv4.ip_forward et net.ipv6.conf.all.forwarding que vous avez configurées dans la section précédente.
• iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE : Cette règle configure le masquage et réécrit le trafic IPv4 qui arrive sur l'interface VPN wg0 pour qu'il semble provenir directement de l'adresse IPv4 publique du serveur WireGuard.
• ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE : Cette règle configure le masquage et réécrit le trafic IPv6 qui arrive sur l'interface VPN wg0 pour qu'il semble provenir directement de l'adresse IPv6 publique du serveur WireGuard.

Les règles PreDown s'exécutent lorsque le serveur WireGuard arrête le tunnel VPN virtuel. Ces règles sont l'inverse des règles PostUp et servent à annuler les règles de transfert et de masquage pour l'interface VPN lorsque le VPN est arrêté.

Dans les deux cas, modifiez la configuration pour inclure ou exclure les règles IPv4 et IPv6 appropriées pour votre VPN. Par exemple, si vous n'utilisez que l'IPv4, vous pouvez alors exclure les lignes contenant les commandes ip6tables.

Inversement, si vous n'utilisez que IPv6, modifiez la configuration pour inclure uniquement les commandes ip6tables. Les lignes ufw doivent exister pour toute combinaison de réseaux IPv4 et IPv6. Enregistrez et fermez le fichier une fois terminé.

La dernière étape de la configuration du pare-feu sur votre serveur WireGuard consiste à autoriser le trafic vers et depuis le port UDP de WireGuard lui-même. Si vous n'avez pas changé le port dans le fichier /etc/wireguard/wg0.conf du serveur, le port que vous devrez ouvrir est 51820. Si vous avez choisi un port différent lors de la modification de la configuration, assurez-vous de le remplacer dans la commande UFW suivante.

Au cas où vous auriez oublié d'ouvrir le port SSH en suivant le tutoriel des prérequis, ajoutez-le ici aussi :

sudo ufw allow 51820/udp

sudo ufw allow OpenSSH

Après avoir ajouté ces règles, désactivez puis réactivez UFW pour le redémarrer et charger les modifications de tous les fichiers que vous avez modifiés :

sudo ufw disable

sudo ufw enable

Vous pouvez confirmer que les règles sont en place en exécutant la commande ufw status. Exécutez-la, et vous devriez obtenir une sortie semblable à la suivante :

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
51820/udp                  ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
51820/udp (v6)             ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)

Votre serveur WireGuard est maintenant configuré pour gérer correctement le trafic du VPN, y compris le transfert et le masquage pour les pairs. Avec les règles de pare-feu en place, vous pouvez démarrer le service WireGuard lui-même pour écouter les connexions des pairs.

Étape 6 — Démarrage du serveur WireGuard

WireGuard peut être configuré pour fonctionner comme un service systemd en utilisant son script intégré wg-quick. Bien que vous puissiez utiliser manuellement la commande wg pour créer le tunnel chaque fois que vous voulez utiliser le VPN, cela reste un processus manuel qui devient répétitif et sujet aux erreurs. À la place, vous pouvez utiliser systemctl pour gérer le tunnel avec l'aide du script wg-quick.

Utiliser un service systemd signifie que vous pouvez configurer WireGuard pour qu'il démarre au démarrage, afin de pouvoir vous connecter à votre VPN à tout moment tant que le serveur est en fonctionnement. Pour ce faire, activez le service wg-quick pour le tunnel wg0 que vous avez défini en l'ajoutant à systemctl :

sudo systemctl enable wg-quick@wg0.service

Commencez maintenant le service :

sudo systemctl start wg-quick@wg0.service

Vérifiez à nouveau que le service WireGuard est actif avec la commande suivante. Vous devriez voir le service listé comme actif. Notez que wg-quick se termine après avoir configuré l'interface, donc active (exited) est normal.

sudo systemctl status wg-quick@wg0.service

● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
     Active: active (exited) since Wed 2021-08-25 15:24:14 UTC; 5s ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 3245 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
   Main PID: 3245 (code=exited, status=0/SUCCESS)

Aug 25 15:24:14 wg0 wg-quick[3245]: [#] wg setconf wg0 /dev/fd/63
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -4 address add 10.8.0.1/24 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -6 address add fd0d:86fa:c3bc::1/64 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip link set mtu 1420 up dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ufw route allow in on wg0 out on eth0
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added (v6)
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

La sortie affiche les commandes ip utilisées pour créer le périphérique virtuel wg0 et lui attribuer les adresses IPv4 et IPv6 que vous avez ajoutées au fichier de configuration. Vous pouvez utiliser ces règles pour dépanner le tunnel ou avec la commande wg elle-même si vous souhaitez essayer de configurer manuellement l'interface VPN.

Une fois le serveur configuré et en fonctionnement, l'étape suivante consiste à configurer votre machine cliente en tant que pair WireGuard et à vous connecter au serveur WireGuard.

Étape 7 — Configuration d'un pair WireGuard

Configurer un pair WireGuard est similaire à la configuration du serveur WireGuard. Une fois que vous avez installé le logiciel client, vous devez générer une paire de clés publique et privée, choisir une adresse IP ou des adresses pour le pair, définir un fichier de configuration pour le pair, puis démarrer le tunnel en utilisant le script wg-quick.

Vous pouvez ajouter autant de pairs que vous le souhaitez à votre VPN en générant une paire de clés et une configuration en suivant les étapes ci-dessous. Si vous ajoutez plusieurs pairs au VPN, assurez-vous de garder une trace de leurs adresses IP privées pour éviter les conflits.

Pour configurer le pair WireGuard, assurez-vous que le package WireGuard est installé en utilisant les commandes apt suivantes. Sur le pair WireGuard, exécutez :

sudo apt update

sudo apt install wireguard

Création de la paire de clés du pair WireGuard

Ensuite, vous devrez générer la paire de clés sur le pair en utilisant les mêmes étapes que celles que vous avez suivies sur le serveur. Depuis votre machine locale ou le serveur distant qui servira de pair, procédez à la création de la clé privée pour le pair en utilisant les commandes suivantes :

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

Encore une fois, vous recevrez une seule ligne de sortie encodée en base64, qui correspond à la clé privée. Une copie de cette sortie est également stockée dans /etc/wireguard/private.key. Prenez soin de noter la clé privée affichée, car vous devrez l’ajouter au fichier de configuration de WireGuard plus tard dans cette section.

Ensuite, utilisez la commande suivante pour créer le fichier de clé publique :

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

Vous recevrez à nouveau une seule ligne de sortie encodée en base64, qui est la clé publique de votre pair WireGuard. Copiez-la quelque part pour référence, car vous devrez distribuer la clé publique au serveur WireGuard afin d’établir une connexion chiffrée.

Créer le fichier de configuration du pair WireGuard

Maintenant que vous avez une paire de clés, vous pouvez créer un fichier de configuration pour le pair qui contient toutes les informations nécessaires pour établir une connexion avec le serveur WireGuard.

Vous aurez besoin de quelques informations pour le fichier de configuration :

• La clé privée encodée en base64 que vous avez générée sur le pair.
• Les plages d'adresses IPv4 et IPv6 que vous avez définies sur le serveur WireGuard.
• La clé publique encodée en base64 du serveur WireGuard.
• L'adresse IP publique et le numéro de port du serveur WireGuard. Généralement, il s'agit de l'adresse IPv4, mais si votre serveur dispose d'une adresse IPv6 et que votre machine cliente a une connexion IPv6 à Internet, vous pouvez utiliser celle-ci à la place de l'IPv4.

Avec toutes ces informations en main, ouvrez un nouveau fichier /etc/wireguard/wg0.conf sur la machine Peer WireGuard en utilisant nano ou votre éditeur préféré :

sudo nano /etc/wireguard/wg0.conf

Ajoutez les lignes suivantes au fichier, en remplaçant les différentes données dans les sections surlignées au besoin :

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_peer_private_key_goes_here
Address = 10.8.0.2/24
Address = fd0d:86fa:c3bc::2/64

[Peer]
PublicKey = U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
AllowedIPs = 10.8.0.0/24, fd0d:86fa:c3bc::/64
Endpoint = 203.0.113.1:51820

Remarquez comment la première ligne Address utilise une adresse IPv4 provenant du sous-réseau 10.8.0.0/24 que vous avez choisi précédemment. Cette adresse IP peut être n'importe laquelle dans le sous-réseau tant qu'elle est différente de celle du serveur. Incrémenter les adresses de 1 à chaque fois que vous ajoutez un pair est généralement la façon la plus simple d'allouer les adresses IP.

De même, remarquez comment la deuxième ligne Address utilise une adresse IPv6 du sous-réseau que vous avez généré plus tôt, et incrémente l’adresse du serveur d’un. Encore une fois, n’importe quelle IP dans la plage est valide si vous décidez d’utiliser une adresse différente.

L'autre partie notable du fichier est la dernière ligne AllowedIPs. Ces deux plages IPv4 et IPv6 indiquent au pair d'envoyer le trafic sur le VPN uniquement si le système de destination possède une adresse IP dans l'une ou l'autre plage. En utilisant la directive AllowedIPs, vous pouvez restreindre le VPN sur le pair pour ne se connecter qu'à d'autres pairs et services sur le VPN, ou vous pouvez configurer ce paramètre pour acheminer tout le trafic via le VPN et utiliser le serveur WireGuard comme passerelle.

Si vous utilisez uniquement IPv4, omettez alors la plage fd0d:86fa:c3bc::/64 à la fin (y compris la , virgule). Inversement, si vous utilisez uniquement IPv6, incluez seulement le préfixe fd0d:86fa:c3bc::/64 et omettez la plage IPv4 10.8.0.0/24.

Dans les deux cas, si vous souhaitez envoyer tout le trafic de votre pair via le VPN et utiliser le serveur WireGuard comme passerelle pour tout le trafic, vous pouvez alors utiliser 0.0.0.0/0, qui représente l'ensemble de l'espace d'adresses IPv4, et ::/0 pour l'ensemble de l'espace d'adresses IPv6.

(Optionnel) Configurer un pair pour acheminer tout le trafic via le tunnel

Si vous avez choisi de router tout le trafic du pair via le tunnel en utilisant les routes 0.0.0.0/0 ou ::/0 et que le pair est un système distant, vous devrez alors compléter les étapes de cette section. Si votre pair est un système local, il est préférable de sauter cette section.

Pour les pairs distants auxquels vous accédez via SSH ou un autre protocole en utilisant une adresse IP publique, vous devrez ajouter certaines règles supplémentaires au fichier wg0.conf du pair. Ces règles permettront de vous assurer que vous pouvez toujours vous connecter au système depuis l'extérieur du tunnel lorsqu'il est connecté. Sinon, lorsque le tunnel est établi, tout le trafic qui serait normalement géré sur l'interface réseau publique ne sera pas correctement acheminé pour contourner l'interface du tunnel wg0, ce qui rendra le système distant inaccessible.

Tout d’abord, vous devrez déterminer l’adresse IP que le système utilise comme passerelle par défaut. Exécutez la commande suivante ip route :

ip route list table main default

Vous recevrez une sortie comme suit :

default via 203.0.113.1 dev eth0 proto static

Notez l'adresse IP mise en évidence du passerelle 203.0.113.1 pour utilisation ultérieure, ainsi que le périphérique eth0. Le nom de votre périphérique peut être différent. Le cas échéant, remplacez-le à la place de eth0 dans les commandes suivantes.

Ensuite, trouvez l'adresse IP publique du système en examinant l'appareil avec la commande ip address show :

ip -brief address show eth0

Vous recevrez un résultat comme le suivant :

eth0             UP             203.0.113.5/20 10.20.30.40/16 2604:a880:400:d1::3d3:6001/64 fe80::68d5:beff:feff:974c/64

Dans cet exemple de sortie, l'adresse IP mise en évidence 203.0.113.5 (sans le /20 final) est l'adresse publique qui est assignée au périphérique eth0 que vous devrez ajouter à la configuration de WireGuard.

Ouvrez maintenant le fichier /etc/wireguard/wg0.conf du pair WireGuard avec nano ou votre éditeur préféré.

sudo nano /etc/wireguard/wg0.conf

Avant la ligne [Peer], ajoutez les 4 lignes suivantes :

PostUp = ip rule add table 200 from 203.0.113.5
PostUp = ip route add table 200 default via 203.0.113.1
PreDown = ip rule delete table 200 from 203.0.113.5
PreDown = ip route delete table 200 default via 203.0.113.1

[Peer]
. . .

Ces lignes créeront une règle de routage personnalisée et ajouteront une route personnalisée pour garantir que le trafic public vers le système utilise la passerelle par défaut.

• PostUp=ip rule add table 200 from 203.0.113.5 - Cette commande crée une règle qui vérifie toutes les entrées de routage dans la table numéro 200 lorsque l'IP correspond à l'adresse publique 203.0.113.5 du système.
• PostUp=ip route add table 200 default via 203.0.113.1 - Cette commande garantit que tout le trafic traité par la table 200 utilisera la passerelle 203.0.113.1 pour le routage, au lieu de l'interface WireGuard.

Les lignes PreDown suppriment la règle et la route personnalisées lorsque le tunnel est arrêté.

Si vous redirigez tout le trafic du pair via le VPN, assurez-vous d’avoir configuré les bonnes règles sysctl et iptables sur le serveur WireGuard dans Ajuster la configuration réseau du serveur WireGuard et Configurer le pare-feu du serveur WireGuard.

(Optionnel) Configuration des résolveurs DNS du pair WireGuard

Si vous utilisez le serveur WireGuard comme passerelle VPN pour tout le trafic de vos pairs, vous devrez ajouter une ligne à la section [Interface] qui spécifie les résolveurs DNS. Si vous n’ajoutez pas ce paramètre, vos requêtes DNS pourraient ne pas être sécurisées par le VPN, ou elles pourraient être visibles par votre fournisseur d’accès Internet ou d’autres tiers.

Si vous utilisez WireGuard uniquement pour accéder aux ressources sur le réseau VPN ou dans une configuration peer-to-peer, vous pouvez passer cette section.

Pour ajouter des résolveurs DNS à la configuration de votre pair, commencez par déterminer quels serveurs DNS votre serveur WireGuard utilise. Exécutez la commande suivante sur le serveur WireGuard, en remplaçant le nom de votre périphérique ethernet à la place de eth0 s'il est différent de cet exemple :

resolvectl dns eth0

Vous devriez recevoir un résultat comme le suivant :

Link 2 (eth0): 67.207.67.2 67.207.67.3 2001:4860:4860::8844 2001:4860:4860::8888

Les adresses IP qui sont affichées sont les résolveurs DNS que le serveur utilise. Vous pouvez choisir d’en utiliser un ou tous, ou seulement IPv4 ou IPv6 selon vos besoins. Notez les résolveurs que vous allez utiliser.

Ensuite, vous devrez ajouter vos résolveurs choisis au fichier de configuration du Pair WireGuard. De retour sur le Pair WireGuard, ouvrez le fichier /etc/wireguard/wg0.conf en utilisant nano ou votre éditeur préféré :

sudo nano /etc/wireguard/wg0.conf

Avant la ligne [Peer], ajoutez ce qui suit :

DNS = 67.207.67.2 2001:4860:4860::8844

[Peer]
. . .

Encore une fois, selon vos préférences ou vos exigences pour IPv4 et IPv6, vous pouvez modifier la liste en fonction de vos besoins.

Global: 67.207.67.2 67.207.67.3
. . .

Avec tous ces paramètres de résolveur DNS en place, vous êtes maintenant prêt à ajouter la clé publique du pair au serveur, puis à démarrer le tunnel WireGuard sur le pair.

Étape 8 — Ajouter la clé publique du pair au serveur WireGuard

Avant de connecter le pair au serveur, il est important d'ajouter la clé publique du pair au serveur WireGuard. Cette étape garantit que vous pourrez vous connecter et acheminer le trafic via le VPN. Sans cette étape, le serveur WireGuard n'autorisera pas le pair à envoyer ou recevoir du trafic via le tunnel.

Assurez-vous d’avoir une copie de la clé publique encodée en base64 pour le pair WireGuard en exécutant :

sudo cat /etc/wireguard/public.key

PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=

Connectez-vous maintenant au serveur WireGuard et exécutez la commande suivante :

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,fd0d:86fa:c3bc::2

Notez que la partie allowed-ips de la commande prend une liste d'adresses IPv4 et IPv6 séparées par des virgules. Vous pouvez spécifier des adresses IP individuelles si vous souhaitez restreindre l'adresse IP qu'un pair peut s'attribuer, ou une plage comme dans l'exemple si vos pairs peuvent utiliser n'importe quelle adresse IP de la plage VPN. Notez également qu'aucun pair ne peut avoir la même configuration allowed-ips.

Si vous souhaitez mettre à jour les allowed-ips pour un pair existant, vous pouvez exécuter à nouveau la même commande, mais en modifiant les adresses IP. Plusieurs adresses IP sont prises en charge. Par exemple, pour modifier le pair WireGuard que vous venez d’ajouter afin d’ajouter une adresse IP comme 10.8.0.100 aux adresses IP existantes 10.8.0.2 et fd0d:86fa:c3bc::2, vous exécuteriez la commande suivante :

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,10.8.0.100,fd0d:86fa:c3bc::2

Une fois que vous avez exécuté la commande pour ajouter le pair, vérifiez l'état du tunnel sur le serveur en utilisant la commande wg :

sudo wg

interface: wg0
 public key: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 private key: (hidden)
 listening port: 51820

peer: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 allowed ips: 10.8.0.2/32, fd0d:86fa:c3bc::/128

Remarquez comment la ligne peer affiche la clé publique du pair WireGuard, ainsi que les adresses IP, ou plages d'adresses, qu'il est autorisé à utiliser pour s'attribuer une IP.

Maintenant que vous avez défini les paramètres de connexion du pair sur le serveur, l'étape suivante consiste à démarrer le tunnel sur le pair.

Étape 9 — Connexion du pair WireGuard au tunnel

Maintenant que votre serveur et votre pair sont tous deux configurés pour prendre en charge votre choix d’IPv4, d’IPv6, de transfert de paquets et de résolution DNS, il est temps de connecter le pair au tunnel VPN.

Puisque vous ne voudrez peut-être activer le VPN que pour certains cas d'utilisation, nous allons utiliser la commande wg-quick pour établir la connexion manuellement. Si vous souhaitez automatiser le démarrage du tunnel comme vous l'avez fait sur le serveur, suivez ces étapes dans la section Démarrage du serveur WireGuard au lieu d'utiliser la commande wg-quick.

Au cas où vous achemineriez tout le trafic via le VPN et auriez configuré le transfert DNS, vous devrez installer l’utilitaire resolvconf sur le Peer WireGuard avant de démarrer le tunnel. Exécutez la commande suivante pour configurer cela :

sudo apt install resolvconf

Pour démarrer le tunnel, exécutez ce qui suit sur le pair WireGuard :

sudo wg-quick up wg0

Vous recevrez un résultat comme le suivant :

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x

Remarquez les adresses IPv4 et IPv6 mises en évidence que vous avez attribuées au pair.

Si vous définissez les AllowedIPs sur le pair à 0.0.0.0/0 et ::/0 (ou pour utiliser des plages autres que celles que vous avez choisies pour le VPN), alors votre sortie ressemblera à ce qui suit :

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

Dans cet exemple, remarquez les routes en surbrillance que la commande a ajoutées, qui correspondent aux AllowedIPs dans la configuration du pair.

Vous pouvez vérifier l’état du tunnel sur le pair en utilisant la commande wg :

sudo wg

interface: wg0
 public key: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 private key: (hidden)
 listening port: 49338
 fwmark: 0xca6c

peer: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 endpoint: 203.0.113.1:51820
 allowed ips: 10.8.0.0/24, fd0d:86fa:c3bc::/64
 latest handshake: 1 second ago
 transfer: 6.50 KiB received, 15.41 KiB sent

Vous pouvez également vérifier à nouveau le statut sur le serveur, et vous recevrez un résultat similaire.

Vérifiez que votre pair utilise le VPN en utilisant les commandes ip route et ip -6 route. Si vous utilisez le VPN comme passerelle pour tout votre trafic Internet, vérifiez quelle interface sera utilisée pour le trafic destiné aux résolveurs DNS de CloudFlare 1.1.1.1 et 2606:4700:4700::1111.

ip route get 1.1.1.1

1.1.1.1 dev wg0 table 51820 src 10.8.0.2 uid 1000
   cache

Remarquez que le périphérique wg0 est utilisé et que l'adresse IPv4 10.8.0.2 vous a été attribuée pour le pair. De même, si vous utilisez IPv6, exécutez ce qui suit :

ip -6 route get 2606:4700:4700::1111

2606:4700:4700::1111 from :: dev wg0 table 51820 src fd0d:86fa:c3bc::2 metric 1024 pref medium

Remarquez encore l'interface wg0, ainsi que l'adresse IPv6 fd0d:86fa:c3bc::2 que vous avez attribuée au pair.

Si votre pair a un navigateur installé, vous pouvez également visiter ipleak.net et ipv6-test.com pour confirmer que votre pair achemine son trafic via le VPN.

Une fois que vous êtes prêt à vous déconnecter du VPN sur le pair, utilisez la commande wg-quick :

sudo wg-quick down wg0

Vous recevrez une sortie semblable à ce qui suit indiquant que le tunnel VPN est fermé :

[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f

Si vous définissez les AllowedIPs sur le pair à 0.0.0.0/0 et ::/0 (ou pour utiliser des plages autres que celles que vous avez choisies pour le VPN), alors votre sortie ressemblera à ce qui suit :

[#] ip rule delete table 200 from 203.0.113.5
[#] ip route delete table 200 default via 203.0.113.1
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip -6 rule delete table 51820
[#] ip -6 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
[#] iptables-restore -n
[#] ip6tables-restore -n

Pour se reconnecter au VPN, exécutez à nouveau la commande wg-quick up wg0 sur le pair. Si vous souhaitez supprimer complètement la configuration d’un pair du serveur WireGuard, vous pouvez exécuter la commande suivante, en vous assurant de remplacer par la clé publique correcte du pair que vous souhaitez supprimer :

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= remove

En général, vous n'aurez besoin de supprimer une configuration de pair que si le pair n'existe plus ou si ses clés de chiffrement sont compromises ou modifiées. Sinon, il est préférable de laisser la configuration en place afin que le pair puisse se reconnecter au VPN sans que vous ayez à ajouter sa clé et les allowed-ips à chaque fois.

Gestion et rotation des clés WireGuard

WireGuard repose sur des paires de clés publiques et privées statiques pour l'authentification et le chiffrement. Cette conception réduit considérablement la complexité de la configuration, mais elle place également la responsabilité de la gestion des clés entièrement sur l'administrateur. Pour les déploiements VPN à long terme, les infrastructures partagées ou les environnements avec plusieurs pairs, une gestion soigneuse des clés est essentielle pour maintenir la sécurité et la stabilité opérationnelle.

Comprendre les types de clés WireGuard

Chaque pair WireGuard utilise deux catégories de clés cryptographiques.

• Clés privées à long terme : Une clé privée identifie de manière unique un pair et doit rester secrète en tout temps. Cette clé est utilisée lors des échanges chiffrés pour authentifier le pair et générer des clés de session à courte durée. Si une clé privée est exposée, tout système possédant cette clé peut usurper l'identité du pair.

• Clés publiques à long terme : Une clé publique est dérivée d'une clé privée et est partagée avec d'autres pairs. Sur le hub central, les clés publiques déterminent quels pairs sont autorisés à communiquer et quelles adresses IP ils sont autorisés à utiliser.

En plus de ces clés à long terme, WireGuard génère automatiquement des clés de session éphémères lors des échanges chiffrés. Ces clés de session sont régulièrement renouvelées et assurent la confidentialité persistante sans intervention de l’administrateur.

Pratiques recommandées de gestion des clés

Les pratiques suivantes aident à réduire les risques et à simplifier les opérations courantes :

• Attribuez une paire de clés unique à chaque pair : Chaque appareil devrait avoir sa propre paire de clés privée et publique. L'utilisation de clés uniques permet de révoquer l'accès pour un seul appareil sans affecter les autres. Réutiliser des clés sur plusieurs systèmes augmente l'impact en cas de compromission et complique l'audit.

• Limiter l'accès au matériel de clé privée : Les fichiers de clé privée ne devraient être lisibles que par l'utilisateur root. Sur les systèmes Linux, cela signifie généralement définir les permissions à 600 en utilisant une commande comme chmod 600 /etc/wireguard/private.key. Restreindre l'accès aux fichiers aide à prévenir les divulgations accidentelles via les sauvegardes, les journaux ou les utilisateurs non privilégiés.

• Maintenez un inventaire explicite des pairs : Conservez un registre qui associe la clé publique de chaque pair à son nom d'appareil, aux adresses IPv4 et IPv6 attribuées, ainsi qu'à l'utilisation prévue. Cette documentation devient de plus en plus importante à mesure que le nombre de pairs augmente et facilite le dépannage, les audits et l'entretien courant.

• Supprimez rapidement les pairs inutilisés ou inactifs : lorsqu'un appareil est mis hors service ou n'a plus besoin d'accéder au VPN, retirez sa clé publique de la configuration centrale des pairs. Laisser des clés inutilisées en place augmente la surface d'attaque et rend les examens futurs plus difficiles.

Situations nécessitant la rotation des clés

La rotation des clés devrait être effectuée dans plusieurs scénarios courants :

• Exposition suspectée ou confirmée d’une clé : Si une clé privée a pu être copiée, divulguée ou accédée par une personne non autorisée, elle doit être remplacée immédiatement pour prévenir toute usurpation d’identité.

• Appareils perdus ou volés : Lorsque qu’un appareil est perdu ou volé, la rotation de ses clés garantit qu’il ne pourra plus se connecter au VPN, même si la configuration originale est récupérée.

• Exigences de sécurité organisationnelle : Certains environnements nécessitent une rotation périodique des clés pour respecter les politiques internes ou les normes de conformité, même si aucune compromission n’est suspectée.

• Changements dans la propriété ou le rôle de l’appareil : Lorsqu’un appareil est réaffecté à un autre utilisateur ou à un autre objectif, faire tourner ses clés empêche un accès continu non intentionnel.

Changer en toute sécurité les clés d’un pair

WireGuard associe les adresses IP internes à des clés publiques spécifiques à l'aide d'une table de routage cryptographique. En raison de cette conception, la même adresse IP interne ne peut pas être attribuée en toute sécurité à deux clés publiques en même temps. La rotation des clés implique donc généralement une brève interruption de la connectivité pendant la mise à jour de la configuration.

Pour faire tourner les clés d’un pair, suivez ce processus :

1. Générer une nouvelle paire de clés privée et publique sur le pair.
2. Mettez à jour la configuration du pair central pour remplacer l’ancienne clé publique par la nouvelle tout en conservant les mêmes valeurs AllowedIPs. Ne redémarrez pas encore l’interface.
3. Mettez à jour le fichier de configuration du pair pour utiliser la nouvelle clé privée.
4. Appliquez la configuration mise à jour sur le pair central, par exemple en rechargeant le service WireGuard ou en utilisant wg syncconf. À ce stade, le pair perdra temporairement la connectivité.
5. Redémarrez l’interface WireGuard sur le pair afin qu’elle commence à utiliser la nouvelle clé privée.
6. Vérifiez qu'une nouvelle poignée de main se termine et que le trafic circule correctement.
7. Supprimez toutes les références restantes à l’ancienne clé si elles existent encore.

Cette approche basée sur le remplacement reflète la manière dont WireGuard applique le routage cryptographique et évite les configurations ambiguës ou conflictuelles.

Rotation des clés sur le pair central

La rotation de la clé privée du pair central affecte tous les pairs connectés. La configuration de chaque pair doit être mise à jour avec la nouvelle clé publique avant que la connectivité puisse être rétablie.

Comme ce changement affecte tous les pairs simultanément, la rotation des clés des pairs centraux doit être planifiée avec soin et effectuée pendant une période de maintenance. En pratique, les clés centrales sont tournées moins fréquemment que les clés des pairs.

Gestion des clés prépartagées (facultatif)

En plus des paires de clés publiques et privées, WireGuard prend en charge une clé prépartagée (PSK) optionnelle pour chaque pair. Une PSK ajoute une couche supplémentaire de chiffrement symétrique par-dessus la cryptographie existante de WireGuard.

Les clés pré-partagées sont couramment utilisées dans les environnements à haute sécurité comme mesure de protection contre les avancées cryptographiques futures. Si le trafic chiffré est enregistré aujourd'hui et que l'algorithme de clé publique sous-jacent est compromis à l'avenir, une clé pré-partagée empêcherait toujours le déchiffrement des sessions passées.

Si des PSK sont utilisés, ils doivent être traités comme des secrets sensibles et être renouvelés périodiquement. Le renouvellement d'un PSK suit le même schéma opérationnel que le renouvellement des clés des pairs et doit être coordonné des deux côtés de la connexion.

Choisir une fréquence de rotation

WireGuard n'applique pas de calendrier fixe pour la rotation des clés. Les intervalles de rotation appropriés dépendent de l'environnement.

• Les déploiements personnels ou de courte durée peuvent ne pas nécessiter de rotation planifiée.
• Les environnements partagés ou de production font généralement tourner les clés tous les 6 à 12 mois.
• Les environnements à haute sécurité peuvent nécessiter une rotation plus fréquente selon la politique.

La rotation régulière réduit le risque lié aux informations d'identification à longue durée de vie et aligne les déploiements de WireGuard sur les pratiques de sécurité courantes.

WireGuard vs OpenVPN : différences pratiques

WireGuard et OpenVPN sont deux technologies VPN largement utilisées, mais elles adoptent des approches très différentes en matière de chiffrement, de configuration et de comportement réseau. Comprendre ces différences aide les développeurs à choisir la solution qui correspond le mieux à leurs contraintes opérationnelles.

Configuration et modèle opérationnel

WireGuard utilise un modèle de configuration statique basé sur des paires de clés publiques et privées. Tous les pairs sont définis de manière explicite, et le comportement de routage est contrôlé par des valeurs de configuration fixes. Il n'y a pas de canal de contrôle, d'autorité de certification ou de négociation dynamique des paramètres.

OpenVPN repose sur TLS et les certificats X.509. Il utilise un canal de contrôle pour authentifier les clients, négocier les paramètres de chiffrement et gérer les sessions. Ce modèle offre de la flexibilité mais augmente la complexité de configuration et d'exploitation.

En pratique, les configurations WireGuard sont plus courtes, plus faciles à vérifier et moins sujettes à des erreurs de configuration subtiles. Les configurations OpenVPN offrent plus de contrôle, mais nécessitent une gestion attentive pour rester sécurisées et cohérentes.

Cryptographie et conception de la sécurité

WireGuard utilise un ensemble fixe de méthodes cryptographiques modernes. Ces choix ne sont pas configurables. Cette conception élimine les attaques de rétrogradation cryptographique et supprime le besoin de sélectionner des suites de chiffrement.

OpenVPN prend en charge une large gamme d'algorithmes de chiffrement et de méthodes d'authentification. Bien que cette flexibilité permette la compatibilité avec les systèmes hérités, elle augmente également le risque de configurations faibles ou incohérentes.

Les deux solutions prennent en charge le Perfect Forward Secrecy. WireGuard effectue automatiquement la rotation des clés grâce à son mécanisme de négociation, tandis qu'OpenVPN repose sur le comportement des sessions TLS.

Caractéristiques de performance

WireGuard est conçu pour des performances élevées et une faible latence. Il fonctionne dans le noyau Linux et possède une petite base de code, ce qui réduit la surcharge et les changements de contexte. Dans la plupart des environnements, WireGuard offre un débit plus élevé et une latence plus constante avec un minimum de réglages.

Historiquement, OpenVPN fonctionne en espace utilisateur et entraîne un surcoût supplémentaire dû aux changements de contexte et à la gestion des protocoles. Les versions modernes d'OpenVPN prennent en charge le déchargement du canal de données du noyau (Kernel Data Channel Offload, DCO), ce qui améliore considérablement les performances, mais cette fonctionnalité n'est pas toujours activée ou disponible dans les déploiements par défaut.

Même avec DCO, WireGuard atteint généralement de bonnes performances avec moins de variables de configuration.

Itinérance réseau et traversée de pare-feu

WireGuard gère les changements de réseau de manière fluide. Si l'adresse IP d'un pair change, par exemple lors du passage du WiFi aux réseaux mobiles, le tunnel continue de fonctionner sans renégociation.

Cependant, WireGuard fonctionne exclusivement sur UDP. Bien que l’UDP soit efficace, il est parfois bloqué sur des réseaux WiFi publics restrictifs, des pare-feu d’entreprise ou des réseaux institutionnels. WireGuard n’a pas de solution de secours native lorsque le trafic UDP est bloqué.

OpenVPN prend en charge à la fois UDP et TCP. Lorsque UDP n'est pas disponible, OpenVPN peut être configuré pour fonctionner sur le port TCP 443, ce qui fait en sorte que le trafic VPN ressemble à un trafic HTTPS ordinaire. Cette capacité rend OpenVPN plus fiable dans des environnements avec des règles de pare-feu strictes ou de la censure.

Pour les utilisateurs opérant derrière des réseaux restrictifs, la prise en charge de TCP est souvent le facteur décisif dans le choix d’OpenVPN plutôt que de WireGuard.

Portée des fonctionnalités et extensibilité

OpenVPN comprend des fonctionnalités que WireGuard choisit délibérément de ne pas fournir. Celles-ci incluent l'authentification basée sur l'utilisateur, l'attribution d'adresses dynamiques et l'intégration avec des systèmes d'identité externes.

WireGuard se concentre exclusivement sur le tunneling sécurisé. Les flux d’authentification, le contrôle d’accès et la configuration dynamique doivent être gérés en dehors du protocole.

Cela fait d'OpenVPN un meilleur choix pour les environnements nécessitant une authentification complexe ou une gestion centralisée des utilisateurs, tandis que WireGuard est mieux adapté aux VPN au niveau de l'infrastructure et à l'accès basé sur les pairs.

Comparaison Résumée

Choisir entre WireGuard et OpenVPN

WireGuard convient parfaitement aux VPN d'infrastructure, aux tunnels site à site, aux clients mobiles et aux environnements où la simplicité, la performance et la prévisibilité sont des priorités.

OpenVPN demeure un choix solide pour les environnements d'entreprise qui nécessitent un tunnel basé sur TCP, une authentification avancée ou un fonctionnement fiable derrière des pare-feu restrictifs.

Dans plusieurs déploiements modernes, WireGuard remplace OpenVPN non pas parce qu'il offre plus de fonctionnalités, mais parce qu'il en offre moins avec un comportement plus clair.

Ajustement et optimisation des performances

WireGuard fonctionne bien avec ses paramètres par défaut, mais les conditions réelles du réseau peuvent affecter la fiabilité et le débit. Des facteurs tels que la taille des paquets, la portée du routage, le comportement du NAT et la résolution DNS influencent tous la manière dont le tunnel se comporte lors d'une utilisation soutenue ou intermittente.

Examinons les domaines d’ajustement les plus courants et quand il est approprié de les modifier.

Sélection de la MTU et fragmentation des paquets

L'Unité de Transmission Maximale (MTU) définit la taille maximale d'un paquet pouvant être transmis sans fragmentation. WireGuard chiffre et encapsule les paquets, ce qui réduit la MTU effective par rapport à une interface réseau physique.

Par défaut, WireGuard utilise une MTU de 1420. Cette valeur prend en compte la surcharge combinée des en-têtes IPv6, UDP et de l'encapsulation WireGuard, et fonctionne bien pour la plupart des réseaux Ethernet. Certains environnements nécessitent une MTU plus petite. C'est courant sur les réseaux mobiles, les connexions PPPoE et les plateformes cloud avec des couches d'encapsulation supplémentaires. Lorsque la MTU est trop grande, les paquets peuvent être abandonnés ou fragmentés. Cela entraîne souvent des connexions qui fonctionnent pour de petites requêtes mais qui se bloquent ou échouent pour des transferts plus volumineux. Si ces symptômes apparaissent, il est recommandé de réduire la MTU progressivement. Des valeurs telles que 1360, ou dans des environnements plus contraints 1280 qui est la MTU minimale pour IPv6, résolvent souvent ces problèmes avec un impact minimal sur le débit.

La MTU devrait être définie explicitement dans la section [Interface] du fichier de configuration afin d’assurer un comportement cohérent lors des redémarrages.

Portée et impact de AllowedIPs

La directive AllowedIPs influence à la fois le comportement du routage et les performances. Des plages d'adresses étendues font en sorte que plus de trafic traverse le tunnel, ce qui augmente la charge de chiffrement et la charge sur le serveur. Utiliser des valeurs AllowedIPs plus restreintes limite le tunnel uniquement au trafic qui nécessite une protection. Cela réduit l'utilisation du processeur et évite l'encapsulation inutile.

Lorsque 0.0.0.0/0 ou ::/0 est configuré, tout le trafic est acheminé via le VPN. Cette configuration est appropriée lorsque la confidentialité, le contrôle centralisé de la sortie ou les réseaux non fiables sont une préoccupation, mais elle augmente la latence et l'utilisation des ressources pour le trafic Internet général.

L'optimisation des performances implique souvent de réduire les AllowedIPs lorsque c'est possible et d'éviter le routage en tunnel complet sauf si cela est nécessaire.

Traversée NAT et stabilité de la connexion (PersistentKeepalive)

WireGuard reste volontairement silencieux lorsqu'aucune donnée n'est transmise. Par défaut, il n'envoie pas de paquets keepalive périodiques. Dans des environnements utilisant le NAT, comme les routeurs domestiques, les réseaux mobiles ou de nombreux réseaux cloud, ce silence peut amener le dispositif NAT à fermer la correspondance de connexion. Lorsque cela se produit, le trafic entrant du serveur est bloqué jusqu'à ce que le pair renvoie du trafic. Ce comportement est souvent perçu comme un retard, des connexions retardées ou des échecs intermittents.

Pour éviter cela, WireGuard fournit le paramètre PersistentKeepalive. Cette option peut être ajoutée à la section [Peer] de la configuration du pair. Elle force le pair à envoyer un petit paquet de maintien de connexion à intervalles réguliers pour garder le mappage NAT ouvert. Une valeur de 25 secondes est couramment utilisée et fonctionne bien avec la plupart des dispositifs NAT. Si une connexion fonctionne au départ mais échoue après être restée inactive, activer PersistentKeepalive=25 est la solution principale et recommandée.

Résolution DNS et comportement du tunnel

La configuration DNS a un impact significatif sur la performance perçue du VPN. Lorsque les résolveurs DNS ne sont pas correctement acheminés via le tunnel, les applications peuvent sembler lentes ou peu fiables même si le tunnel lui-même fonctionne correctement.

Dans les configurations de passerelle, les requêtes DNS doivent être envoyées via le VPN pour assurer un routage cohérent et éviter les fuites. Cela nécessite de définir explicitement les résolveurs DNS dans la configuration du pair. Lorsque le DNS est mal configuré, les symptômes courants incluent des pages qui se chargent lentement, une connectivité incohérente ou un trafic acheminé en dehors du VPN malgré un tunnel actif.

Sélectionner des résolveurs accessibles via le tunnel et qui répondent rapidement améliore à la fois la fiabilité et l’expérience utilisateur.

Différences de performance entre IPv4 et IPv6

Dans les environnements à double pile, IPv4 et IPv6 peuvent se comporter différemment. Les chemins IPv6 peuvent avoir des contraintes MTU différentes, des politiques de routage ou un comportement de pare-feu distinct.

Tester les deux protocoles indépendamment aide à identifier les problèmes spécifiques à chaque protocole. Des outils tels que ping, tracepath et ip route get sont utiles pour valider le routage et le comportement de la MTU pour chaque famille d'adresses.

Si les performances IPv6 semblent incohérentes, vérifiez que le trafic ICMPv6 est autorisé. ICMPv6 est nécessaire pour la découverte du MTU du chemin, et le bloquer peut entraîner des blocages de connexion sur des paquets plus volumineux.

CPU et surcharge de chiffrement

WireGuard utilise une cryptographie moderne qui est efficace sur la plupart des systèmes. Cependant, le chiffrement consomme toujours des ressources CPU.

Sur de petites machines virtuelles, des routeurs intégrés ou des systèmes sans accélération matérielle, les configurations à tunnel complet peuvent saturer le processeur en cas de charge soutenue.

Surveiller l'utilisation du processeur lors de périodes de trafic élevé permet de déterminer si les problèmes de performance sont causés par la surcharge liée au chiffrement plutôt que par la configuration du réseau. Dans de tels cas, il peut être nécessaire de réduire le trafic encapsulé ou de mettre à niveau l'instance du serveur.

Validation des changements de performance

L'optimisation des performances devrait se faire de manière progressive. Après chaque modification, la connectivité et la stabilité doivent être vérifiées avant d'appliquer des ajustements supplémentaires.

Les étapes de validation utiles incluent la vérification de la stabilité de l'établissement de la connexion avec wg, la mesure de la latence et du débit avant et après les changements, et la confirmation du comportement du routage avec ip route et ip -6 route. Cette approche minimise les risques et simplifie le dépannage.

FAQ

1. Qu'est-ce que WireGuard et comment fonctionne-t-il sur Ubuntu ?

WireGuard est une technologie VPN moderne conçue pour être beaucoup plus rapide et facile à configurer que les options plus anciennes comme OpenVPN ou IPsec. Vous pouvez le voir comme un tunnel sécurisé qui connecte directement vos appareils. Contrairement aux VPN plus anciens, qui sont lourds et complexes, WireGuard est extrêmement léger. Sur Ubuntu, il fonctionne en s'exécutant directement dans le noyau Linux, le « moteur » central du système d'exploitation. Comme il s'exécute profondément dans le système plutôt qu'en tant qu'application séparée, il consomme très peu de batterie et traite les données de manière incroyablement rapide.

Pour établir une connexion, WireGuard utilise une méthode très similaire à SSH. Il génère une paire de « clés » pour chaque appareil : une clé privée (qui reste secrète sur l’appareil) et une clé publique (que vous partagez avec les autres appareils avec lesquels vous souhaitez vous connecter). La connexion ne se fait que si les clés correspondent parfaitement, ce qui rend la poignée de main rapide et sécurisée.

2. WireGuard est-il plus sécuritaire qu'OpenVPN ?

Pour la plupart des utilisateurs, WireGuard est considéré comme plus sûr en raison de sa simplicité et de sa conception moderne. La raison principale est la taille de son code. WireGuard est construit avec seulement environ 4 000 lignes de code, alors qu’OpenVPN en compte plus de 100 000. Cette énorme différence signifie qu’il est beaucoup plus facile pour les experts en sécurité de lire le code de WireGuard et de trouver des vulnérabilités (bugs) avant que des acteurs malveillants ne le fassent.

WireGuard vous oblige également à utiliser les normes de chiffrement les plus récentes et les plus puissantes disponibles aujourd’hui. Les anciens VPN permettent l’« agilité cryptographique », ce qui signifie qu’ils peuvent rétrograder vers des méthodes de chiffrement plus faibles pour prendre en charge les appareils anciens. WireGuard supprime ce choix, empêchant les attaquants de tromper votre VPN pour utiliser un verrouillage plus faible. De plus, WireGuard est discret par défaut; si un appareil non autorisé envoie un paquet à votre serveur, WireGuard ne répond tout simplement pas. Cela rend votre serveur invisible aux pirates qui cherchent des ports ouverts.

3. Puis-je configurer WireGuard sur Ubuntu sans Docker ?

Oui, vous pouvez facilement le configurer directement sur le système sans utiliser de conteneurs Docker. En fait, l'exécuter directement est souvent la méthode préférée sur Ubuntu, car le logiciel est inclus dans les dépôts logiciels standard d'Ubuntu. Il vous suffit généralement d'exécuter les commandes d'installation standard ci-dessous, qui récupéreront le logiciel nécessaire directement depuis la source officielle d'Ubuntu.

sudo apt update
sudo apt install wireguard

4. Comment puis-je ajouter plusieurs clients WireGuard (pairs) ?

WireGuard utilise un concept de pair-à-pair, ce qui signifie que chaque appareil auquel vous vous connectez est considéré comme un « pair ». Pour ajouter plusieurs appareils, comme un ordinateur portable, un smartphone et une tablette, il vous suffit de modifier le fichier de configuration du serveur (généralement situé à /etc/wireguard/wg0.conf).

Pour chaque nouvel appareil, vous ajoutez un nouveau bloc de texte intitulé [Peer]. Dans ce bloc, vous devez coller la clé publique de cet appareil spécifique et lui attribuer une adresse IP interne unique (comme 10.0.0.2 pour le premier appareil, 10.0.0.3 pour le deuxième, et ainsi de suite). Il est crucial que ces adresses IP internes ne se chevauchent pas.

Voici un exemple simple de bloc de configuration :

[Interface]
# Server settings...
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <Server_Private_Key>

[Peer]
# Client 1 (Laptop)
PublicKey = <Laptop_Public_Key>
AllowedIPs = 10.0.0.2/32

[Peer]
# Client 2 (Phone)
PublicKey = <Phone_Public_Key>
AllowedIPs = 10.0.0.3/32

5. Quels ports WireGuard utilise-t-il ?

WireGuard utilise par défaut le port UDP 51820. Il repose strictement sur le protocole UDP car il est plus rapide pour le transfert de données que TCP. TCP nécessite une confirmation pour chaque paquet de données envoyé, ce qui peut ralentir considérablement une connexion VPN. UDP envoie simplement les données sans attendre de reçu, ce qui est parfait pour la rapidité de WireGuard. Lors de la configuration du pare-feu Ubuntu (UFW), vous devez spécifiquement autoriser le trafic sur ce port UDP, sinon les requêtes de connexion seront bloquées avant d'atteindre le logiciel VPN.

6. Comment dépanner les problèmes de connexion WireGuard ?

Le dépannage de WireGuard est généralement simple, car il y a moins de composants en mouvement. Si vous ne pouvez pas vous connecter, vous devriez suivre cette séquence spécifique de vérifications :

Tout d'abord, vérifiez le statut de la poignée de main en exécutant sudo wg show sur votre serveur. Si la connexion est saine, vous verrez une ligne indiquant dernière poignée de main suivie d'une heure (par exemple, « il y a 1 minute »). Si cette ligne est absente, les appareils ne communiquent pas du tout entre eux. Cela est presque toujours causé par un pare-feu bloquant le port UDP ou une incompatibilité des clés publiques/privées.

Deuxièmement, si la poignée de main fonctionne mais que vous ne pouvez pas naviguer sur Internet, le problème est probablement lié au transfert IP. Vous devez vous assurer que votre serveur Ubuntu est autorisé à acheminer le trafic depuis le VPN vers Internet. Vous pouvez vérifier cela en consultant le fichier /etc/sysctl.conf et en vous assurant que la ligne net.ipv4.ip_forward=1 est active (non commentée).

7. WireGuard prend-il en charge IPv6 sur Ubuntu ?

Oui, WireGuard offre un excellent support pour IPv6. Il est très flexible et peut encapsuler (envelopper) différents types de trafic. Par exemple, vous pouvez accéder à un site Web uniquement IPv4 via une connexion IPv6, ou l'inverse. Pour activer cela, il vous suffit d'inclure des adresses IPv6 séparées par des virgules dans votre fichier de configuration aux côtés de vos adresses IPv4 standard. Vous devez les ajouter à la fois dans le champ Address (pour l’IP du serveur) et dans le champ AllowedIPs (pour les IP des clients).

8. Comment puis-je activer WireGuard pour qu'il démarre au démarrage ?

Pour vous assurer que votre VPN s'active automatiquement chaque fois que vous redémarrez votre serveur Ubuntu, vous devez utiliser systemd, qui est le gestionnaire de système pour Linux. Vous utilisez la commande enable pour indiquer au système de rechercher votre fichier de configuration spécifique (par exemple, wg0) et de le charger lors de la séquence de démarrage. Cela garantit que si votre serveur redémarre à cause d'une mise à jour, votre connexion VPN sera rétablie sans que vous ayez besoin de la démarrer manuellement.

sudo systemctl enable wg-quick@wg0

Conclusion

Dans ce tutoriel, vous configurez un VPN WireGuard sur un serveur Ubuntu et connectez un pair en utilisant à la fois IPv4 et IPv6. En cours de route, vous avez configuré des clés, attribué des adresses de tunnel et activé le serveur pour router le trafic de manière sécurisée, vous donnant un VPN fonctionnel qui est facile à comprendre et à utiliser.

Le guide couvrait également quelques détails pratiques importants une fois que le VPN est en usage régulier, tels que la gestion des clés au fil du temps, la prise en charge d’IPv6 et du réseau à double pile, ainsi que l’amélioration de la fiabilité et des performances grâce au réglage du MTU, aux keepalives et aux paramètres DNS. Avec ces éléments en place, vous devriez être bien préparé pour utiliser WireGuard dans des environnements réels ou l’adapter à mesure que vos besoins évoluent.

Si vous souhaitez en savoir plus sur WireGuard, y compris sur la façon de configurer des tunnels plus avancés ou d'utiliser WireGuard avec des conteneurs, consultez la documentation officielle de WireGuard. Pour d'autres tutoriels liés à la sécurisation de vos systèmes Ubuntu, consultez les articles suivants :

• Comment configurer un pare-feu avec UFW sur Ubuntu
• Notions de base d'UFW : Règles et commandes de pare-feu courantes pour la sécurité Linux
• VPC vs VPN : Lequel convient à vos besoins de réseau sécurisé ?
• Comment configurer et installer un serveur OpenVPN sur Ubuntu

Merci de apprendre avec la communauté Linux-Console.net.