Comment utiliser un fichier de configuration WireGuard

Ce que contient un fichier .conf, ligne par ligne

Toute configuration WireGuard a la même structure en deux parties. [Interface] décrit votre extrémité du tunnel ; [Peer] décrit la machine à laquelle vous vous connectez. Voici une configuration client complète, avec les secrets remplacés par des valeurs fictives :

[Interface]
PrivateKey = YOUR_PRIVATE_KEY_KEEP_THIS_SECRET
Address    = 10.7.0.4/32
DNS        = 10.7.0.1

[Peer]
PublicKey           = THE_SERVER_PUBLIC_KEY_FROM_YOUR_PROVIDER
Endpoint            = 198.51.100.10:51820
AllowedIPs          = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Le bloc [Interface] : votre côté

• PrivateKey — c'est votre identité sur le VPN. Quiconque la détient peut se faire passer pour vous. Elle fait 44 caractères base64 et se termine par = ; si la vôtre a une autre longueur, le fichier a été tronqué quelque part lors d'une copie.
• Address — l'IP que votre appareil possède à l'intérieur du tunnel, pas votre IP publique. Le /32 signifie « cette seule adresse », ce qui est normal pour un client.
• DNS — le résolveur utilisé tant que le tunnel est actif. Sans lui, votre appareil continue d'interroger l'ancien résolveur, ce qui révèle ce que vous cherchez et, souvent, ne permet de résoudre rien de l'autre côté.
• MTU — facultative, mais c'est la ligne la plus utile à connaître. Elle manque dans la plupart des fichiers parce que la valeur par défaut convient ; voyez le dépannage pour le cas où elle ne convient pas.

Le bloc [Peer] : le côté du serveur

• PublicKey — la clé publique du serveur. La vôtre n'apparaît jamais dans votre propre fichier ; c'est le serveur qui la détient.
• Endpoint — où envoyer les paquets, sous la forme host:port. WireGuard fonctionne uniquement en UDP, et 51820 est le port habituel, pas un port obligatoire.
• AllowedIPs — les destinations qui passent par le tunnel. 0.0.0.0/0, ::/0 signifie tout, ce qui est précisément le rôle d'un VPN de confidentialité. Une liste plus restreinte — par exemple uniquement le réseau interne de votre entreprise — n'envoie que cela dans le tunnel et laisse le reste sur votre connexion habituelle. Cette configuration s'appelle un split tunnel, et c'est un choix délibéré, pas un tunnel complet cassé.
• PersistentKeepalive — envoie un petit paquet toutes les 25 secondes pour que l'équipement NAT entre vous et le serveur garde le chemin de retour ouvert. Nécessaire dès que vous êtes derrière un NAT, ce qui est toujours le cas sur un téléphone ou une connexion domestique.

Windows : importer le tunnel

Windows dispose d'une application WireGuard officielle, et y importer un fichier constitue tout le travail.

1. Installez WireGuard depuis wireguard.com/install.
2. Cliquez sur Ajouter le tunnel en bas à gauche, ce qui ouvre un sélecteur de fichiers filtré sur Fichiers de configuration (*.zip, *.conf). Choisissez votre .conf : il apparaît dans la liste des tunnels, sous le nom du fichier.
3. Ou collez-le. La flèche à côté de Ajouter le tunnel propose Ajouter un tunnel vide…, qui vous donne une zone de texte — pratique quand la configuration est arrivée dans un message plutôt que sous forme de fichier. Une nouvelle clé privée y est déjà pré-remplie : supprimez cette ligne et collez votre propre configuration par-dessus.
4. Cliquez sur Activer. L'état passe à Activée et le panneau commence à compter les octets transférés. Ce compteur est votre vérification la plus rapide : s'il montre des données qui partent et rien qui revient, votre handshake n'aboutit pas.

Android et iPhone : scanner le QR code ou importer le fichier

Sur un téléphone, vous avez deux options, et le QR code existe précisément parce que taper une clé de 44 caractères sur un écran tactile est un calvaire.

Android

1. Installez WireGuard depuis le Play Store et appuyez sur le bouton +.
2. L'écran Créer un tunnel WireGuard propose Importer depuis un QR code, Importer depuis un fichier ou une archive et la création d'un tunnel de zéro. Choisissez l'option qui correspond à ce que vous avez reçu.
3. Donnez un nom au tunnel si on vous le demande, puis activez son interrupteur. Android demande une seule fois l'autorisation d'ajouter une configuration VPN — cette demande vient du système d'exploitation, pas de l'application.

iPhone et iPad

1. Installez WireGuard depuis l'App Store et appuyez sur Ajouter un tunnel.
2. Sous Ajouter un nouveau tunnel WireGuard, choisissez Créer à partir d'un code QR ou Créer depuis un fichier ou une archive. L'écran du scanner s'intitule Scanner le code QR ; après un scan réussi, il vous demande de nommer le tunnel.
3. Activez-le et autorisez la configuration VPN quand iOS le demande.

Créer un QR code à partir d'un fichier de configuration que vous avez déjà

Un QR code n'a pas à vous être fourni par votre fournisseur — ce n'est que votre fichier de configuration dessiné sous forme d'image, et vous pouvez le produire vous-même en une commande. L'application WireGuard le suggère d'ailleurs elle-même :

# prints the code straight into the terminal, ready to scan off the screen
qrencode -t ansiutf8 < wg0.conf

# or write it to an image file
qrencode -o wg0.png < wg0.conf

Sous Debian ou Ubuntu, qrencode s'installe avec apt install qrencode ; sous macOS, avec brew install qrencode.

macOS et Linux

macOS

Installez WireGuard depuis le Mac App Store. L'application Mac n'est pas l'application iPhone sur un plus grand écran : elle vit dans la barre des menus, et sa fenêtre s'ouvre depuis Gestion des tunnels. Cliquez sur Importer le(s) tunnel(s) à partir du fichier (la barre des menus propose la même chose sous Importer le(s) tunnel(s) à partir du fichier…), choisissez votre .conf, puis sélectionnez le tunnel et cliquez sur Activer. Le Mac n'a pas de scanner de QR code — les QR codes, c'est pour les téléphones —, alors utilisez le fichier lui-même, ou choisissez Ajouter un tunnel vide… et collez-y la configuration.

Si vous préférez travailler dans un terminal, brew install wireguard-tools vous donne les mêmes commandes wg-quick que sous Linux, décrites juste après.

Linux

1. Installez les outils. Sous Debian ou Ubuntu : sudo apt install wireguard. La plupart des distributions ont un paquet du même nom.
2. Placez le fichier là où wg-quick le cherche. C'est l'étape où l'on se trompe le plus, car le nom du fichier devient le nom de l'interface :

   sudo install -m 600 -o root -g root wg0.conf /etc/wireguard/wg0.conf

   Le 600 compte — le fichier contient votre clé privée et ne doit pas être lisible par les autres utilisateurs de la machine. Gardez un nom court et simple ; il doit être un nom d'interface réseau valide.
3. Démarrez-le :

   sudo wg-quick up wg0
   sudo wg show

   wg show est la seule commande à retenir. Elle affiche le pair, l'endpoint, une ligne latest handshake et les compteurs de transfert. Un horodatage de handshake qui n'apparaît jamais est la signature du problème traité dans la section suivante.
4. Démarrage au boot : sudo systemctl enable --now wg-quick@wg0. Pour arrêter le tunnel à la main, sudo wg-quick down wg0.

Sur le routeur, pour couvrir toute la maison

Placer le tunnel sur le routeur couvre tous les appareils qui se trouvent derrière, y compris ceux qui ne peuvent pas du tout faire tourner une application VPN — une console de jeux, une télévision, une enceinte connectée. Que ce soit possible dépend entièrement de votre firmware.

Si votre routeur est la box que votre fournisseur d'accès vous a remise, les options réalistes sont de placer derrière elle un routeur que vous contrôlez, ou de continuer avec des configurations par appareil. Aucune des deux n'est un échec ; une configuration par appareil est même souvent préférable, car vous pouvez laisser le tunnel désactivé sur les appareils qui n'en ont pas besoin.

Une chose à décider avant de faire passer toute la maison par un tunnel : tout y passera alors. Les sites bancaires qui n'aiment pas les adresses étrangères, les services de streaming qui vérifient votre région et tout ce qui communique avec des appareils de votre propre réseau peuvent se comporter différemment. C'est là qu'un AllowedIPs plus restreint prouve son utilité — n'envoyez que ce qui doit passer, et laissez le reste tranquille.

Connecté mais rien ne charge, et autres vrais problèmes

WireGuard est particulièrement silencieux quand il échoue, et c'est un choix de conception délibéré — un paquet non authentifié ne reçoit aucune réponse, si bien qu'un scanner ne peut pas savoir si quelque chose écoute. L'effet secondaire, c'est qu'une mauvaise clé, un mauvais port et un réseau bloqué se ressemblent parfaitement de votre côté : le silence. Partez du symptôme.

« Handshake did not complete »

Votre appareil a envoyé un paquet d'initiation et n'a rien reçu en retour. Vérifiez, dans cet ordre :

• L'endpoint. Bon hôte, bon port, et le port est en UDP. Une faute de frappe ici produit exactement ce symptôme et rien d'autre.
• Que l'UDP sorte bien vers l'extérieur. Les wifi invités, les réseaux d'hôtel, certains réseaux d'entreprise et quelques opérateurs mobiles n'autorisent que le TCP sur les ports courants. Si la même configuration fonctionne sur votre connexion domestique et échoue sur un réseau précis, la configuration est bonne et c'est le réseau qui pose problème.
• Que les clés soient dans le bon sens. La PublicKey de [Peer] est la clé publique du serveur, et le serveur doit de son côté détenir la clé publique qui correspond à votre PrivateKey. Une configuration copiée pour un autre appareil échoue à cette étape.
• Votre horloge. Le handshake WireGuard inclut un horodatage et rejette celui qui est trop décalé. Rare, mais cela arrive sur des appareils qui ont perdu l'heure.

Si le tunnel fonctionne depuis chez vous mais jamais depuis une connexion mobile, la cause peut se trouver du côté de votre fournisseur plutôt que du vôtre — le carrier-grade NAT et les dispositifs similaires changent ce qui peut vous atteindre. Le guide sur la redirection de ports explique comment l'identifier depuis votre propre routeur en quelques minutes.

Le problème de MTU, qui vaut la peine d'être compris une fois

C'est le cas classique du « connecté mais Internet ne marche pas », et le schéma est caractéristique : le ping marche, le DNS marche, les petites pages s'affichent, et tout ce qui est un peu lourd bloque indéfiniment.

La cause, c'est la taille. Encapsuler votre trafic pour le tunnel ajoute des en-têtes, si bien qu'un paquet qui tenait tout juste sur votre connexion normale ne tient plus une fois dans WireGuard. Les petits paquets passent sans problème ; les gros sont abandonnés. Normalement, le réseau indique à l'expéditeur d'utiliser des paquets plus petits, mais le message qui s'en charge est fréquemment filtré : au lieu d'une erreur, vous attendez, tout simplement.

La solution consiste à dire à WireGuard d'utiliser des paquets plus petits dès le départ. wg-quick s'y emploie déjà : il prend la MTU de votre route normale et retire 80 octets pour la surcharge du tunnel, ce qui donne 1420 sur une connexion ordinaire à 1500 octets. Quand c'est encore trop — certains réseaux mobiles, la plupart des connexions qui passent déjà par un autre tunnel —, définissez-la explicitement et descendez progressivement :

[Interface]
MTU = 1420      # what wg-quick would have picked
# still stalling? try 1380, then 1280

1280 est le plancher à essayer, car c'est la plus petite taille de paquet qu'IPv6 impose à tous de transporter : elle passe donc à peu près sur n'importe quel chemin. Elle coûte un peu d'efficacité et vaut bien mieux qu'un tunnel qui se bloque.

Le tunnel est actif mais rien n'y passe

Vérifiez d'abord AllowedIPs. Ce n'est ni un pare-feu ni une liste d'autorisations — il décide quelles destinations sont routées dans le tunnel, tout simplement. S'il n'inclut pas 0.0.0.0/0, le trafic vers le reste d'Internet n'a jamais été censé passer par le tunnel, et votre connexion se comporte exactement comme elle a été configurée. Sous Linux, ip route show table all | grep wg0 montre ce qui a réellement été routé.

Si le routage est bon et que seuls les noms ne se résolvent pas, c'est la ligne DNS — soit elle manque, soit elle est présente mais n'est pas appliquée parce que resolvconf n'est pas installé.

D'où vient le fichier de configuration

Tout ce qui précède suppose que vous avez un fichier. Il y a exactement deux façons d'en obtenir un.

Faire tourner le serveur vous-même

Vous générez une paire de clés, installez WireGuard sur une machine dotée d'une adresse publique, ajoutez votre appareil comme pair et écrivez la configuration client à la main. Ce n'est pas difficile, et c'est une vraie compétence à acquérir. Le coût, lui, est permanent : un serveur à payer et à maintenir à jour, et une modification manuelle aux deux extrémités chaque fois que vous ajoutez un appareil — car, rappelez-vous, un pair correspond à un appareil.

L'obtenir auprès d'un fournisseur

L'autre possibilité, c'est que le fichier soit généré pour vous et que vous n'ayez qu'à le télécharger. Avec HytHost VPN, dès €0.99/mois, voici où il se trouve :

1. Commandez le service et connectez-vous à l'espace client, puis ouvrez votre service VPN dans la liste.
2. Repérez la section WireGuard Configuration. Elle vous propose deux boutons — Copy to Clipboard, qui copie le texte de la configuration dans votre presse-papiers, et Download Configuration, qui vous remet le fichier prêt à l'emploi.
3. Si vous l'avez copiée, collez-la dans un éditeur de texte brut et enregistrez-la avec l'extension .conf — wg0.conf est un bon nom. Vérifiez que votre éditeur n'a pas ajouté .txt à la fin.
4. Importez-la en suivant la section ci-dessus correspondant à votre appareil. Sur un téléphone, transformez-la d'abord en QR code avec qrencode.

La même page indique si le tunnel est actuellement connecté au serveur, ce qui tranche la question « est-ce que ça vient de moi ou d'eux » avant que vous ne commenciez à modifier des réglages. Il n'y a pas de bouton pour le QR code — générez-le vous-même à partir du fichier, ce qui signifie aussi que le code ne transite jamais là où il n'avait pas besoin d'aller.