WireGuard, Tailscale ou Headscale : lequel choisir ?

WireGuard contre Tailscale : réponse courte

WireGuard contre Tailscale n’est pas un choix entre deux protocoles, car Tailscale est WireGuard. Tailscale utilise le même chiffrement et le même tunnel, puis ajoute un plan de contrôle : un serveur de coordination qui échange les clés publiques, attribue les adresses, traverse les NAT (traduction d’adresses réseau) et applique une politique d’accès. Vous choisissez la part de cette coordination que vous souhaitez gérer vous-même.

Il y a trois réponses simples. Utilisez WireGuard seul lorsque vous avez un serveur et quelques clients qui s’y connectent tous. Utilisez Tailscale lorsque vous voulez que chaque machine puisse joindre toutes les autres sans avoir à gérer de fichier de configuration. Utilisez Headscale lorsque vous voulez ce mesh, mais que vous ne voulez pas qu’un tiers détienne la liste des nœuds.

Ce que le control plane vous apporte réellement

WireGuard seul n'offre aucun mécanisme de découverte. Chaque peer est un bloc de texte que vous rédigez manuellement : une clé publique, une ligne AllowedIPs et une ligne Endpoint si ce peer est joignable. Ajouter une machine à un réseau de dix machines impose de modifier dix fichiers de configuration, car chaque côté a besoin de la clé de l'autre. C'est pourquoi presque toutes les configurations WireGuard auto-hébergées utilisent une topologie en étoile : un serveur avec une adresse IP publique, et des clients qui ne communiquent qu'avec lui.

Un control plane supprime ces modifications manuelles. Chaque nœud s'enregistre une fois, reçoit une adresse de la plage 100.64.0.0/10 CGNAT (carrier grade NAT), puis reçoit les clés publiques des nœuds qu'il est autorisé à joindre. Le tunnel reste une connexion WireGuard directe entre deux peers, et votre trafic ne passe jamais par le serveur de coordination. Le serveur ne transporte que des métadonnées : les nœuds existants, la clé de chacun et les nœuds autorisés à communiquer entre eux.

Trois fonctions concrètes en résultent.

Traversée du NAT. Deux ordinateurs portables derrière deux routeurs domestiques différents n'ont aucune adresse IP publique commune pour communiquer directement. Tailscale utilise STUN (session traversal utilities for NAT) pour découvrir l'adresse et le port externes de chaque côté. Les deux côtés envoient ensuite des paquets au même moment, afin que chaque routeur voie d'abord un flux sortant et accepte la réponse. En cas d'échec, le trafic bascule vers un relais DERP, un relais chiffré géré par Tailscale. Vos données restent chiffrées de bout en bout via le relais, car celui-ci ne possède jamais les clés. Exécutez tailscale status : chaque ligne de peer indique alors direct ou relay. Exécutez tailscale netcheck pour voir quel relais est le plus proche et vérifier si votre réseau autorise UDP.

Rotation des clés avec expiration. Les clés WireGuard n'expirent jamais. Une clé créée il y a trois ans reste valide indéfiniment, sauf si vous supprimez manuellement le bloc du peer. Tailscale fait expirer les clés des nœuds. Depuis juillet 2026, la période d'expiration par défaut d'un nouveau tailnet est de 180 jours. Une machine qui ne s'est pas réauthentifiée cesse de se connecter. Vous pouvez désactiver l'expiration pour chaque appareil, notamment pour un serveur ou un subnet router sur lequel personne ne se connectera directement.

Règles de sécurité plutôt que routage. Avec WireGuard seul, AllowedIPs est à la fois la table de routage et la liste de contrôle d'accès. La règle « alice peut joindre la base de données » doit donc être exprimée sous forme de plage d'adresses IP. Tailscale utilise un fichier de stratégie distinct, dans lequel les règles désignent des utilisateurs, des groupes et des tags. Une règle peut autoriser tag:laptop à joindre tag:db sur le port 5432, et rien d'autre. Cette règle reste valide même si une machine reçoit une nouvelle adresse.

Ce que vous coûte le control plane

Le serveur de coordination connaît votre réseau. Il stocke la clé publique de chaque nœud, le nom de chaque nœud, les adresses attribuées et la policy. Avec Tailscale hébergé, ce serveur appartient à une entreprise que vous ne contrôlez pas. Cette entreprise ne peut pas lire vos paquets, car les clés privées WireGuard restent sur vos machines. En revanche, elle peut voir la structure de votre réseau. Votre capacité à vous connecter dépend aussi de la disponibilité de son service et du bon état de votre compte.

Il existe un deuxième coût, plus facile à oublier. Tailscale est un daemon présent sur chaque machine. Vous devez donc maintenir ce logiciel à jour sur chaque machine. WireGuard standard sur Ubuntu 24.04 est un module du kernel fourni avec la distribution. Il est mis à jour avec le kernel.

Le troisième coût est la facturation. En juillet 2026, le plan Personal est gratuit avec un nombre illimité d’appareils pour un maximum de 6 utilisateurs, le plan Standard coûte $8 par utilisateur et par mois, et le plan Premium coûte $18 par utilisateur et par mois. Un foyer reste gratuit. Une équipe de 10 personnes ne l’est pas.

Quand WireGuard seul est le bon choix

Choisissez WireGuard seul lorsque la topologie est réellement en étoile. Un VPS avec une adresse IP publique, trois ou quatre appareils qui s’y connectent, et aucune exigence pour que ces appareils puissent communiquer entre eux. La configuration tient sur un écran. Aucun daemon n’est à mettre à jour, aucun compte ne peut être perdu et aucun service externe ne s’interpose entre vous et votre serveur.

C’est également le bon choix si vous voulez comprendre la couche sur laquelle tout le reste repose. Héberger vous-même un VPN WireGuard sur un VPS explique la génération des clés, wg0.conf, le transfert IP, le NAT et les échecs de handshake. Tous ces mécanismes continuent de fonctionner sous un tailnet. Si vous envisagez encore l’ancienne solution, WireGuard contre OpenVPN présente les quatre cas dans lesquels OpenVPN conserve un avantage.

L’installation est courte :

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

WireGuard seul cesse d’être pratique dès que chaque appareil doit pouvoir joindre tous les autres. Un full mesh de N nœuds nécessite N fois N moins un blocs peer. Avec six appareils, cela représente trente blocs à maintenir manuellement. Une entrée AllowedIPs dupliquée détourne silencieusement le trafic du peer qui la possédait auparavant, sans qu’aucune erreur ne soit affichée.

Quand Tailscale est la bonne solution

Choisissez Tailscale lorsque les machines se déplacent. Les ordinateurs portables sur des réseaux d’hôtel, un téléphone utilisant les données mobiles ou un serveur domestique derrière un routeur que vous ne contrôlez pas en sont des exemples typiques. Ce sont précisément les cas que WireGuard seul gère mal, car aucun des deux côtés ne dispose d’un endpoint public stable à placer dans Endpoint.

L’installation du client se fait avec une seule commande provenant de l’installeur officiel :

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale up affiche une URL. Ouvrez-la, connectez-vous, puis la machine rejoint le réseau. Vous n’avez aucune clé à copier et aucun port entrant à ouvrir, car le daemon établit une connexion sortante vers le serveur de coordination et la maintient ouverte. C’est également pourquoi un nœud Tailscale fonctionne sur un réseau où vous ne contrôlez aucun firewall.

Deux paramètres couvrent l’essentiel des besoins. Un subnet router annonce tout un LAN sur le réseau. Vous n’avez donc pas besoin d’installer le client sur chaque appareil :

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

La route reste inactive tant que vous ne l’avez pas approuvée dans la console d’administration. C’est volontaire : un nœud ne peut pas injecter lui-même une route dans votre réseau. Les clients Linux ont également besoin de sudo tailscale set --accept-routes, car Linux n’accepte pas les routes annoncées par défaut. Ainsi, une route qui semble approuvée côté serveur ne produit toujours aucun effet sur un ordinateur portable Linux tant que vous n’avez pas configuré ce paramètre.

Un exit node envoie tout le trafic d’un client via une seule machine. C’est le comportement full tunnel généralement associé à un « VPN » :

sudo tailscale set --advertise-exit-node

Quand Headscale est la bonne solution

Headscale est une implémentation open source du serveur de coordination, exécutée sur un VPS qui vous appartient. Les clients Tailscale officiels s’y connectent au lieu d’utiliser le service hébergé :

sudo tailscale up --login-server https://headscale.example.com

Le chemin des données reste inchangé. Il utilise toujours WireGuard et reste direct entre les pairs lorsque le réseau le permet. En revanche, la liste des nœuds, les clés et la stratégie sont stockées dans un fichier SQLite sur un disque qui vous appartient. Aucun tiers extérieur ne peut voir la structure de votre réseau, désactiver votre compte ou vous facturer par utilisateur.

Cette solution demande réellement du travail. Vous devez maintenant gérer un service HTTPS public. Il vous faut donc un nom DNS, un certificat et un reverse proxy qui transmet correctement les mises à niveau WebSocket. Vous êtes responsable de sa disponibilité. Si le serveur de coordination est indisponible, les nouveaux nœuds ne peuvent pas s’enregistrer et les nœuds existants ne peuvent pas récupérer les modifications. Headscale est également antérieur à la version 1.0 et ses versions mineures ont introduit des changements incompatibles. Consultez donc le changelog avant chaque mise à niveau. Exécuter Headscale comme votre propre serveur de contrôle Tailscale couvre l’installation, config.yaml, les clés preauth et les ports à ouvrir.

Un point particulier est souvent découvert trop tard. Headscale n’inclut pas le réseau mondial de relais de Tailscale. Lorsque deux pairs ne peuvent pas se connecter directement, vous devez soit activer le relais intégré sur votre propre serveur, soit configurer l’utilisation d’un autre relais. Ce relais est alors une machine unique dans une seule région, et non une infrastructure mondiale. Les pairs situés à l’autre bout de la planète subissent cette différence.

Comment décider en une seule passe

Demandez combien de machines doivent communiquer entre elles. Si elles doivent toutes uniquement communiquer avec le serveur, WireGuard seul nécessite moins de logiciels pour obtenir le même résultat.

Demandez si les machines ont des adresses publiques stables. Si la plupart sont derrière un NAT que vous ne contrôlez pas, vous avez besoin d’un control plane, car le hole punching est la partie difficile et ne vaut pas la peine d’être recréée.

Demandez qui est autorisé à connaître la topologie de votre réseau. Si la réponse exclut les entreprises externes, ou si le nombre d’utilisateurs rend la facturation par siège trop coûteuse, exécutez Headscale et acceptez que vous devez désormais exploiter le control server.

Vous pouvez changer d’avis facilement. Comme le data plane utilise le même protocole dans les trois cas, passer de WireGuard seul à un mesh coordonné consiste à installer le client, et passer de Tailscale à Headscale consiste à réenregistrer chaque nœud auprès d’un login server différent.

Ce qu’aucun des trois ne fournit

Aucun des trois n’est un firewall. Un tunnel détermine quels paquets sont transportés, et non quels services sont en écoute. Un serveur accessible via le tunnel reste accessible depuis Internet sur tout port que vous avez laissé ouvert. Laissez donc les règles du firewall UFW sur le VPS assurer leur rôle. Le fichier de stratégie de Tailscale limite ce que les autres nœuds peuvent atteindre, mais il ne contrôle pas l’interface publique.

Aucun des trois ne fournit une authentification par service. Aucun ne constitue une piste d’audit des actions effectuées par un utilisateur après sa connexion. Considérez les trois comme des mécanismes de transport et placez les contrôles de connexion dans l’application.

FAQ

Tailscale est-il simplement WireGuard avec des étapes supplémentaires ?

Tailscale utilise le protocole WireGuard pour le transport des données. Le chiffrement et le tunnel sont donc les mêmes. Tailscale ajoute la coordination : échange de clés, attribution d’adresses, traversée du NAT avec les relais STUN et DERP, expiration des clés et fichier de stratégie qui désigne les utilisateurs au lieu de plages d’adresses IP. Avec WireGuard seul, vous devez gérer ces éléments vous-même. Ils deviennent difficiles à gérer lorsque les machines changent de réseau.

Mon trafic passe-t-il par les serveurs de Tailscale ?

Normalement, non. Les pairs se connectent directement dès que le serveur de coordination les a présentés l’un à l’autre, et tailscale status affiche direct sur ces lignes de pairs. Lorsqu’un chemin direct ne peut pas être établi, le trafic passe par un relais DERP et la ligne affiche relay. Même dans ce cas, le relais transporte des paquets chiffrés et ne détient pas vos clés privées WireGuard. Il ne peut donc pas lire leur contenu. Exécutez tailscale netcheck pour vérifier si votre réseau bloque le trafic UDP nécessaire aux connexions directes.

Puis-je utiliser Headscale avec les applications officielles Tailscale ?

Oui. Headscale utilise le même protocole de contrôle. Les clients officiels se connectent donc avec sudo tailscale up --login-server https://headscale.example.com. Les applications de bureau et mobiles peuvent également utiliser un serveur de connexion personnalisé. Le réglage se trouve toutefois à un emplacement différent selon la plateforme, et les applications mobiles sont celles qui nécessitent le plus souvent une version précise. Testez un téléphone avant de migrer tout un réseau.

Dois-je tout de même ouvrir des ports pour Tailscale ou Headscale ?

Un client Tailscale n’a besoin d’aucun port entrant. Il se connecte au serveur de coordination et maintient cette connexion ouverte. Un serveur Headscale auto-hébergé a besoin de ports entrants : 443 pour le protocole de contrôle, 80 si vous utilisez un challenge de certificat HTTP-01, et 3478/udp uniquement si vous activez le relais intégré. WireGuard seul nécessite que son port d’écoute UDP, généralement 51820, soit ouvert sur le serveur et sur tout pare-feu réseau distinct géré par votre fournisseur.

Lequel des trois est le plus rapide ?

Le débit est identique, car les trois solutions transportent les paquets avec WireGuard. La différence se situe au niveau de l’établissement de la connexion et de la qualité du chemin réseau. WireGuard seul, avec un Endpoint correct, se connecte directement à chaque fois. Tailscale et Headscale se connectent directement la plupart du temps, puis utilisent un relais lorsque le réseau bloque le hole punching. Un chemin via relais ajoute de la latence. Mesurez votre propre chemin avec tailscale ping <node>, qui indique si la route est directe ou passe par un relais, ou avec iperf3 sur le tunnel.