Tailscale sur Proxmox : hôte, conteneur LXC ou VM ?

Où installer Tailscale sur Proxmox ?

Pour joindre l'interface web de Proxmox VE (port 8006) et vos machines invitées depuis l'extérieur, installez Tailscale à l'un de trois endroits : sur l'hôte Proxmox lui-même, dans un conteneur LXC non privilégié qui sert de routeur de sous-réseau, ou dans une VM. Dans les trois cas, vous n'ouvrez aucun port sur la Freebox ou la Livebox. Le choix porte sur une seule question : quelle machine rejoint votre tailnet, c'est-à-dire votre réseau privé Tailscale ?

Une règle vaut pour tout le guide : le port 8006 n'est jamais redirigé sur la box. Aucune règle NAT (traduction d'adresses réseau) ne pointe vers l'hyperviseur. Tailscale établit des connexions sortantes. Les deux pairs se rejoignent ensuite directement, ou passent par un relais DERP de Tailscale quand la connexion directe échoue. C'est aussi pour cela que l'approche fonctionne quand Free vous attribue une IPv4 partagée : vous n'avez pas de plage de ports à négocier. Si vous redirigez encore des ports pour d'autres services, remplacer la redirection de ports par Tailscale suit la même logique, service par service.

Les trois options, et ce que chacune expose

Sur l'hôte Proxmox. C'est le chemin le plus court vers l'interface : l'hôte devient un nœud du tailnet, et https://pve.votre-tailnet.ts.net mène directement à pveproxy. Le prix est clair. L'hyperviseur, la machine qui contrôle toutes les autres, fait maintenant partie du tailnet. Un appareil compromis dans ce tailnet voit l'hôte comme un voisin de réseau local, sauf si vos règles d'accès (ACL, listes de contrôle d'accès) le limitent.

Dans un conteneur LXC non privilégié. Le conteneur rejoint le tailnet et annonce votre réseau local, par exemple 192.168.1.0/24. L'hôte ne fait aucun routage et n'exécute aucun logiciel de plus. Vous atteignez l'interface par son adresse locale, https://192.168.1.10:8006. C'est l'option la plus légère qui garde Tailscale hors de l'hyperviseur, et c'est le cœur de ce guide.

Dans une VM. Une petite VM Debian avec Tailscale. Elle a son propre noyau, donc /dev/net/tun existe sans aucune configuration. C'est l'option la plus lourde (une VM réserve sa mémoire, et elle a son propre système à mettre à jour), mais c'est la plus propre : un problème dans la VM reste dans la VM. Choisissez-la si vous voulez plus tard en faire un nœud de sortie (exit node), ou si vous ne voulez rien changer à la configuration de vos conteneurs.

Mon conseil pour un homelab classique : un conteneur LXC en routeur de sous-réseau pour les invités, et Tailscale sur l'hôte seulement si un nom HTTPS valide pour l'interface vous importe vraiment. Les deux peuvent coexister.

Installer depuis le dépôt officiel de Tailscale

Quelle que soit l'option, installez le paquet depuis le dépôt stable de Tailscale, pas depuis un script tiers ni depuis un paquet de distribution qui peut avoir des mois de retard. Proxmox VE 9 repose sur Debian 13 (Trixie), Proxmox VE 8 sur Debian 12 (Bookworm). Prenez la version de Debian de la machine où vous installez : l'hôte, ou le modèle du conteneur.

Le shell de Proxmox et celui d'un conteneur Debian ouvrent une session root, et sudo n'y est souvent pas installé. Les commandes ci-dessous s'exécutent donc en root, sans sudo. Pour Debian 13 :

apt-get update && apt-get install -y curl
mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/debian/trixie.noarmor.gpg | tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/debian/trixie.tailscale-keyring.list | tee /etc/apt/sources.list.d/tailscale.list
apt-get update && apt-get install -y tailscale

Sur Debian 12, remplacez trixie par bookworm dans les deux URL. Vérifiez ensuite que le service tourne :

systemctl status tailscaled
tailscale version

systemctl status doit afficher active (running). Si le service est en échec dans un conteneur, la cause est presque toujours l'accès à /dev/net/tun, traité plus bas.

Option 1 : Tailscale sur l'hôte, et un vrai certificat pour le port 8006

Sur l'hôte, après l'installation :

tailscale up

La commande affiche une URL de connexion. Ouvrez-la dans un navigateur et validez la machine dans votre compte. tailscale status doit ensuite lister l'hôte avec une adresse en 100.x.y.z.

Par défaut, pveproxy présente un certificat autosigné, donc le navigateur affiche un avertissement à chaque visite. Tailscale peut fournir un certificat valide pour le nom machine.votre-tailnet.ts.net. Activez d'abord HTTPS dans la console d'administration : page DNS, MagicDNS activé, puis « Enable HTTPS » sous HTTPS Certificates. Lisez l'avertissement avant de valider. Chaque certificat est inscrit dans les journaux publics Certificate Transparency, donc le nom de la machine et le nom DNS du tailnet deviennent publics. Renommez la machine avant si son nom en dit trop.

Ensuite, Tailscale documente deux méthodes dans sa page consacrée à Proxmox.

Méthode A : tailscale serve. Tailscale reçoit les connexions HTTPS sur le port 443 de son adresse tailnet, puis les transmet à pveproxy en local :

tailscale serve --bg https+insecure://localhost:8006
tailscale serve status

Le préfixe https+insecure:// dit à Tailscale que la cible parle HTTPS avec un certificat qu'il ne doit pas vérifier. C'est exactement le cas du certificat autosigné de pveproxy. --bg laisse la configuration active en arrière-plan. tailscale serve status affiche l'adresse à utiliser, de la forme https://pve.votre-tailnet.ts.net. Pour tout retirer : tailscale serve reset.

Méthode B : remplacer le certificat de pveproxy. Vous gardez le port 8006, mais avec un certificat valide. Tailscale publie ce script, qui demande jq (apt-get install -y jq) :

#!/bin/bash
NAME="$(tailscale status --json | jq '.Self.DNSName | .[:-1]' -r)"
tailscale cert "${NAME}"
pvenode cert set "${NAME}.crt" "${NAME}.key" --force --restart

Enregistrez-le, par exemple sous /root/update_cert.sh, rendez-le exécutable avec chmod +x /root/update_cert.sh, et lancez-le une fois. https://pve.votre-tailnet.ts.net:8006 doit alors s'ouvrir sans avertissement. Ces certificats ont une durée de vie limitée, donc Tailscale conseille de relancer le script par cron toutes les 12 heures (crontab -e) :

0 */12 * * * /root/update_cert.sh

Les deux méthodes restent internes au tailnet. tailscale serve ne publie rien sur Internet. C'est tailscale funnel qui le ferait, et l'interface d'un hyperviseur n'a rien à y faire. La différence est détaillée dans Tailscale Serve ou Funnel : ce que chacun rend public.

Option 2 : un conteneur LXC non privilégié en routeur de sous-réseau

Créez un conteneur Debian non privilégié classique, avec une adresse fixe sur votre réseau local (par exemple 192.168.1.20). Une petite taille suffit : un cœur et 512 Mo de mémoire font l'affaire pour un routeur de sous-réseau de homelab. Dans les exemples, son identifiant (CTID) est 110.

Pourquoi tailscaled ne démarre pas dans le conteneur

Tailscale crée une interface réseau virtuelle, tailscale0, et pour cela il ouvre le périphérique /dev/net/tun. Un conteneur non privilégié n'a pas ce périphérique, parce que LXC n'expose au conteneur que les périphériques que l'hôte autorise. Sans lui, tailscaled ne peut pas créer son interface. Le service échoue donc au démarrage, et tailscale up ne peut pas le joindre. Lisez la cause exacte avec journalctl -u tailscaled -n 50 : le journal mentionne /dev/net/tun.

La correction se fait sur l'hôte, pas dans le conteneur. Elle dépend de la version de Proxmox VE.

Proxmox VE 8.1 et suivants, y compris 9.x : l'option dev0

Depuis la version 8.1, Proxmox sait passer un périphérique de l'hôte à un conteneur avec les options dev0, dev1, etc. Les versions récentes proposent aussi cette option dans l'interface web (onglet Resources, Add, Device Passthrough, chemin /dev/net/tun). En ligne de commande, sur l'hôte :

pct set 110 --dev0 /dev/net/tun
pct set 110 --features keyctl=1,nesting=1
pct reboot 110

La première ligne passe le périphérique TUN. La seconde reprend les options que la documentation de Tailscale indique pour LXC : keyctl donne au conteneur l'accès au trousseau de clés du noyau, et nesting expose procfs et sysfs, ce que systemd utilise pour isoler ses services. Le redémarrage est nécessaire, car le périphérique n'est ajouté qu'au démarrage du conteneur. En octobre 2026, c'est la méthode à utiliser de la 8.1 à la 8.4 et sur toute la branche 9.x.

Vérifiez depuis le conteneur :

pct enter 110
ls -l /dev/net/tun

La ligne doit commencer par c (un périphérique de type caractère) et porter les numéros 10, 200. Si le fichier n'existe pas, le conteneur n'a pas redémarré, ou l'option ne figure pas dans /etc/pve/lxc/110.conf sur l'hôte.

Proxmox VE 7 et 8.0 : les lignes LXC brutes

Avant la 8.1, l'option dev0 n'existe pas. Ajoutez ces deux lignes à la fin de /etc/pve/lxc/110.conf sur l'hôte, puis redémarrez le conteneur :

lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

La première ligne autorise le périphérique de type caractère 10:200 (c'est /dev/net/tun) dans le cgroup du conteneur. La seconde monte le fichier de l'hôte dans le conteneur. Le préfixe cgroup2 compte, car Proxmox VE 7 et 8 utilisent cgroup v2. L'ancienne forme lxc.cgroup.devices.allow ne concerne que Proxmox 6 et avant, et Proxmox VE 9 a retiré le support de cgroup v1. Sur une version qui connaît dev0, préférez dev0 : une seule option, visible dans l'interface.

Le mode userspace : l'alternative documentée, avec son coût

Tailscale documente un autre chemin : le mode « userspace networking ». Dans ce mode, tailscaled gère le réseau lui-même, sans /dev/net/tun ni interface tailscale0. On l'active avec l'option --tun=userspace-networking. Sur Debian, les options du service se placent dans la ligne FLAGS= de /etc/default/tailscaled.

Ce mode a un coût réel. Sans interface tailscale0, les programmes du conteneur ne voient pas le tailnet comme un réseau. Pour sortir vers le tailnet, ils doivent passer par un proxy SOCKS5 ou HTTP que tailscaled expose, et le proxy HTTP ne transporte que HTTP et HTTPS. Tailscale présente ce mode d'abord pour les environnements où l'on ne contrôle pas l'hôte, et sa page sur ce mode ne documente pas le rôle de routeur de sous-réseau. Sur un Proxmox que vous administrez, passez /dev/net/tun : c'est une ligne de configuration.

Activer le transfert IP et annoncer le réseau local

Un routeur de sous-réseau transmet des paquets qui ne lui sont pas destinés. Linux les rejette par défaut, donc activez le transfert IP dans le conteneur :

echo 'net.ipv4.ip_forward = 1' | tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | tee -a /etc/sysctl.d/99-tailscale.conf
sysctl -p /etc/sysctl.d/99-tailscale.conf
sysctl net.ipv4.ip_forward

La dernière commande doit afficher net.ipv4.ip_forward = 1. Le fichier dans /etc/sysctl.d/ garde le réglage après un redémarrage, ce que ne fait pas un sysctl -w isolé. Connectez ensuite le conteneur et annoncez le réseau de la box :

tailscale up
tailscale set --advertise-routes=192.168.1.0/24

La Livebox utilise par défaut le réseau 192.168.1.0/24, et c'est aussi le cas courant derrière une Freebox. Vérifiez le vôtre avec ip route dans le conteneur. N'annoncez pas plus large que nécessaire : si vos VM sont sur un pont séparé, annoncez seulement ce sous-réseau.

Sur Linux, Tailscale fait par défaut une traduction d'adresse source sur ces routes. Les machines du réseau local voient donc les connexions arriver depuis l'adresse du conteneur, et vous n'avez aucune route de retour à déclarer sur la box.

Approuver les routes annoncées

Une route annoncée n'est pas active tant qu'un administrateur ne l'a pas approuvée. Dans la console d'administration, page Machines, le conteneur porte le badge Subnets. Ouvrez la machine, section Subnets, cliquez sur Edit et cochez 192.168.1.0/24 sous Subnet routes.

Côté clients, Windows, macOS, iOS et Android prennent les nouvelles routes tout seuls. Un client Linux doit les accepter explicitement :

sudo tailscale set --accept-routes

Testez depuis votre téléphone en 4G, Wi-Fi coupé : https://192.168.1.10:8006 doit afficher la page de connexion de Proxmox. L'avertissement de certificat reste là, puisque vous passez par l'adresse locale. Si rien ne répond, tailscale status dans le conteneur indique si le nœud est connecté, et la console indique si la route est bien approuvée.

Un piège fréquent en France : le Wi-Fi d'un ami, d'un gîte ou d'un hôtel derrière une autre Livebox utilise lui aussi 192.168.1.0/24. Dans ce cas, 192.168.1.10 est d'abord cherché sur le réseau local où vous vous trouvez, donc la connexion n'atteint jamais votre Proxmox. Deux solutions : renuméroter votre réseau domestique (par exemple 192.168.42.0/24 dans les réglages DHCP de la box), ou passer par le nom tailnet de l'hôte de l'option 1, qui n'entre jamais en conflit.

Désactiver l'expiration de clé sur le nœud permanent

Par défaut, la clé d'un appareil expire au bout de 180 jours. Sur un ordinateur portable, c'est une sécurité. Sur un routeur de sous-réseau ou un hyperviseur sans écran, c'est une panne programmée. Le nœud quitte le tailnet le jour de l'expiration, et vous perdez l'accès distant au moment où vous n'êtes pas chez vous pour le reconnecter.

Dans la console, page Machines, ouvrez le menu à droite de la ligne du nœud et choisissez Disable Key Expiry. Faites-le pour le conteneur, et pour l'hôte s'il est aussi dans le tailnet. Un appareil qui reçoit un tag à sa première authentification a déjà l'expiration désactivée. Si vous utilisez des tags, ce réglage est donc fait.

Désactiver l'expiration rend chaque clé plus précieuse. Le jour où vous voulez que la console d'administration ne puisse plus ajouter un nœud sans votre accord, Tailnet Lock et la signature des nouveaux nœuds ajoute ce contrôle.

Option 3 : une VM, la solution la plus isolée

Une VM Debian avec deux cœurs et 1 Go de mémoire suffit. Installez Tailscale depuis le dépôt comme plus haut, puis suivez les mêmes étapes que pour le conteneur : transfert IP, --advertise-routes, approbation, expiration désactivée. Aucune configuration de /dev/net/tun n'est nécessaire, puisque la VM a son propre noyau. Vous payez cette isolation en mémoire réservée et en un système de plus à maintenir. Pour comparer ces modèles d'isolation au-delà de Tailscale, KVM, Xen ou LXC : ce que chaque virtualisation partage avec l'hôte reprend la différence entre un conteneur et une VM.

Ajouter un VPS dans le même tailnet

Un serveur à la maison et un VPS loué se complètent bien. Le VPS rejoint le même tailnet que votre Proxmox, et les deux communiquent sans port ouvert d'un côté comme de l'autre.

Le premier usage est la sauvegarde hors site. Un Proxmox Backup Server sur le VPS reçoit les sauvegardes de vos VM à travers le tailnet. Une coupure de courant ou un cambriolage ne détruit alors plus à la fois les données et leurs copies. Le guide installer Proxmox Backup Server sur un VPS couvre cette mise en place. Le second usage est la façade publique. Le VPS a une IPv4 fixe et dédiée, il reçoit le trafic d'Internet, et un proxy inverse le transmet à un service de votre homelab par le tailnet. Votre box reste fermée. Le sens inverse marche aussi, avec un VPS en routeur de sous-réseau pour exposer au tailnet un réseau privé hébergé chez un fournisseur.

Ce qui reste chez vous et ce qui va sur le VPS dépend de la charge et de la disponibilité attendue. La comparaison Proxmox à la maison ou VPS loué aide à faire ce partage.

FAQ

Faut-il ouvrir le port 8006 sur la Freebox ou la Livebox pour Tailscale ?

Non. Tailscale n'a besoin d'aucune redirection de port : chaque nœud ouvre des connexions sortantes, puis les pairs se joignent directement ou par un relais DERP. Le port 8006 de Proxmox ne doit jamais être redirigé sur la box. L'interface reste joignable uniquement depuis les appareils de votre tailnet, par l'adresse locale via un routeur de sous-réseau, ou par le nom ts.net de l'hôte.

Pourquoi Tailscale ne démarre pas dans mon conteneur LXC Proxmox ?

Un conteneur LXC non privilégié n'a pas accès à /dev/net/tun, donc tailscaled ne peut pas créer l'interface tailscale0. Sur Proxmox VE 8.1 et suivants, y compris 9.x, exécutez sur l'hôte pct set CTID --dev0 /dev/net/tun et pct set CTID --features keyctl=1,nesting=1, puis redémarrez le conteneur. Sur Proxmox 7 et 8.0, ajoutez les lignes lxc.cgroup2.devices.allow: c 10:200 rwm et lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file au fichier /etc/pve/lxc/CTID.conf.

Comment supprimer l'avertissement de certificat de l'interface Proxmox ?

Installez Tailscale sur l'hôte, activez HTTPS dans la page DNS de la console d'administration, puis lancez tailscale serve --bg https+insecure://localhost:8006. L'interface est alors servie en HTTPS valide sous https://nom-de-l-hote.votre-tailnet.ts.net. L'autre méthode remplace le certificat de pveproxy avec tailscale cert et pvenode cert set, relancés par cron toutes les 12 heures. Dans les deux cas, le nom de la machine apparaît dans les journaux publics Certificate Transparency.

Vaut-il mieux installer Tailscale sur l'hôte Proxmox ou dans un conteneur ?

Sur l'hôte, l'accès à l'interface est le plus direct et vous obtenez un nom HTTPS valide, mais l'hyperviseur rejoint le tailnet. Dans un conteneur LXC non privilégié en routeur de sous-réseau, l'hôte ne fait aucun routage, et vous atteignez l'interface et les invités par leurs adresses locales. Une VM isole encore mieux, au prix de mémoire réservée. Pour un homelab, le conteneur est le bon point de départ.

Pourquoi mon Proxmox disparaît du tailnet après quelques mois ?

La clé du nœud a expiré : par défaut, une clé d'appareil Tailscale expire après 180 jours. Dans la console d'administration, page Machines, ouvrez le menu du nœud et choisissez Disable Key Expiry. Faites-le pour chaque nœud permanent, routeur de sous-réseau compris. Un appareil authentifié avec un tag a déjà l'expiration désactivée.