WireGuard, Tailscale ou Headscale : lequel choisir ?

WireGuard vs Tailscale : réponse courte

WireGuard vs 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 control plane : un serveur de coordination qui échange les clés publiques, attribue les adresses, traverse les NAT (network address translation) et applique une politique d’accès. Vous choisissez la part de cette coordination que vous souhaitez gérer vous-même.

Il existe 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 conserve la liste des nœuds.

Ce que le control plane vous apporte réellement

WireGuard seul ne fournit 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 implique de modifier dix fichiers de configuration, car chaque côté doit connaître la clé de l’autre. C’est pourquoi presque toutes les configurations WireGuard auto-hébergées utilisent une architecture en étoile : un serveur doté d’une IP publique, et des clients qui ne communiquent qu’avec lui.

Un control plane évite 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 transite jamais par le serveur de coordination. Le serveur transporte uniquement des métadonnées : les nœuds existants, la clé de chacun et les nœuds autorisés à communiquer entre eux.

Cela apporte trois éléments concrets.

Traversal NAT. Deux ordinateurs portables situés derrière deux routeurs domestiques ne disposent d’aucune IP publique commune. 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, qui est un relais chiffré géré par Tailscale. Vos données restent chiffrées de bout en bout via le relais, car celui-ci ne détient jamais les clés. Exécutez tailscale status : chaque ligne de peer indique alors direct ou relay. Exécutez tailscale netcheck pour connaître le relais le plus proche et vérifier si votre réseau autorise les paquets UDP.

Rotation des clés avec expiration. Les clés WireGuard n’expirent jamais. Une clé créée il y a trois ans continue de fonctionner indéfiniment, sauf si vous supprimez manuellement le bloc du peer. Tailscale fait expirer les clés des nœuds. En 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 auquel personne ne pourra se connecter pour effectuer cette opération.

Stratégie 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 la forme d’une plage d’adresses IP. Tailscale conserve un fichier de stratégie distinct, dans lequel les règles désignent des utilisateurs, des groupes et des tags. Une règle peut indiquer que tag:laptop peut 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.

Le coût du control plane

Le serveur de coordination connaît votre réseau. Il détient 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. L’importance de ce point dépend de ce qu’un serveur de coordination compromis ou un compte d’identité volé pourrait réellement faire avec les informations qu’il détient. C’est pourquoi il est utile de lire en détail le modèle de confiance de Tailscale.

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

Le troisième coût concerne la facturation. En juillet 2026, le plan Personal est gratuit et autorise un nombre illimité d’appareils pour un maximum de 6 utilisateurs. Le plan Standard coûte $8 par utilisateur et par mois. Le plan Premium coûte $18 par utilisateur et par mois. Un foyer reste donc dans l’offre gratuite. Une équipe de 10 personnes ne le peut pas. Le dépassement dépend du nombre d’utilisateurs, pas du nombre d’appareils. Il est donc utile de lire ce que couvre réellement le plan gratuit avant d’inviter le septième utilisateur.

Quand WireGuard classique est le bon choix

Choisissez WireGuard classique lorsque la topologie est réellement en étoile, avec un hub et des clients. Un seul VPS avec une adresse IP publique, trois ou quatre appareils qui s’y connectent, et aucune nécessité pour ces appareils de 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 soi-même un VPN WireGuard sur un VPS explique la génération des clés, wg0.conf, le forwarding IP, le NAT et les échecs de handshake. Tous ces mécanismes continuent de fonctionner sous un tailnet. Si vous envisagez encore l’ancienne option, WireGuard vs 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 classique 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 en premier, sans afficher la moindre erreur.

Dans quels cas Tailscale est le bon choix

Choisissez Tailscale lorsque les machines se déplacent. Il peut s’agir d’ordinateurs portables connectés à des réseaux d’hôtel, d’un téléphone utilisant le réseau mobile ou d’un serveur personnel derrière un routeur que vous ne contrôlez pas. Ce sont précisément les cas que WireGuard classique 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 en une commande depuis l’installateur 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 pas de clé à copier ni de port entrant à ouvrir, car le daemon établit une connexion sortante vers le serveur de coordination et la maintient ouverte. C’est également la raison pour laquelle un nœud Tailscale fonctionne sur un réseau dont vous ne contrôlez aucun firewall.

Deux paramètres couvrent ensuite 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 seul 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. Une route qui semble approuvée côté serveur ne produit donc toujours aucun effet sur un ordinateur portable Linux tant que vous n’avez pas défini ce paramètre. Si c’est l’architecture recherchée, exécuter un subnet router sur un VPS détaille l’étape d’approbation et les paramètres de forwarding dans l’ordre qui évite d’obtenir une route partiellement fonctionnelle.

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

sudo tailscale set --advertise-exit-node

Ce flag est la partie la plus simple. L’article transformer un VPS en exit node explique la suite : approuver la route dans la console d’administration, puis corriger le comportement de DNS et d’IPv6, qui ferait sinon sortir le trafic par le mauvais chemin. Si vous souhaitez accéder à un seul service web plutôt qu’à tout un réseau, serve et funnel place HTTPS devant un port local unique, soit uniquement sur le tailnet, soit en l’ouvrant à l’Internet public.

Quand Headscale est le bon choix

Headscale est une implémentation open source du serveur de coordination. Il s’exécute sur un VPS que vous contrôlez. 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 entièrement inchangé. Il utilise toujours WireGuard, avec une connexion directe 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 que vous contrôlez. Aucun tiers ne peut voir la topologie de votre réseau, désactiver votre compte ou vous facturer par utilisateur.

Cette solution demande toutefois un vrai travail d’administration. Vous exploitez alors 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 changements. 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. Exploiter Headscale comme votre propre serveur de contrôle Tailscale couvre l’installation, config.yaml, les clés preauth et les ports à ouvrir.

Un point pose souvent problème tardivement. 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 un autre relais. Ce relais se trouve alors sur une seule machine, dans une seule région, et non au sein d’une flotte mondiale. Les pairs situés à l’autre bout de la planète ressentent cette différence. Si vous préférez ne pas assembler vous-même cette partie, auto-héberger NetBird est l’autre solution pour conserver le control plane en interne, car son quickstart démarre ensemble les services de management, de signalisation et de relais sur un seul VPS.

Comment décider en une seule étape

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

Demandez si les machines ont des adresses publiques stables. Si la plupart se trouvent derrière un NAT que vous ne contrôlez pas, il vous faut un control plane, car le hole punching est la partie complexe et ne mérite pas d’être réimplémentée.

Demandez qui est autorisé à connaître la topologie de votre réseau. Si votre réponse exclut les entreprises externes, ou si le nombre d’utilisateurs rend la facturation par utilisateur difficile à supporter, déployez Headscale et acceptez de devoir administrer le serveur de contrôle. Si la facturation est le facteur déterminant, faites les calculs avant de lancer la migration, car ce que paie réellement une équipe de votre taille dépend du nombre de personnes qui possèdent un compte, et non du nombre de machines que vous exploitez. Ces deux nombres sont rarement proches.

Vous pouvez changer d’avis à moindre coût. Comme le data plane repose sur le même protocole dans les trois cas, passer de WireGuard seul à un mesh coordonné consiste à installer le client plutôt qu’à revoir l’architecture. Passer de Tailscale à Headscale consiste à réenregistrer chaque nœud auprès d’un autre login server.

Ce qu’aucun des trois ne fournit

Aucun n’est un firewall. Un tunnel détermine quels paquets sont transportés, pas quels services sont en écoute. Un serveur accessible via le tunnel reste accessible depuis Internet sur tous les ports que vous avez laissés ouverts. Laissez donc les règles du firewall UFW sur le VPS faire leur travail. Le fichier de policy de Tailscale limite ce que les autres nœuds peuvent atteindre. Il ne protège pas l’interface publique.

Aucun ne fournit d’authentification par service, et 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. 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 identiques. 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 nomme les utilisateurs au lieu de plages d’adresses IP. Avec WireGuard seul, ces tâches vous incombent. Elles deviennent complexes lorsque les machines changent de réseau.

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

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

Puis-je utiliser Headscale avec les applications Tailscale officielles ?

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 plate-forme, et les applications mobiles sont les plus susceptibles d’exiger une version précise. Testez un téléphone avant de migrer tout un réseau.

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

Un client Tailscale n’a besoin d’aucun port entrant. Il ouvre une connexion sortante vers le serveur de coordination et la maintient ouverte. En revanche, 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 ainsi que sur tout firewall 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 relayé ajoute de la latence. Mesurez votre propre chemin avec tailscale ping <node>, qui indique si la route est directe ou relayée, ou avec iperf3 à travers le tunnel. Si cette valeur est nettement inférieure au débit de votre ligne sur un chemin direct, le choix entre ces trois solutions n’est pas responsable du problème. La cause habituelle est une différence de MTU sur le chemin, qui produit le même résultat avec ou sans plan de contrôle.