Installer et configurer Tailscale sur un VPS Linux : réseau privé sans ouvrir de ports

Tailscale sur un VPS Linux : un réseau privé virtuel WireGuard sans ouvrir de ports

Tailscale crée un réseau privé virtuel (tailnet) entre vos machines en superposant un tunnel WireGuard chiffré au-dessus de votre connexion Internet existante. Chaque noeud se connecte au serveur de coordination Tailscale, échange ses clés publiques, puis établit des tunnels point-à-point directs via des interfaces réseau virtuelles. Résultat : vos VPS communiquent entre eux sans ouvrir le moindre port public sur le firewall, et sans configurer de NAT traversal manuellement.

Contrairement à un VPN classique comme WireGuard configuré manuellement, Tailscale gère automatiquement la distribution des clés, le routage entre noeuds et la résolution DNS. C'est un atout pour les administrateurs qui gèrent plusieurs VPS Linux en ligne de commande et veulent un accès privé entre eux sans exposer de services sur l'adresse IP publique.

Ce tutoriel couvre l'installation sur un VPS Ubuntu ou Debian, la configuration du serveur, les ACL (listes de contrôle d'accès), le MagicDNS, les routeurs de sous-réseau, et surtout les bonnes pratiques de sécurité à appliquer après la publication des vulnérabilités Tailworm en octobre 2026.

Prérequis

• Un VPS Linux sous Ubuntu 22.04 LTS, Ubuntu 24.04 LTS ou Debian 12, avec un accès root via un shell SSH (configurer une clé SSH sur VPS Linux) ;
• Un nom d'utilisateur et une clé SSH configurés pour l'authentification (les mots de passe doivent être désactivés dans le fichier de configuration sshd_config) ;
• Un compte Tailscale (gratuit jusqu'à 100 appareils sur un tailnet personnel) ;
• Au moins deux machines à relier (deux VPS, ou un VPS et un poste local) avec un accès à Internet.

Installer Tailscale sur le VPS

La méthode officielle utilise le script d'installation fourni par Tailscale. Il détecte la distribution, ajoute le dépôt APT signé et installe les paquets nécessaires :

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

Sur Ubuntu et Debian, le script ajoute le dépôt pkgs.tailscale.com/stable, installe le paquet tailscale et active le service tailscaled via systemd. Vérifiez que le service tourne avec la commande suivante :

systemctl status tailscaled

Pour une installation manuelle sans exécuter de script distant, ajoutez le dépôt et la clé GPG vous-même. Créez le fichier de configuration du dépôt APT :

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg 
  | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list 
  | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt update
sudo apt install -y tailscale

Adaptez noble à votre version (jammy pour Ubuntu 22.04, bookworm pour Debian 12). Vérifiez la version installée :

tailscale version

À la date de publication de ce guide, la version stable est la 1.104.4 ou supérieure. Cette version corrige les vulnérabilités Tailworm détaillées plus bas.

Connecter le VPS au tailnet

Authentifiez le VPS sur votre tailnet avec la commande suivante :

sudo tailscale up

La commande affiche une URL d'authentification dans le shell. Ouvrez-la dans un navigateur, effectuez le login sur votre compte Tailscale et autorisez la machine. Une fois approuvée, le VPS reçoit une adresse IP privée dans la plage 100.x.y.z (CGNAT), attribuée par le serveur de coordination sans DHCP classique.

Vérifiez l'adresse IP attribuée à votre noeud :

tailscale ip -4

Vérifiez la connexion vers un autre noeud déjà présent sur le tailnet :

tailscale ping nom-de-la-machine

Si le ping passe, le tunnel WireGuard est établi. Vos deux machines communiquent sur un réseau privé chiffré, sans qu'aucun port ne soit ouvert sur l'adresse IP publique du VPS. Consultez le log de connexion avec journalctl -u tailscaled pour vérifier que la connexion est directe et ne passe pas par un relais DERP.

MagicDNS : résolution automatique des noms de domaine

MagicDNS est activé par défaut sur les nouveaux tailnets. Il attribue un nom de domaine interne à chaque machine sous la forme nom-machine.tailnet-name.ts.net. Ces alias DNS remplacent les adresses IP dans vos fichiers de configuration, scripts et connexions SSH :

ssh admin@mon-vps.tailnet-name.ts.net

Pour vérifier que MagicDNS est actif, consultez la page DNS de la console d'administration Tailscale. Le domaine MagicDNS apparaît en premier dans la liste des domaines de recherche. Chaque machine est accessible par son alias sans configurer d'enregistrement DNS manuellement.

MagicDNS ne permet pas d'ajouter des enregistrements de nom de domaine personnalisés. Pour un DNS interne complet, configurez un serveur DNS sur votre tailnet et ajoutez-le comme nameserver global dans la console Tailscale.

Configurer un routeur de sous-réseau (subnet router)

Un routeur de sous-réseau Tailscale permet d'exposer un réseau local privé (LAN) situé derrière un VPS à l'ensemble du tailnet, sans installer Tailscale sur chaque machine de ce réseau local. C'est utile pour accéder à des équipements qui ne supportent pas Tailscale (routeurs physiques, imprimantes réseau, serveurs de stockage) ou à un réseau local de serveurs dédiés en housing en datacenter.

Sur le VPS qui servira de routeur, activez la fonction de routeur de sous-réseau en annonçant les plages d'adresses IP du réseau local :

sudo tailscale up --advertise-routes=192.168.1.0/24,10.0.0.0/24

Remplacez les plages par celles de votre réseau local. Les interfaces Ethernet du VPS doivent être configurées pour permettre le forwarding IP. Activez-le dans le fichier de configuration du noyau :

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Dans la console d'administration Tailscale, approuvez les routes annoncées par le routeur. Les autres noeuds du tailnet peuvent ensuite joindre les machines du réseau local via les adresses IP privées annoncées, comme si elles étaient sur le même réseau.

Pour limiter quels noeuds ont accès aux routes du routeur, configurez des ACL spécifiques dans la politique d'accès (voir la section ACL ci-dessous).

Configurer les ACL pour restreindre les accès

Par défaut, chaque appareil d'un tailnet personnel peut joindre tous les autres sur tous les ports TCP et UDP. En production, c'est trop permissif. Les ACL (Access Control Lists) de Tailscale appliquent un modèle deny-by-default : seuls les flux explicitement autorisés passent.

Les configurations ACL se gèrent dans la console d'administration, onglet Access Controls, au format HuJSON (fichier de configuration JSON avec commentaires). Exemple minimal qui autorise un groupe d'administrateurs à accéder à tout, et les noeuds de production à ne communiquer qu'entre eux sur les ports TCP 443 et 5432 :

{
  "groups": {
    "group:admin": ["user@example.com"],
    "group:prod":  ["tag:production"]
  },
  "acls": [
    {"action": "accept", "src": ["group:admin"], "dst": ["*:*"]},
    {"action": "accept", "src": ["group:prod"], "dst": ["group:prod:443,5432"]}
  ]
}

Attribuez des tags à vos machines pour les regrouper par rôle. Un VPS de production reçoit le tag tag:production, un VPS d'administration reçoit tag:admin. Les tags se définissent dans la section tagOwners du fichier de politique (conf), puis s'appliquent machine par machine dans la console ou via la ligne de commande :

sudo tailscale up --advertise-tags=tag:production

Les ACL sont configurées pour permettre uniquement les connexions déclarées. Elles sont appliquées localement sur chaque noeud, sans dépendre du serveur de coordination. En cas de coupure du control plane, les règles restent actives.

Vulnérabilités Tailworm : ce qui s'est passé

Le 25 octobre 2026, la chercheuse Erica Windisch (Cyberdione Labs) a publié Tailworm, un rapport de 11 failles dans Tailscale SSH et Tailscale Serve. Tailscale a répondu avec quatre bulletins de sécurité (TS-2026-014 à TS-2026-017) et a publié la version corrective 1.104.4 le 28 octobre 2026.

Les failles les plus critiques :

• TS-2026-014 (Tailscale SSH, critique) : le transfert local de sockets Unix (ssh -L) s'exécutait en tant que root. Un pair authentifié pouvait atteindre des sockets accessibles uniquement à root, comme le socket Docker ou le daemon systemd ;
• TS-2026-015 (Tailscale SSH, élevée) : un pair authentifié pouvait provoquer une consommation mémoire illimitée via des messages de redimensionnement de fenêtre en boucle, causant un déni de service sur le noeud ;
• TS-2026-016 (Tailscale Serve, critique) : les transferts TCP vers des sockets Unix s'exécutaient en tant que root et la vérification de lien symbolique n'intervenait qu'à la configuration initiale, permettant une escalade de privilèges ;
• TS-2026-017 (Tailscale Serve, modérée) : une condition de concurrence avec TLS pouvait provoquer une fuite de capacités entre requêtes HTTP/2.

Aucun CVE n'a été attribué à ces failles. Les logs d'audit Tailscale ne montrent pas d'exploitation active à ce jour.

Bonnes pratiques de sécurité post-Tailworm

Les correctifs sont intégrés à la version 1.104.4. Mais les failles Tailworm rappellent que tout logiciel qui s'interpose dans la chaîne SSH ajoute une surface d'attaque. Voici les mesures à appliquer sur la configuration de vos serveurs VPS Linux.

1. Mettre à jour Tailscale immédiatement

Vérifiez votre version et mettez à jour les paquets :

tailscale version
sudo apt update && sudo apt install --only-upgrade tailscale

Vous devez être en 1.104.4 ou supérieure. Consultez le log du service après la mise à jour pour confirmer le redémarrage :

sudo journalctl -u tailscaled --since "5 minutes ago"

2. Préférer SSH classique (OpenSSH) à Tailscale SSH

Tailscale SSH est pratique : il remplace le daemon OpenSSH par un serveur SSH intégré au client Tailscale, avec un login SSO via votre fournisseur d'identité. Mais cela signifie qu'une faille dans Tailscale donne un accès shell à vos machines. Sur un VPS de production, conservez OpenSSH comme serveur SSH principal et utilisez Tailscale uniquement comme couche réseau (tunnel WireGuard). Pour durcir votre fichier de configuration OpenSSH : sécuriser SSH sur VPS Linux.

3. Désactiver le forwarding Unix sur Tailscale SSH

Si vous utilisez Tailscale SSH malgré tout, désactivez le transfert de sockets Unix, vecteur principal des failles TS-2026-014 et TS-2026-016. Ajoutez la variable d'environnement au service systemd :

sudo systemctl edit tailscaled

Dans l'éditeur, ajoutez :

[Service]
Environment="TS_SSH_DISABLE_FORWARDING=1"

Puis rechargez la configuration et redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart tailscaled

Le forwarding est désactivé, mais les sessions SSH interactives et l'accès shell restent fonctionnels.

4. Désactiver l'authentification par mot de passe sur OpenSSH

Si vous conservez le daemon OpenSSH actif sur le VPS (recommandé), vérifiez que les mots de passe sont désactivés dans le fichier de configuration /etc/ssh/sshd_config :

PasswordAuthentication no
PubkeyAuthentication yes

Après modification du fichier de conf, redémarrez le service SSH :

sudo systemctl restart sshd

L'authentification par clé publique est plus sûre que les mots de passe et réduit la surface d'attaque sur le port SSH public. Consultez l'analyse des logs de connexion SSH pour surveiller les tentatives de login échouées.

5. Séparer les noeuds admin des noeuds production

Avec les ACL vues plus haut, isolez vos VPS de production dans un groupe distinct. Un noeud de production compromis ne doit pas pouvoir atteindre les autres noeuds du tailnet. L'idéal : un tag tag:production sans droit d'accès vers tag:admin, et un tag tag:admin avec accès restreint aux ports d'administration uniquement.

6. Activer la journalisation des connexions

Activez les logs de connexion Tailscale dans la console d'administration pour garder une trace de chaque connexion entre noeuds. En complément, auditd sur VPS Linux enregistre les accès root et les modifications de fichiers de configuration au niveau du système d'exploitation.

Tailscale SSH vs OpenSSH classique via tunnel Tailscale

Tailscale et le firewall du VPS

Tailscale crée une interface réseau virtuelle tailscale0 sur le VPS, séparée de l'interface Ethernet physique (eth0 ou ens3). Le trafic du tailnet passe par cette interface virtuelle, pas par l'interface publique. Vos règles UFW ou nftables sur l'interface publique restent inchangées. Les paquets réseau entre machines du tailnet sont déjà chiffrés par WireGuard.

Si vous souhaitez filtrer les paquets sur l'interface Tailscale (pour segmenter davantage au niveau noyau, en complément des ACL), vous pouvez ajouter des règles nftables spécifiques à tailscale0. Consultez notre guide nftables et pare-feu sur VPS Linux pour la syntaxe.

Point important : Tailscale ne nécessite aucun port entrant ouvert sur le firewall. Le client établit une connexion sortante vers le serveur de coordination et utilise le NAT traversal (STUN) pour les tunnels directs. Si la connexion directe échoue, le trafic passe par un relais DERP (proxy TCP chiffré) hébergé par Tailscale. C'est le principal avantage par rapport à un VPN WireGuard classique qui exige un port UDP ouvert sur le firewall.

Aller plus loin

• Combinez Tailscale avec Fail2ban sur le daemon OpenSSH pour bloquer les tentatives de brute force sur le port SSH public (que vous pouvez conserver en parallèle du tunnel Tailscale) ;
• Utilisez tailscale up --accept-routes pour accéder aux sous-réseaux annoncés par les routeurs de sous-réseau du tailnet ;
• Activez la fonctionnalité Exit Node sur un VPS pour router l'accès à Internet d'un poste local via le VPS, comme un VPN classique. La configuration de l'exit node se gère via la ligne de commande et les ACL ;
• Tailscale fonctionne aussi sous Windows, macOS et sur les routeurs compatibles. Pour un tailnet mixte, installez le client sur chaque système d'exploitation et gérez les accès par tags dans les ACL ;
• Surveillez vos connexions et ressources avec Grafana et Prometheus pour un monitoring complet de votre infrastructure.

Conclusion

Tailscale simplifie la création d'un réseau privé virtuel entre VPS Linux en s'appuyant sur WireGuard, sans ouvrir de ports ni configurer de clés manuellement. Le MagicDNS fournit des alias de nom de domaine pour chaque noeud, les ACL segmentent les accès, et les routeurs de sous-réseau permettent d'intégrer un réseau local existant au tailnet.

Les vulnérabilités Tailworm d'octobre 2026 rappellent cependant qu'un outil de réseau privé n'est pas un outil de sécurité magique. Sur un VPS de production, la recommandation est claire : utilisez Tailscale comme tunnel réseau, conservez OpenSSH comme serveur SSH, désactivez le forwarding de sockets Unix et séparez vos noeuds par rôle dans les ACL. Un VPS Linux ElypseCloud avec accès root vous donne le contrôle complet sur ces configurations.