Rédigé par Rédaction CyberSDF / 18 September 2026

Tailscale sur Linux : relier ses appareils sans configurer chaque tunnel

Tailscale relie des appareils dans un réseau privé appelé tailnet. Il s’appuie sur WireGuard pour chiffrer les échanges, puis ajoute une gestion des identités, des appareils, des routes et des noms. Le trafic Internet ordinaire ne passe pas par Tailscale par défaut : il faut choisir un exit node pour changer cette règle.

Le critère technique est simple : si vous devez régler des routes, un DNS, un pare-feu ou un daemon, vous ne choisissez pas seulement une application. Vous choisissez aussi qui administre les deux extrémités et qui peut modifier les accès.

Tailscale n’est pas le VPN qui cache votre adresse partout

Un VPN de sortie envoie votre trafic Internet vers un serveur qui devient le point de sortie. Tailscale commence par un autre besoin : relier des machines qui vous appartiennent ou que vous administrez. Un portable peut joindre un serveur, un poste fixe ou un téléphone sur le tailnet, même si les appareils ne sont pas sur le même réseau local.

La différence change le résultat attendu. Une connexion entre deux appareils Tailscale ne rend pas anonyme le navigateur et ne protège pas un ordinateur compromis. Elle fournit un chemin chiffré entre des appareils autorisés. La page officielle What is Tailscale décrit ce réseau de pairs et l’usage de WireGuard.

Trois situations ne demandent pas la même configuration :

• joindre un serveur Linux depuis un autre appareil : un client Tailscale sur chaque appareil suffit souvent ;
• joindre une imprimante ou un NAS qui ne peut pas installer le client : un subnet router annonce le réseau local ;
• faire sortir la navigation par un ordinateur de confiance : un exit node devient la route par défaut.

Commencez par le trajet à protéger. Le mot VPN ne dit pas si vous cherchez un accès privé, une route vers un LAN ou une sortie Internet.

Installer le client Linux et rejoindre un tailnet

La documentation d’installation Linux de Tailscale propose un script pour les distributions courantes et des instructions par paquet. Le script officiel est pratique pour un premier poste, mais l’installation manuelle convient mieux si vous devez contrôler chaque paquet avant de l’ajouter au système.

Avec le script officiel :

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

Vous pouvez aussi ouvrir la page des paquets stables, choisir votre distribution et suivre la méthode fournie. Le point important est de ne pas confondre l’installation avec la connexion au réseau.

Activez ensuite le client et demandez l’authentification :

sudo tailscale up

La commande affiche une adresse à ouvrir dans un navigateur. Après la validation de l’identité, la machine apparaît dans le tailnet. Sur un serveur sans interface graphique, l’authentification peut être faite depuis un autre appareil, selon la méthode proposée par l’administrateur du tailnet.

Mesurez la version avant de dépanner une commande :

tailscale version

Le 18 septembre 2026, cette commande a renvoyé 1.102.2 sur un Linux équipé du client Tailscale, avec un code de retour nul. Cette mesure ne vaut que pour cette installation ; elle donne le point de départ nécessaire pour comparer une option de CLI ou un comportement documenté.

La version et l’état du daemon sont deux choses différentes. Une version affichée prouve que le binaire répond. Elle ne prouve pas que la machine est authentifiée, qu’un pair est en ligne ou qu’un service accepte les connexions.

Vérifier deux appareils avant de parler de réseau

La procédure de démarrage Tailscale ajoute un appareil, puis un second, avant de proposer les fonctions de DNS et de routage. Sur Linux, la vérification utile commence par l’état local :

tailscale status

Cette commande liste les appareils visibles par le client et leur état. Ne publiez pas cette sortie sans la relire : elle peut contenir des noms de machines, des adresses, des utilisateurs et des informations de dernière connexion.

Pour vérifier le chemin vers un appareil précis, utilisez son nom ou son adresse Tailscale :

tailscale ping nom-de-la-machine

Le résultat de tailscale ping renseigne sur le chemin Tailscale. Il ne remplace pas un test du service que vous voulez utiliser. Si le but est SSH, testez ensuite SSH. Si le but est une interface web, testez le port et le protocole depuis l’autre appareil.

MagicDNS permet d’utiliser le nom d’une machine au lieu de mémoriser son adresse. La documentation indique que cette fonction ne demande pas de nameserver supplémentaire à partir de Tailscale 1.20. Vous pouvez donc viser un service avec un nom lisible, par exemple :

ssh utilisateur@serveur-maison
curl -I http://serveur-maison:8080/

Le nom résout l’appareil. Il n’accorde aucun droit au service. Une règle de pare-feu, une politique Tailscale ou une application qui n’écoute que sur 127.0.0.1 peut encore refuser la connexion.

Pour un contrôle reproductible, gardez cette séquence : version, statut, chemin vers le pair, puis test du service. Elle évite de déclarer le réseau fonctionnel parce qu’un seul daemon est démarré.

Atteindre un LAN avec un subnet router

Une imprimante, une caméra ou un vieux NAS ne peut pas toujours recevoir le client Tailscale. Dans ce cas, installez Tailscale sur une machine qui peut atteindre le réseau local, puis configurez cette machine comme subnet router. Elle annonce un préfixe du LAN aux appareils autorisés du tailnet.

Sur le routeur de sous-réseau, la commande ressemble à ceci :

sudo tailscale up --advertise-routes=192.168.50.0/24

Remplacez 192.168.50.0/24 par le réseau réel, jamais par un exemple copié sans vérification. L’administrateur doit ensuite approuver la route dans la console et vérifier le pare-feu. Sur un client Linux qui doit accepter les routes annoncées, l’option correspondante peut être nécessaire :

sudo tailscale up --accept-routes

Le subnet router ne transforme pas le LAN en tailnet complet. Il donne un chemin vers les adresses annoncées, avec les droits et les règles de routage qui les accompagnent. Un appareil du LAN peut aussi refuser la connexion, ne pas connaître la route de retour ou filtrer les paquets venant du routeur.

La documentation des subnet routers précise le fonctionnement des routes annoncées et leur approbation. Pour un premier essai, choisissez une seule cible, vérifiez son adresse depuis le client, puis testez le service attendu. N’annoncez pas tout un réseau avant d’avoir confirmé le trajet et le retour des paquets.

L’exit node change la promesse du VPN

Un exit node est un appareil du tailnet qui sert de passerelle pour le trafic Internet d’un autre appareil. Tailscale devient alors comparable, pour ce trajet précis, à un VPN de sortie. L’appareil doit annoncer ce rôle, l’administrateur doit l’autoriser et le client doit le sélectionner.

Pour annoncer un exit node sur Linux :

sudo tailscale up --advertise-exit-node

Sur le client, la sélection se fait avec le nom ou l’adresse de l’appareil :

sudo tailscale up --exit-node=nom-de-la-machine

Les routes 0.0.0.0/0 et ::/0 correspondent aux routes par défaut IPv4 et IPv6. Elles changent le trajet du trafic qui n’est pas déjà destiné au tailnet. L’accès au réseau local du client peut aussi changer selon l’option --exit-node-allow-lan-access.

La documentation des exit nodes demande une activation explicite et distingue le réseau privé du trafic public. Vérifiez l’adresse IP publique depuis le client, puis désactivez l’exit node et refaites le même contrôle. Ce test ferme la question du trajet ; il ne prouve pas l’anonymat du compte ou du navigateur.

Ne sélectionnez pas un exit node pour réparer un accès à un serveur du tailnet. Pour ce besoin, corrigez d’abord le peer, MagicDNS, le service et la politique d’accès. Une route par défaut ajoutée trop tôt rend le diagnostic plus difficile.

Tailscale ou WireGuard direct, qui doit garder la configuration ?

WireGuard direct et Tailscale ne répondent pas au même besoin d’administration. WireGuard fournit le tunnel et les clés ; il vous revient ensuite d’écrire les pairs, de distribuer les clefs publiques, de régler les routes et de maintenir les endpoints. La page Configurer WireGuard sur Linux montre ce niveau de contrôle avec wg-quick et AllowedIPs.

Tailscale ajoute l’identité des utilisateurs et des machines, la distribution des paramètres, la découverte et le traversal NAT. Cela réduit la configuration manuelle quand les appareils changent de réseau ou quand plusieurs personnes doivent accéder à plusieurs machines. La comparaison officielle entre WireGuard et Tailscale rappelle que le trafic pair à pair reste fondé sur WireGuard, tout en ajoutant une couche d’administration.

Tailscale simplifie la gestion, mais il ajoute une dépendance au service de coordination et à l’identité qui administre le tailnet. Le chiffrement du trafic entre pairs ne supprime pas cette question de gouvernance.

Le contrôle qui évite d’ouvrir un service par erreur

Un appareil Tailscale peut être joignable sans que le service voulu soit correctement protégé. Avant de modifier la politique, lisez ce qui écoute sur la machine :

ss -lnt

Un service lié à 0.0.0.0 n’a pas la même exposition qu’un service lié à l’adresse Tailscale ou à 127.0.0.1. La commande ss montre une écoute locale ; elle ne prouve pas qu’un autre appareil peut l’atteindre.

Depuis un peer autorisé, testez ensuite le service :

curl -sS -o /dev/null -w '%{http_code}\n' http://nom-de-la-machine:8080/

Conservez le code HTTP et le message d’erreur. Un timeout, un refus TCP et une réponse HTTP sont trois résultats différents. Si la connexion est refusée, comparez le pare-feu local, la politique d’accès et l’adresse d’écoute avant d’ajouter une route.

La documentation du contrôle d’accès Tailscale sépare l’identité, les règles et les destinations. Pour lire les couches réseau avant de modifier un VPN, utilisez aussi la procédure de diagnostic Linux. Elle distingue interface, adresse, route, DNS et service.

N’annoncez pas un subnet router ou un exit node pour contourner un refus applicatif. Le bon correctif est celui qui change la couche qui a produit l’erreur.

Le premier cas d’usage qui justifie l’installation

Choisissez la première vérification selon votre résultat attendu :

• deux appareils à administrer : installez le client sur chacun, lancez tailscale status, vérifiez le peer avec tailscale ping, puis testez SSH ou HTTP ;
• un appareil du LAN sans client : préparez un subnet router pour une seule adresse ou un préfixe limité, approuvez la route et testez le service ;
• une sortie Internet depuis un autre réseau : préparez un exit node, mesurez l’adresse publique avant et après, puis désactivez-le pour vérifier le retour.

La grille pour choisir un logiciel aide à séparer le résultat, les données touchées, la maintenance et la marche arrière. Pour Tailscale, le bon premier essai n’est pas de multiplier les fonctions : c’est de relier deux appareils, vérifier un service précis et savoir retirer la route ajoutée.