Tailscale : créer un réseau privé sécurisé entre vos serveurs, PC et services

Résumé express

• Besoin couvert : accéder à ses serveurs, son homelab et ses services personnels depuis n’importe où, sans ouvrir de ports sur Internet.
• Fonctionnement : un réseau privé (le « tailnet ») basé sur WireGuard, où chaque appareil est identifié par un compte utilisateur ou par un tag, plutôt que par une adresse IP publique.
• Installation : un script d’installation puis une commande tailscale up suffisent pour rejoindre le tailnet en quelques minutes.
• Point clé : les tags et les grants permettent de segmenter les accès selon le principe du moindre privilège, au lieu de tout autoriser entre appareils connectés.

Dans un homelab, sur un serveur personnel ou dans une petite infrastructure professionnelle, l’accès à distance devient rapidement un sujet important. Ouvrir plusieurs ports sur Internet, configurer des redirections NAT, maintenir un VPN traditionnel et gérer les droits d’accès machine par machine peut vite devenir complexe.

C’est précisément là que Tailscale devient intéressant. Basé sur WireGuard, Tailscale permet de créer un réseau privé entre vos différentes machines, sans avoir à exposer directement leurs services sur Internet. Serveurs, PC, smartphones, NAS, VPS ou conteneurs peuvent ainsi communiquer comme s’ils se trouvaient sur un même réseau local.

Dans cet article, nous allons voir ce qu’est Tailscale, pourquoi l’utiliser, comment l’installer, et surtout comment organiser proprement les tags et les règles d’accès pour un homelab.

Qu’est-ce que Tailscale ?

Tailscale est une solution de réseau privé basée sur WireGuard. Son principe est relativement simple : chaque appareil équipé de Tailscale rejoint un réseau privé appelé tailnet.

Une fois connectés, les appareils peuvent communiquer entre eux à travers ce réseau, même lorsqu’ils se trouvent derrière des box, des NAT ou sur des réseaux complètement différents. Un PC portable sous Windows, un VPS Linux et un homelab hébergeant un NAS, un serveur multimédia comme Jellyfin ou une instance Nextcloud peuvent ainsi dialoguer directement, comme s’ils étaient tous branchés sur le même switch.

Le principal avantage est que l’on ne raisonne plus uniquement en termes d’adresses IP publiques et de ports ouverts, mais en termes de machines, rôles et autorisations. Tailscale propose également MagicDNS, qui permet d’utiliser le nom des machines plutôt que leur adresse Tailscale pour s’y connecter.

Pourquoi utiliser Tailscale ?

Éviter d’exposer inutilement ses services

Prenons un serveur hébergeant Proxmox, Portainer, Grafana, un accès SSH, une interface d’administration et plusieurs services internes. Sans VPN, il peut être tentant d’ouvrir différents ports sur la box ou le pare-feu : 22 pour SSH, 9443 pour Portainer, 3000 pour Grafana, 8006 pour Proxmox, et ainsi de suite.

Chaque port ouvert devient une surface d’exposition supplémentaire, et donc une cible potentielle. Une interface d’administration mal protégée peut suffire à compromettre tout un serveur, comme le montre notre analyse d’un site WordPress piraté. Avec Tailscale, ces services peuvent au contraire rester sur le réseau privé, accessibles uniquement aux appareils ou utilisateurs qui en ont réellement besoin.

Accéder à son homelab depuis n’importe où

Un cas d’usage particulièrement intéressant pour un homelab est l’accès à distance. Depuis un ordinateur portable, un smartphone ou un autre serveur, il devient possible d’accéder à son infrastructure comme si l’on était connecté au réseau local : Portainer, Proxmox, le NAS, Grafana ou Home Assistant restent joignables, sans jamais exposer ces interfaces d’administration sur Internet.

Tailscale n’est pas seulement un VPN

C’est probablement l’un des points les plus intéressants : Tailscale permet de construire une véritable logique d’accès autour des identités et des rôles. C’est ici que les tags deviennent particulièrement utiles.

Un serveur n’est pas réellement un utilisateur. Il est plus logique de dire « cette machine est un serveur web » ou « cette machine héberge une base de données », plutôt que « cette machine appartient à Julien ». Tailscale recommande justement d’utiliser les tags pour les machines qui ne représentent pas des utilisateurs humains.

Les tags Tailscale

Les tags permettent d’attribuer une identité basée sur le rôle d’une machine. On peut par exemple créer les tags suivants :

tag:server
tag:web
tag:database
tag:monitoring
tag:backup
tag:homelab

Une machine peut posséder plusieurs tags à la fois. Par exemple, un serveur Docker pourrait porter tag:server, tag:homelab et tag:web, tandis qu’un serveur PostgreSQL porterait plutôt tag:server, tag:database et tag:production. Tailscale précise qu’un appareil peut avoir plusieurs tags, et que les politiques d’accès peuvent cibler chacun d’entre eux indépendamment.

Un point essentiel à comprendre avant d’utiliser les tags

Un appareil Tailscale possède soit une identité utilisateur, soit une identité basée sur des tags, jamais les deux en même temps. Ajouter un tag à un appareil lui fait donc adopter une identité basée sur ce tag plutôt que l’identité de l’utilisateur qui l’a enregistré.

Les tags sont donc destinés principalement aux serveurs, services et machines d’infrastructure, et non aux ordinateurs personnels des utilisateurs. Le PC de Julien garde son identité utilisateur ; un serveur Docker, lui, reçoit tag:server et tag:docker. C’est une distinction importante pour garder une architecture propre et des règles d’accès lisibles.

Installer Tailscale sous Linux

Sur une distribution Linux compatible, l’installation est très simple. La documentation officielle propose un script d’installation :

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

Puis, pour rejoindre le tailnet :

sudo tailscale up

La commande fournit une URL permettant d’authentifier la machine auprès du tailnet. Une fois l’authentification terminée, la machine apparaît dans la console d’administration Tailscale. On peut ensuite vérifier son état avec :

tailscale status

Exemple d’architecture pour un homelab

Imaginons un homelab comprenant plusieurs machines : un PC personnel, un VPS, un smartphone, et un serveur homelab qui héberge lui-même Docker, un NAS, du monitoring et une solution de sauvegarde. On pourrait organiser ces machines avec les tags suivants :

Machine	Tags
Serveur Docker	tag:server, tag:docker
NAS	tag:server, tag:storage
Grafana	tag:server, tag:monitoring
Serveur de sauvegarde	tag:server, tag:backup
VPS	tag:server, tag:vps

L’intérêt de cette organisation apparaît dès que l’on commence à définir les règles d’accès entre ces différents rôles.

Définir les propriétaires des tags

Les tags sont déclarés dans la section tagOwners de la politique Tailscale (l’ACL du tailnet, éditable depuis la console d’administration). Par exemple :

{
  "tagOwners": {
    "tag:server": [],
    "tag:docker": [],
    "tag:storage": [],
    "tag:monitoring": [],
    "tag:backup": []
  }
}

Une liste vide signifie que les propriétaires du tailnet ont la possibilité d’appliquer ce tag. On peut aussi restreindre cette possibilité à un utilisateur ou à un groupe précis :

{
  "tagOwners": {
    "tag:server": ["[email protected]"],
    "tag:monitoring": ["[email protected]"]
  }
}

La section tagOwners sert précisément à définir qui a le droit d’attribuer chaque tag, ce qui évite qu’un tag sensible comme tag:database soit posé sur un appareil par erreur.

Appliquer un tag à un serveur

Depuis la machine concernée, on applique un ou plusieurs tags directement lors de l’enregistrement :

sudo tailscale up --advertise-tags=tag:server,tag:docker

Le serveur sera alors identifié dans le tailnet comme portant tag:server et tag:docker. Cette méthode est aussi celle recommandée par Tailscale pour automatiser l’enregistrement de nouvelles machines avec des tags, par exemple via un script de provisionnement.

Autoriser l’administration du homelab avec les grants

Imaginons que l’on souhaite permettre aux membres du tailnet d’accéder à tous les serveurs portant le tag tag:server. Avec les grants, la syntaxe recommandée aujourd’hui par Tailscale, cela s’écrit :

{
  "grants": [
    {
      "src": ["autogroup:member"],
      "dst": ["tag:server"],
      "ip":  ["*"]
    }
  ]
}

Les grants constituent aujourd’hui la syntaxe recommandée pour les nouvelles politiques Tailscale : ils remplacent progressivement les ACL historiques, qui restent toutefois toujours supportées.

Séparer frontend, backend et base de données

C’est ici que les tags deviennent vraiment puissants. Imaginons trois types de serveurs : tag:frontend, tag:backend et tag:database. L’objectif est que le frontend puisse parler au backend, que le backend puisse parler à la base de données, mais que le frontend ne puisse jamais accéder directement à la base de données.

La politique peut être organisée ainsi :

{
  "grants": [
    {
      "src": ["tag:frontend"],
      "dst": ["tag:backend"],
      "ip":  ["*"]
    },
    {
      "src": ["tag:backend"],
      "dst": ["tag:database"],
      "ip":  ["*"]
    }
  ]
}

Aucune règle n’autorise tag:frontend à joindre tag:database : cet accès reste donc bloqué par défaut. Ce modèle correspond à l’approche recommandée par Tailscale pour segmenter une architecture en fonction des rôles plutôt que des adresses IP.

Un exemple plus réaliste pour un homelab

Pour un homelab personnel, on pourrait partir sur une organisation de tags comme celle-ci : tag:server, tag:docker, tag:storage, tag:monitoring, tag:backup et tag:management. On définit ensuite des accès spécifiques plutôt qu’un accès global :

• le PC personnel accède à tag:management, tag:monitoring et tag:storage ;
• le serveur Docker accède à tag:storage et tag:monitoring ;
• le serveur de sauvegarde accède uniquement à tag:storage.

Cela permet de limiter progressivement les communications au strict nécessaire. C’est exactement l’idée du principe du moindre privilège : une machine ne devrait pas avoir accès à l’ensemble du réseau simplement parce qu’elle est connectée au tailnet.

Limiter les accès par port

Les règles peuvent être plus précises qu’un simple accès global à une machine. Par exemple, avec une ACL historique, on peut n’autoriser que le port SSH :

{
  "acls": [
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["tag:server:22"]
    }
  ]
}

On peut de la même façon cibler un service précis, par exemple tag:server:443 pour un accès web sécurisé, ou tag:server:8080 pour une interface d’administration donnée. Les règles Tailscale peuvent ainsi prendre en compte à la fois la destination et le port.

ACL ou grants : que choisir ?

Si vous trouvez de nombreux exemples Tailscale sur Internet, vous rencontrerez encore beaucoup de configurations utilisant "acls": [...]. Ce n’est pas une erreur : les ACL restent supportées.

Cependant, Tailscale recommande désormais les grants pour les nouvelles configurations, car ils offrent davantage de possibilités et peuvent également gérer des autorisations au niveau applicatif. Pour une nouvelle installation, il est donc préférable de partir directement sur une combinaison de grants, de tags et de groupes, plutôt que de construire une nouvelle architecture exclusivement autour des anciennes ACL.

MagicDNS : accéder aux machines par leur nom

Une autre fonctionnalité particulièrement agréable est MagicDNS. Au lieu de retenir une adresse Tailscale comme 100.x.x.x, on peut utiliser directement le nom de la machine, par exemple https://portainer ou ssh serveur-docker.

MagicDNS enregistre automatiquement les noms des machines du tailnet et permet donc de les utiliser directement, sans configuration DNS supplémentaire. Pour un homelab comprenant de nombreuses machines, cela devient rapidement très pratique.

Et si une machine ne peut pas installer Tailscale ?

C’est également un point fort de Tailscale. Grâce au Subnet Router, une machine équipée de Tailscale peut servir de passerelle vers tout un réseau local, y compris vers des équipements qui ne peuvent pas installer Tailscale eux-mêmes : caméras IP, imprimantes réseau, objets connectés, ou tout autre appareil fermé.

Concrètement, un serveur du réseau local (par exemple à l’adresse 192.168.1.10) annonce la route vers l’ensemble du sous-réseau 192.168.1.0/24. Une fois cette route approuvée dans la console d’administration, tous les appareils du tailnet peuvent joindre le NAS, la caméra ou l’imprimante situés sur ce réseau, sans que ces équipements aient besoin d’installer quoi que ce soit. Tailscale documente explicitement ce mode pour ce type de scénario.

Tailscale et Docker

Tailscale peut également être intégré dans une infrastructure Docker, par exemple aux côtés d’un outil comme Portainer pour superviser les conteneurs. On peut notamment connecter un conteneur directement au tailnet, ce qui permet de publier certains services uniquement sur le réseau Tailscale, sans jamais les exposer sur le réseau Docker public ni sur Internet.

Cela peut être particulièrement intéressant pour un service d’administration, une API privée, un outil de monitoring, un serveur web interne, un environnement de développement, ou toute interface qui ne doit pas être exposée publiquement. Tailscale fournit d’ailleurs une documentation dédiée à son utilisation avec Docker Compose.

Construire une bonne stratégie de tags

Pour éviter de transformer les tags en véritable jungle, il est préférable de définir une convention dès le départ. Par exemple : tag:server, tag:docker, tag:database, tag:storage, tag:backup, tag:monitoring, tag:management, tag:production et tag:development.

On peut ensuite combiner plusieurs tags, par exemple un serveur PostgreSQL de production portant tag:server, tag:database et tag:production, ou un serveur Docker de développement portant tag:server, tag:docker et tag:development.

Il faut toutefois rester raisonnable : plus un appareil possède de tags, plus la logique d’autorisation devient difficile à comprendre. Tailscale recommande donc de documenter clairement la manière dont les tags sont utilisés dans le tailnet.

Exemple de politique complète pour un homelab

Voici une base volontairement simple, à adapter selon les services réellement présents dans votre homelab :

{
  "tagOwners": {
    "tag:server": [],
    "tag:docker": [],
    "tag:database": [],
    "tag:storage": [],
    "tag:monitoring": [],
    "tag:backup": []
  },

  "grants": [
    {
      "src": ["autogroup:member"],
      "dst": ["tag:server"],
      "ip":  ["tcp:22"]
    },
    {
      "src": ["autogroup:member"],
      "dst": ["tag:monitoring"],
      "ip":  ["tcp:3000"]
    },
    {
      "src": ["tag:docker"],
      "dst": ["tag:database"],
      "ip":  ["*"]
    },
    {
      "src": ["tag:backup"],
      "dst": ["tag:storage"],
      "ip":  ["*"]
    }
  ]
}

Cette configuration illustre une idée importante : on ne donne pas automatiquement accès à tout à tout le monde. On définit précisément qui peut accéder à quoi, et sur quel service. C’est cette approche qui rend Tailscale particulièrement intéressant dans une infrastructure qui commence à prendre de l’ampleur.

Erreurs courantes à éviter

Mettre des tags sur son PC personnel

Les tags sont destinés aux machines d’infrastructure. Pour un ordinateur personnel, mieux vaut conserver l’identité utilisateur Tailscale plutôt que d’y appliquer un tag.

Donner accès à tout, partout

Une règle du type "src": ["*"], "dst": ["*"], "ip": ["*"] est pratique pour démarrer rapidement, mais elle ne permet pas réellement de bénéficier de la segmentation offerte par Tailscale. Elle revient, en pratique, à recréer un simple VPN plat.

Multiplier les tags sans stratégie

Une dizaine de tags bien définis vaut mieux que cinquante tags dont plus personne ne sait réellement à quoi ils servent.

Exposer quand même les services sur Internet

Tailscale est particulièrement intéressant lorsqu’il permet justement de supprimer des ouvertures de ports inutiles. Si Portainer, Proxmox ou SSH n’ont pas besoin d’être accessibles publiquement, il est presque toujours préférable de les rendre accessibles uniquement via le réseau privé.

FAQ

Tailscale est-il gratuit pour un usage personnel ?

Oui, Tailscale propose un plan gratuit destiné à un usage personnel, largement suffisant pour la majorité des homelabs. Les offres payantes ciblent surtout les équipes et les usages professionnels, avec des fonctionnalités de gestion centralisée supplémentaires.

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

Non, pas dans la grande majorité des cas. Tailscale établit des connexions directes chiffrées entre vos appareils grâce à WireGuard. Les serveurs de coordination de Tailscale ne servent qu’à l’authentification et à l’échange des clés, jamais au transport du trafic. Si une connexion directe est impossible (double NAT strict par exemple), le trafic peut transiter par un relais DERP, mais il reste chiffré de bout en bout : Tailscale ne peut pas le lire.

Que se passe-t-il si les serveurs de Tailscale sont indisponibles ?

Les connexions déjà établies entre vos appareils continuent de fonctionner normalement, puisqu’elles reposent sur des tunnels WireGuard directs. Une indisponibilité du plan de contrôle Tailscale peut en revanche empêcher l’ajout de nouveaux appareils ou le renouvellement de certaines clés le temps que le service revienne.

Faut-il un nom de domaine ou une IP publique fixe ?

Non, c’est justement tout l’intérêt de Tailscale. Les appareils peuvent se trouver derrière un NAT classique, un CGNAT d’opérateur mobile ou une IP dynamique : Tailscale se charge d’établir la connexion malgré tout, sans redirection de port ni DNS dynamique à maintenir.

Peut-on retirer un tag une fois qu’il est appliqué ?

Oui, un tag peut être retiré depuis la console d’administration ou en relançant tailscale up avec une liste de tags différente. L’appareil reprend alors les autorisations associées à sa nouvelle identité, ce qui doit être fait avec attention sur une machine en production.

Conclusion

Tailscale est particulièrement adapté aux homelabs parce qu’il permet de résoudre plusieurs problèmes en même temps : créer un réseau privé entre des machines situées sur des réseaux différents, accéder à son infrastructure à distance, éviter d’exposer inutilement des services sur Internet, simplifier l’accès aux machines grâce à MagicDNS, connecter des réseaux entiers grâce aux Subnet Routers, et segmenter les accès grâce aux tags et aux grants.

Pour une petite installation, Tailscale peut simplement servir de VPN pratique. Mais dès qu’un homelab commence à multiplier les serveurs, les conteneurs, les services et les utilisateurs, il devient surtout un outil de segmentation et de gestion des accès. C’est là que les tags prennent tout leur sens : au lieu de gérer une longue liste d’adresses IP, on raisonne simplement en tag:frontend → tag:backend → tag:database, ou pour un homelab en tag:management, tag:server, tag:storage, tag:monitoring et tag:backup.

En résumé : Tailscale permet de transformer un ensemble de machines dispersées en un réseau privé cohérent, tout en gardant un contrôle précis sur qui peut accéder à quoi. Pour un homelab moderne, c’est l’un des outils qui mérite clairement sa place dans la boîte à outils de l’administrateur.

---

Si vous installez Tailscale pour la première fois, commencez par relier deux ou trois machines avec la politique par défaut, vérifiez que MagicDNS fonctionne, puis introduisez progressivement des tags et des grants pour restreindre les accès. C’est la meilleure façon de faire grandir un tailnet sans perdre le contrôle de sa segmentation.

Pour aller plus loin

Tailscale se combine naturellement avec d’autres briques d’un homelab bien organisé. Si vous préférez exposer certains services derrière un nom de domaine plutôt que par MagicDNS, l’article sur Nginx en reverse proxy sur Ubuntu détaille la configuration correspondante — les deux approches sont d’ailleurs complémentaires plutôt qu’exclusives.

La documentation officielle de Tailscale reste la meilleure référence pour les commandes et fonctionnalités présentées dans cet article, notamment pour tout ce qui concerne les tags et les grants.

📡 Soutenir le labo

Sephy-Lab est un projet libre et gratuit. Si tu veux soutenir les expériences et maintenir le système en ligne, tu peux m’aider ici.

Payez-moi un café !