Tailscale sous Linux crée un réseau privé chiffré entre vos machines sans ouvrir le moindre port sur votre box. Une seule commande installe le client, une seconde l’authentifie, et chaque appareil reçoit une adresse 100.x.y.z stable joignable depuis n’importe où. C’est l’alternative à l’exposition publique quand vous voulez atteindre un service auto-hébergé sans le publier sur Internet.
L’essentiel — Vérifié le 15 août 2026
- Version cliente : Tailscale 1.102.2, dernière version publiée au changelog officiel à cette date.
- Protocole : Tailscale s’appuie sur le protocole open source WireGuard pour chiffrer les connexions point à point.
- Installation : script officiel
curl -fsSL https://tailscale.com/install.sh | shpour les distributions à gestionnaire de paquets classique, puissudo tailscale up.- Distributions listées par la documentation officielle : dérivées d’Ubuntu, dérivées de Debian, RHEL, CentOS, Fedora et dérivées, Raspberry Pi OS, Amazon Linux, openSUSE et SUSE Linux Enterprise, Oracle Linux, VMware Photon OS. Arch Linux est traité à part, avec son propre paquet dans le dépôt Extra.
- Redirection de port impossible (CGNAT) : Tailscale reste utilisable même derrière un CGNAT (NAT partagé par plusieurs abonnés chez le fournisseur d’accès), un cas fréquent chez les FAI français où toute redirection de port manuelle échoue.
- Prérequis noyau : le périphérique
/dev/net/tun, disponible par défaut sur la plupart des distributions.- Coût : le plan Personal est gratuit, avec un nombre d’appareils utilisateurs illimité et jusqu’à 6 utilisateurs.
- Niveau de fiabilité : procédure conforme à la documentation officielle Tailscale consultée le 15 août 2026. Les commandes n’ont pas été exécutées sur une machine de test.
Tailscale sous Linux ou WireGuard seul : ce qui change vraiment
WireGuard est un protocole VPN intégré au noyau Linux. Il ne gère cependant ni la distribution des clés, ni la découverte des pairs, ni la traversée des routeurs NAT. Ces trois problèmes restent à votre charge : générer une paire de clés par machine, recopier chaque clé publique dans le fichier de configuration de tous les autres pairs, et disposer d’au moins une machine joignable depuis Internet avec un port UDP ouvert.
Tailscale reprend WireGuard pour le chiffrement et ajoute exactement ces éléments manquants. L’authentification passe par un fournisseur d’identité, l’échange des clés est automatique, et les connexions s’établissent à travers les pare-feu et le NAT sans redirection de port ni règle particulière. Tailscale revendique lui-même cette approche comme « zero-config » sur son site.
Cette traversée automatique du NAT règle un problème que la redirection de port ne résout pas toujours : le CGNAT (Carrier-Grade NAT), une adresse IP publique partagée entre plusieurs abonnés par le fournisseur d’accès. De nombreux FAI français l’appliquent sur certaines offres fibre ou 4G/5G box, et dans ce cas aucune redirection de port ne fonctionne, quelle que soit la configuration du routeur : il n’y a tout simplement pas de port à rediriger sur une IP qui ne vous appartient pas en propre.
WireGuard seul reste alors bloqué sans solution de contournement côté client ; Tailscale continue de fonctionner en établissant la connexion depuis les deux extrémités, ou en repassant par un relais si nécessaire.
Le compromis est réel et mérite d’être posé : un service tiers, le plan de contrôle Tailscale, coordonne votre réseau. Il ne voit pas le contenu de votre trafic, chiffré de bout en bout entre les machines, mais il connaît la liste de vos appareils et leur état de connexion. Une configuration WireGuard manuelle n’implique personne d’autre que vous, au prix d’une gestion des clés entièrement à votre charge.
Si cette dépendance à un tiers est rédhibitoire mais que vous voulez conserver le confort d’un plan de contrôle automatisé, Headscale est une implémentation open source, non officielle, du plan de contrôle Tailscale, que vous hébergez vous-même : elle reste compatible avec le client Tailscale standard, au prix d’une maintenance qui vous revient entièrement.
| WireGuard seul | Tailscale | |
|---|---|---|
| Chiffrement | Protocole WireGuard | Protocole WireGuard |
| Échange des clés | Manuel, fichier par fichier | Automatique |
| Traversée du NAT | Redirection de port nécessaire | Automatique |
| Machine exposée sur Internet | Au moins une | Aucune |
| Dépendance à un tiers | Aucune | Plan de contrôle Tailscale |
| Mise en route | Longue | Quelques minutes |
Un point technique souvent mal compris : le client Tailscale n’utilise pas le module WireGuard du noyau. Il embarque sa propre implémentation du protocole en espace utilisateur, ce qui explique que vous n’ayez aucun paquet WireGuard à installer avant Tailscale.
Prérequis
Vous avez besoin d’un compte Tailscale, gratuit sur le plan Personal, et des droits sudo sur chaque machine à connecter. Un accès sortant vers Internet suffit : aucune règle entrante n’est à créer sur votre routeur.
Le client réclame le périphérique tun, disponible par défaut sur la grande majorité des distributions. Vérifiez sa présence avant de commencer :
# Le périphérique tun est-il disponible ?
ls -l /dev/net/tunUne sortie du type crw-rw-rw- 1 root root 10, 200 ... /dev/net/tun signifie que tout est en place. N’utilisez pas lsmod pour ce contrôle : le module tun n’est souvent chargé qu’à la première ouverture du périphérique, et il n’apparaît jamais dans lsmod lorsqu’il est compilé directement dans le noyau. Dans les deux cas, lsmod ne renverrait rien alors que le système fonctionne parfaitement.
Si le périphérique est absent, chargez le module :
sudo modprobe tunPour que le chargement survive au redémarrage, la documentation Tailscale indique d’ajouter tun à /etc/modules ou à /etc/modules-load.d/tun.conf.
Comptez une dizaine de minutes pour connecter deux machines.
Étape 1 — Installer le client Tailscale
La méthode officielle pour les distributions à gestionnaire de paquets classique est un script d’installation unique :
curl -fsSL https://tailscale.com/install.sh | shAvertissement — vous exécutez un script distant. La construction
curl | shtélécharge du code et l’exécute immédiatement avec les droits qu’elle demande, sans que vous en ayez lu une ligne. Elle est ici recommandée par l’éditeur lui-même sur son propre domaine, mais si ce mode d’installation ne vous convient pas, Tailscale publie les instructions manuelles distribution par distribution sur sa page de paquets stables. Téléchargez alors le script séparément, lisez-le, puis exécutez-le.
D’après la documentation officielle, ce script prend en charge les dérivées d’Ubuntu, les dérivées de Debian, RHEL, CentOS, Fedora et leurs dérivées, Raspberry Pi OS, Amazon Linux, openSUSE et SUSE Linux Enterprise, Oracle Linux, et VMware Photon OS.
Arch Linux est traité à part par la documentation, qui renvoie vers le paquet de la distribution plutôt que vers le script d’installation. Celui-ci est fourni par le dépôt officiel Extra. Manjaro, dérivée d’Arch, n’est pas nommément citée par la documentation Tailscale, mais le même paquet convient dans la pratique :
sudo pacman -S tailscale
sudo systemctl enable --now tailscaledLa seconde commande n’est pas facultative. Arch n’active aucun service à l’installation d’un paquet : sans elle, le démon tailscaled ne tourne pas et l’étape 2 échouera. Sur les distributions installées via le script officiel, cette activation est prise en charge automatiquement.
Au 15 août 2026, le dépôt Extra d’Arch propose la version 1.98.10, la 1.102.2 se trouvant encore dans extra-testing. Un décalage de version par rapport au changelog amont est normal et sans gravité pour un usage courant.
Vérification de l’étape. Le binaire doit répondre, et le démon doit tourner :
# Version du client installé
tailscale version
# Le démon est-il actif ? Doit répondre : active
systemctl is-active tailscaledLes deux contrôles sont nécessaires : tailscale version interroge le binaire posé sur le disque et réussit même si le démon est à l’arrêt.
Étape 2 — Authentifier la machine
L’installation ne connecte rien par elle-même. La commande suivante démarre la connexion :
sudo tailscale upLa sortie affiche une URL d’authentification. Ouvrez-la dans un navigateur, sur la machine elle-même ou depuis un autre appareil, et connectez-vous. Votre réseau privé Tailscale porte le nom de tailnet.
Répétez l’opération sur chaque machine à raccorder. Deux appareils authentifiés suffisent à constituer un tailnet fonctionnel.
Vérification de l’étape. Demandez l’adresse attribuée à la machine :
tailscale ip -4La réponse est une adresse de la plage 100.x.y.z, par exemple 100.121.112.23. Cette adresse est stable et propre à cette machine. La console d’administration Tailscale doit également faire apparaître l’appareil dans sa liste de machines.
Étape 3 — Vérifier la liaison entre deux appareils
Une fois deux machines authentifiées, l’état du réseau se lit avec :
tailscale statusLa sortie prend cette forme, telle que décrite dans la documentation de la ligne de commande :
100.1.2.3 device-a utilisateur@ linux active; direct <ip-port>, tx 1116 rx 1124
100.4.5.6 device-b utilisateur@ macOS active; relay <relay-server>, tx 1351 rx 4262
100.7.8.9 device-c utilisateur@ windows idle; tx 1214 rx 50
100.0.1.2 device-d utilisateur@ iOS -Les colonnes donnent, de gauche à droite : l’adresse Tailscale, le nom de la machine, l’adresse e-mail du propriétaire de l’appareil, le système d’exploitation, et l’état de la connexion.
Cette dernière colonne mérite votre attention. active indique un échange de trafic en cours, accompagné du type de liaison : direct signale une connexion établie directement entre les deux machines, relay indique que le trafic transite par un serveur relais Tailscale parce que la liaison directe n’a pas pu s’établir, et peer-relay indique un relais assuré par un autre appareil du tailnet plutôt que par l’infrastructure Tailscale.
Une liaison relay ou peer-relay fonctionne, mais avec une latence supérieure à une liaison directe. idle désigne un appareil connu et joignable, sans trafic à cet instant. Un simple tiret signale un appareil que cette machine n’a pas encore joint : c’est le cas normal juste après l’ajout d’un appareil, tant qu’aucune communication n’a eu lieu entre les deux.
Pour tester la liaison, préférez la commande dédiée au ping classique : elle renseigne sur le chemin emprunté.
tailscale ping device-bPar défaut, cette commande s’arrête dès qu’un chemin direct est établi, envoie au maximum dix messages et abandonne après cinq secondes d’attente.
Si vous rencontrez des difficultés de connexion, tailscale netcheck produit un rapport sur les conditions réseau de la machine : disponibilité de l’UDP, présence d’IPv4 et d’IPv6, champ MappingVariesByDestIP qui signale un NAT difficile à traverser, serveur relais le plus proche et latences associées.
Étape 4 — Atteindre un service auto-hébergé sans l’exposer
C’est ici que Tailscale prend tout son sens face à l’autre approche possible. Pour rendre un service accessible à distance, vous avez le choix entre le publier sur Internet derrière un nom de domaine et un certificat, ou le laisser strictement privé et n’y accéder que par le tailnet.
La première approche est celle d’un reverse proxy, décrite dans notre guide sur l’installation de Nginx Proxy Manager avec SSL automatique. Elle est indispensable dès que le service doit être joignable par des personnes qui n’installeront pas de client VPN.
La seconde consiste à ne rien publier du tout. Si vous hébergez une galerie photo avec Immich sur Linux via Docker Compose, le service écoute sur un port de la machine. Depuis n’importe quel appareil de votre tailnet, il devient accessible en pointant l’adresse Tailscale de l’hôte suivie du port du service, dans un navigateur. Aucun port n’est ouvert sur votre box, aucun nom de domaine n’est nécessaire, et le service reste invisible depuis Internet.
Une condition est à vérifier : le service doit écouter sur toutes les interfaces, et pas uniquement sur la boucle locale. Un service lié à 127.0.0.1 reste injoignable depuis le tailnet, y compris avec Tailscale correctement configuré. C’est une configuration fréquente lorsque le service était prévu pour être servi par un reverse proxy installé sur la même machine.
# Sur quelle adresse le service écoute-t-il ?
ss -tlnp | grep 2283Une adresse locale affichée sous la forme 127.0.0.1:2283 confirme le problème : le service n’est accessible que depuis la machine elle-même. Une valeur 0.0.0.0:2283 ou *:2283 indique au contraire qu’il accepte les connexions entrantes, donc celles venues du tailnet.
Vérification de l’étape. Depuis un autre appareil du tailnet, en remplaçant l’adresse et le port par les vôtres :
curl -sS -o /dev/null -w '%{http_code}n' http://100.121.112.23:2283Un code de réponse HTTP s’affiche : le service répond à travers le tailnet.
Le même raisonnement s’applique à une interface d’administration, qui n’a le plus souvent aucune raison d’être publique. C’est le cas de la console web d’un hyperviseur monté selon notre guide d’installation de Proxmox VE.
Pour l’accès en ligne de commande, Tailscale propose sa propre gestion de SSH, qui s’active ainsi :
sudo tailscale set --sshCette commande modifie les préférences du démon, d’où les droits administrateur. La fonctionnalité gère les accès SSH par les règles du tailnet plutôt que par des clés distribuées à la main. Elle ne dispense pas de durcir le service SSH classique de la machine, sujet traité dans notre guide sur la configuration et la sécurisation de SSH.
Couper, reprendre et se déconnecter
Trois commandes distinctes existent, et les confondre est la source d’erreur la plus fréquente.
# Se déconnecter du tailnet sans perdre l'authentification
sudo tailscale down
# Se reconnecter
sudo tailscale up
# Se déconnecter ET expirer l'authentification de la machine
sudo tailscale logoutCes trois commandes modifient l’état du démon et réclament donc les droits administrateur, contrairement aux commandes de consultation comme tailscale status ou tailscale ip.
Après sudo tailscale down, vous n’atteignez plus vos appareils, mais la machine reste enregistrée : sudo tailscale up sans option rétablit la liaison. Après sudo tailscale logout, la prochaine connexion exigera une nouvelle authentification complète.
Désinstaller Tailscale
La désinstallation passe par le gestionnaire de paquets utilisé à l’installation :
# Ubuntu, Debian et dérivées
sudo apt-get remove tailscale
# Fedora, CentOS 8, CentOS Stream 9, RHEL 8
sudo dnf remove tailscale
# openSUSE
sudo zypper rm tailscale
# CentOS 7, Amazon Linux 2
sudo yum remove tailscalePour effacer également l’état local de la machine, la documentation officielle indique de supprimer le fichier d’état :
sudo rm /var/lib/tailscale/tailscaled.stateAvertissement — suppression définitive. Ce fichier contient l’identité de la machine dans votre tailnet. Une fois supprimé, la machine ne peut pas retrouver son adresse Tailscale précédente : une réinstallation ultérieure lui attribuera une nouvelle adresse. Ne supprimez ce fichier que si vous retirez définitivement la machine du réseau. Pensez à retirer aussi l’appareil depuis la console d’administration.
Un dernier point que la documentation ne mentionne pas : si vous êtes passé par le script d’installation, celui-ci a ajouté le dépôt Tailscale à votre gestionnaire de paquets, ainsi que la clé de signature associée. La désinstallation du paquet ne les retire pas, et votre système continuera d’interroger ce dépôt à chaque mise à jour. Sur Debian et Ubuntu, vérifiez ce qui subsiste :
ls /etc/apt/sources.list.d/ | grep -i tailscaleSupprimez ensuite le fichier listé si vous ne comptez pas réinstaller Tailscale.
Erreurs courantes
La commande tailscale répond mais rien ne se connecte. Le client se compose de deux parties : le démon tailscaled, qui fait le travail, et la commande tailscale, qui lui parle. Si le démon ne tourne pas, la commande échoue à le joindre. Vérifiez son état avec systemctl status tailscaled.
Une erreur mentionne le module tun. Le module n’est pas chargé. Reportez-vous à la section des prérequis : sudo modprobe tun, puis rendez le chargement persistant.
Toutes les connexions apparaissent en relay dans tailscale status. La liaison directe n’a pas pu s’établir, souvent à cause d’un double NAT ou d’un pare-feu restrictif sur le trafic UDP sortant. Le réseau fonctionne malgré tout, avec une latence plus élevée. tailscale netcheck indique notamment si l’UDP passe.
La machine réclame une nouvelle authentification au bout de quelques mois. C’est le comportement normal : les clés d’appareil expirent périodiquement. Forcez la réauthentification avec sudo tailscale up --force-reauth. Pour un serveur qui doit rester connecté en permanence, l’expiration peut être désactivée appareil par appareil depuis la console d’administration. La documentation Tailscale précise que cette désactivation réduit la sécurité et la réserve aux appareils de confiance.
Vous ne souhaitez pas que le client envoie ses journaux. Le client transmet par défaut des journaux de connectivité aux serveurs Tailscale. La documentation indique d’ajouter TS_NO_LOGS_NO_SUPPORT=true dans /etc/default/tailscaled, en précisant que cela peut empêcher l’éditeur de fournir un support technique. Redémarrez ensuite le démon, sans quoi le réglage n’aura aucun effet : systemd ne lit ce fichier qu’au démarrage du service.
sudo systemctl restart tailscaledQuestions fréquentes
Tailscale est-il gratuit ?
Oui pour un usage personnel. Le plan Personal est annoncé gratuit sans limite de durée, avec un nombre illimité d’appareils utilisateurs, jusqu’à 6 utilisateurs, jusqu’à 3 groupes de contrôle d’accès, 50 ressources étiquetées pour commencer et 1 000 minutes par mois de ressources éphémères. Les plans payants ciblent les usages professionnels et les équipes. Conditions relevées le 15 août 2026 : vérifiez la page officielle avant de vous engager, en particulier si votre usage n’est pas strictement personnel.
Faut-il installer WireGuard avant Tailscale ?
Non. Le client Tailscale embarque sa propre implémentation du protocole WireGuard en espace utilisateur. Aucun paquet wireguard ou wireguard-tools n’est requis. Ces paquets ne servent que si vous configurez WireGuard vous-même, sans Tailscale.
Tailscale voit-il passer mon trafic ?
Non pour le contenu : les connexions sont chiffrées de bout en bout entre vos appareils. Le plan de contrôle Tailscale gère en revanche l’identité des machines, la distribution des clés publiques et l’état des connexions. Et lorsque la liaison directe entre deux appareils échoue, le trafic emprunte un serveur relais de Tailscale, comme le signale l’état relay dans tailscale status : le relais achemine alors des paquets qu’il n’est pas en mesure de déchiffrer. Si ce modèle ne vous convient pas, une configuration WireGuard manuelle vous en affranchit.
Quelle différence avec un VPN commercial ?
L’objectif diffère. Un VPN commercial fait sortir votre trafic Internet par un serveur distant, pour masquer votre adresse IP. Tailscale relie vos propres machines entre elles dans un réseau privé. Les deux usages peuvent se rejoindre : Tailscale sait faire transiter tout le trafic par une machine désignée comme nœud de sortie, mais ce n’est pas sa fonction première.
Comment couper rapidement Tailscale sans le désinstaller ?
sudo tailscale down suffit. La machine reste enregistrée dans le tailnet et sudo tailscale up rétablit la connexion sans nouvelle authentification.
Faut-il ouvrir un port sur ma box ?
Non. C’est précisément ce que Tailscale évite : les connexions s’établissent à travers le NAT et les pare-feu sans redirection de port. Seul l’accès sortant vers Internet est nécessaire.
Conclusion
Tailscale sous Linux résout en quelques minutes un problème qui demande normalement une configuration WireGuard complète : relier des machines dispersées sans exposer aucun service sur Internet. Le script officiel couvre l’essentiel des distributions courantes, Arch passant par son propre paquet, et deux commandes suffisent à raccorder un appareil.
Le choix entre Tailscale et une configuration WireGuard manuelle se joue sur un seul critère : acceptez-vous qu’un service tiers coordonne votre réseau, en échange d’une mise en route sans gestion de clés ? Pour un accès privé à des services auto-hébergés, la réponse est le plus souvent oui. Pour une infrastructure qui doit rester autonome de bout en bout, WireGuard seul garde tout son intérêt.
Si vous devez au contraire rendre un service accessible publiquement, la démarche est différente et passe par un reverse proxy avec certificat automatique. Et quel que soit le mode d’accès retenu, la sécurisation du service SSH reste la première mesure à appliquer sur toute machine joignable à distance.
