Configurer votre VPS comme exit node Tailscale

Ce que fait un exit node Tailscale

Un exit node Tailscale est une machine de votre tailnet qui achemine tout le trafic Internet de vos autres appareils. Un VPS (virtual private server) convient bien, car il dispose d’une adresse publique fixe et reste en ligne. Sa configuration se déroule en cinq étapes : installer Tailscale sur le serveur, annoncer l’exit node, activer le forwarding IP, approuver la route dans la console d’administration, puis sélectionner le nœud sur votre ordinateur portable. La quatrième étape consiste à activer une option dans une page web, et non à exécuter une commande. C’est à cette étape que la plupart des utilisateurs restent bloqués.

Une fois cette configuration active, votre ordinateur portable chiffre chaque paquet et l’envoie au VPS. Le VPS applique un NAT source (network address translation), puis transmet le paquet avec sa propre adresse IP publique. Les sites web voient l’adresse du VPS. Le Wi-Fi du café ne voit qu’un flux UDP chiffré vers le VPS, et rien d’autre.

Tailscale utilise WireGuard pour le data path, ainsi qu’un serveur de coordination qui distribue les clés et aide deux machines à se trouver à travers le NAT. Ce serveur de coordination explique pourquoi aucune copie de clé n’est nécessaire dans les étapes ci-dessous. Pour une présentation détaillée des compromis, consultez la comparaison entre Tailscale et WireGuard classique. Si vous préférez gérer vous-même chaque composant du tunnel, hébergez plutôt un VPN WireGuard classique sur votre VPS.

Les étapes ci-dessous supposent que Tailscale fonctionne déjà sur votre ordinateur portable et que les deux machines se connectent au même tailnet. Un tailnet est votre réseau Tailscale privé. Chaque appareil qui en fait partie reçoit une adresse stable dans 100.64.0.0/10.

Installer Tailscale sur votre VPS

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

Le script d’installation sélectionne le dépôt de paquets adapté à votre distribution et installe le daemon tailscaled. tailscale up affiche ensuite une URL d’authentification. Ouvrez-la dans un navigateur et connectez-vous avec le même compte que celui utilisé par votre ordinateur portable, car un VPS connecté à un autre tailnet ne peut pas servir votre ordinateur portable.

tailscale status
tailscale ip -4

tailscale status doit maintenant lister les deux machines. tailscale ip -4 affiche l’adresse tailnet du VPS. C’est cette adresse que vous transmettrez au client plus tard.

Tailscale a besoin d’un périphérique TUN pour établir le tunnel. Sur un VPS KVM, ce périphérique est disponible. Sur les offres utilisant une virtualisation par conteneurs qui partagent le kernel de l’hôte, /dev/net/tun est parfois absent, et tailscaled ne peut pas créer l’interface tailscale0. Exécutez ls -l /dev/net/tun avant de poursuivre.

Activer le transfert IP, sinon le VPS abandonne tous les paquets

Une machine Linux abandonne tout paquet qui ne lui est pas destiné, car net.ipv4.ip_forward vaut 0 par défaut. Le nœud de sortie accepterait votre trafic, le déchiffrerait, puis le supprimerait. Écrivez ce paramètre dans un fichier pour qu’il survive à un redémarrage.

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

tee -a ajoute le contenu à la fin du fichier. Si vous exécutez ces lignes une deuxième fois, les deux paramètres seront donc écrits deux fois. Le résultat reste fonctionnel, mais cat /etc/sysctl.d/99-tailscale.conf aura un contenu inhabituel. Vérifiez la valeur active au lieu de vous fier au fichier :

sysctl net.ipv4.ip_forward

La commande doit afficher net.ipv4.ip_forward = 1. Si vous ignorez cette étape et utilisez tailscale up --advertise-exit-node, le client vous indique :

Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.

tailscale set --advertise-exit-node n’effectue pas cette vérification. L’absence de sortie de set ne prouve donc pas que le transfert est activé. Lisez vous-même la valeur sysctl.

Vous n’avez pas besoin d’écrire manuellement une règle de masquerade. tailscaled installe ses propres chaînes de pare-feu, nommées ts-input, ts-forward et ts-postrouting. La règle NAT pour le trafic du nœud de sortie se trouve dans ts-postrouting. Affichez-les avec sudo iptables-save | grep ts-, ou avec sudo nft list ruleset sur une machine nftables.

Publier le VPS comme exit node

sudo tailscale set --advertise-exit-node

tailscale set modifie une préférence et laisse les autres inchangées. tailscale up --advertise-exit-node publie également le nœud, mais avec un effet secondaire : up considère les flags fournis sur sa ligne de commande comme l’ensemble complet des paramètres non définis par défaut. Un sudo tailscale up exécuté seul plus tard refuse alors de s’exécuter et affiche

changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

Utilisez set pour les modifications ultérieures afin de ne jamais rencontrer ce message.

La publication constitue une proposition. Le VPS indique maintenant au coordination server qu’il accepte de servir d’exit node. Aucun client ne peut encore l’utiliser.

Approuver le nœud de sortie Tailscale dans la console d’administration

Cette étape ne comporte aucune commande. Ouvrez la page Machines de la console d’administration, trouvez le VPS, ouvrez le menu à trois points à la fin de sa ligne, choisissez Edit route settings, puis activez Use as exit node.

Tant que cette option n’est pas activée, le control plane conserve la proposition sans l’attribuer. tailscale exit-node list sur votre ordinateur portable n’affiche rien et votre trafic conserve son routage habituel. Aucun message d’erreur n’apparaît sur l’une ou l’autre machine. Le nœud de sortie n’est tout simplement jamais proposé.

Vous pouvez approuver automatiquement les nœuds de sortie avec une entrée dans le fichier de policy du tailnet :

"autoApprovers": {
  "exitNode": ["tag:exit"],
}

Un appareil démarré avec --advertise-tags=tag:exit est alors approuvé automatiquement, à condition que tag:exit soit défini sous tagOwners dans le même fichier de policy. L’ajout d’un tag modifie la propriété : un appareil tagué appartient au tailnet plutôt qu’à votre compte utilisateur, et les règles d’accès qui s’y appliquent changent en conséquence. Pour un seul VPS, l’option de la console est plus simple.

Sélectionner le nœud de sortie sur votre ordinateur portable

Sur un client Linux :

tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.net

exit-node list affiche les nœuds de sortie approuvés dans votre tailnet, avec leurs adresses. Une liste vide signifie que l’étape d’approbation n’a pas été effectuée. Sous macOS, Windows, iOS et Android, la même option se trouve dans le menu Exit Node de l’application Tailscale.

Vérifiez depuis le client, jamais depuis le serveur :

curl -4 https://ifconfig.me

Exécutez cette commande une fois avant de sélectionner le nœud de sortie, puis une fois après. L’adresse doit passer de votre adresse locale à l’adresse IP publique du VPS. Pour arrêter d’utiliser le nœud de sortie :

sudo tailscale set --exit-node=

Un autre flag est important dès le premier jour. Lorsqu’un nœud de sortie est sélectionné, le client envoie tout le trafic dans le tunnel, y compris les paquets destinés à 192.168.1.50. Votre imprimante et votre stockage réseau cessent alors de répondre. Conservez le réseau local sur la route locale :

sudo tailscale set --exit-node=<name> --exit-node-allow-lan-access=true

Pourquoi votre DNS change dès que le nœud de sortie est activé

Par défaut, un appareil qui utilise un nœud de sortie utilise également ce nœud de sortie comme résolveur DNS (domain name system) pour tous les domaines. Cela remplace les serveurs DNS globaux et split DNS configurés pour votre tailnet. Ce comportement est volontaire. Si les requêtes continuaient à être envoyées au résolveur du réseau local, le routeur du café verrait encore le nom de chaque site que vous consultez, alors que le trafic lui-même resterait privé. Les noms et les paquets doivent sortir du même endroit.

Cela pose notamment problème aux personnes qui utilisent un résolveur interne : un serveur de noms du tailnet dont vous dépendez cesse d’être utilisé lorsque le nœud de sortie est activé. Activez Use with exit node pour ce serveur de noms dans la page DNS de la console d’administration afin de le rétablir.

Les noms MagicDNS continuent de fonctionner, car le client Tailscale y répond localement à 100.100.100.100 avant que quoi que ce soit n’atteigne le nœud de sortie. Vérifiez-le avec dig @100.100.100.100 your-vps.your-tailnet.ts.net ou, sur un client systemd-resolved, avec resolvectl status : l’interface Tailscale y indique 100.100.100.100 comme serveur DNS.

Si vous désactivez la gestion DNS de Tailscale avec --accept-dns=false, le client conserve le résolveur fourni par le réseau local. Le trafic est tunnelisé, mais pas les requêtes DNS. Il s’agit de la même fuite DNS qui affecte les tunnels WireGuard configurés manuellement. Ne modifiez pas --accept-dns, sauf si vous avez une raison précise de le faire.

IPv6 via le nœud de sortie

Un nœud de sortie annonce les deux routes par défaut, 0.0.0.0/0 et ::/0. Si le VPS ne dispose d’aucun chemin IPv6 fonctionnel vers Internet, les paquets IPv6 arrivent par le tunnel, puis s’arrêtent sur le VPS. Testez ce point sur le VPS avant de lui faire confiance :

ip -6 addr show
curl -6 https://ifconfig.me

Une requête qui échoue signifie que le VPS ne dispose d’aucun accès IPv6 en amont. Les sites en dual stack continuent généralement de se charger, car le client abandonne IPv6 et réessaie via IPv4. Ce nouvel essai ajoute toutefois un délai lors de la première connexion à chaque site. Les destinations accessibles uniquement en IPv6 restent injoignables.

L’autre aspect concerne le forwarding. Avec net.ipv4.ip_forward = 1 et net.ipv6.conf.all.forwarding laissés à 0, vous obtenez un chemin IPv4 fonctionnel et un black hole pour IPv6. Pour l’utilisateur, cela ressemble à « certains sites sont lents » plutôt qu’à une erreur facilement recherchable. Les deux lignes doivent figurer dans le fichier sysctl.

Le VPS doit-il aussi annoncer des routes de sous-réseau ?

Un exit node achemine tout le trafic Internet. Une route de sous-réseau achemine une plage privée située derrière la machine qui l’annonce. Ce sont deux fonctions distinctes, avec des autorisations distinctes, et une même machine peut assurer les deux. Aucune des deux n’expose un service exécuté directement sur le VPS. Si vous voulez en réalité une URL HTTPS pour une application installée sur ce serveur, ce sont serve et funnel qu’il faut utiliser.

sudo tailscale set --advertise-routes=10.0.0.0/24

Annoncez un sous-réseau lorsque le VPS partage un réseau privé avec d’autres serveurs que vous voulez atteindre via leurs adresses privées. Autorisez-le dans le même panneau Edit route settings, avec son propre bouton d’activation. Les clients Linux ignorent ensuite la route annoncée tant que vous n’avez pas exécuté --accept-routes. C’est l’une des différences que le guide sur le subnet router explique en détail.

Choisissez soigneusement la plage. Une route annoncée est plus spécifique que la route par défaut de votre ordinateur portable. Si vous annoncez 192.168.1.0/24 depuis le VPS, cette route prend le contrôle des adresses d’un réseau domestique qui utilise la même plage, et les appareils installés chez vous deviennent injoignables. Utilisez une plage que vous avez choisie, et non celle que votre routeur domestique a choisie pour vous.

Accélérer l’exit node avec la redirection UDP GRO

Tailscale 1.54 et les versions ultérieures peuvent utiliser, avec un kernel Linux 6.2 ou ultérieur, une fonction de receive offload qui augmente le débit du trafic redirigé. Le GRO (generic receive offload) regroupe les paquets entrants avant que le kernel les traite un par un. En août 2026, cette configuration doit encore être appliquée manuellement sur l’exit node.

sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

ip -o route get 8.8.8.8 indique l’interface qui permet réellement d’atteindre Internet. Vous n’avez donc pas à choisir entre eth0, ens3 et enp1s0. Vérifiez avec ethtool -k $NETDEV | grep udp-gro-forwarding, qui doit maintenant afficher on. Le GRO n’est utile que si le chemin fonctionne correctement. Si l’exit node reste lent, mesurez ensuite le chemin lui-même, comme pour un tunnel WireGuard simple plus lent que la liaison sous-jacente.

La configuration est perdue au redémarrage. Sur un système qui utilise networkd-dispatcher, rendez-la automatique :

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Vérifiez d’abord que /etc/networkd-dispatcher/routable.d/ existe. Dans le cas contraire, la machine n’exécute pas networkd-dispatcher. Une petite unité systemd qui exécute la ligne ethtool au démarrage fournit la même fonctionnalité.

Ce que la politique d’utilisation acceptable de votre fournisseur implique pour le trafic sortant

Chaque paquet qu’un client envoie via le nœud de sortie quitte le réseau avec l’adresse IP publique du VPS. Il est donc associé à votre compte. Les signalements d’abus arrivent dans votre boîte de réception : notifications de titulaires de droits d’auteur, réclamations concernant des scans de ports. Lisez l’AUP (acceptable use policy) de votre fournisseur avant de faire transiter le trafic d’un foyer ou d’une équipe par un même serveur. N’ouvrez pas un nœud de sortie à des personnes dont vous ne pouvez pas garantir le comportement.

La bande passante est comptabilisée deux fois. Le trafic arrive sur le VPS par le tunnel, puis repart vers Internet. Les deux directions sont généralement déduites du quota de transfert inclus dans l’offre. Le visionnage d’un flux vidéo via un nœud de sortie consomme donc davantage de quota que la plupart des utilisateurs ne le prévoient.

Les plages d’adresses des datacenters ont également une réputation. Certains sites leur présentent davantage de CAPTCHA, et certains services de streaming les refusent totalement. Aucun réglage de votre configuration ne peut changer cela, car ce comportement dépend du bloc d’adresses détenu par votre fournisseur.

Pourquoi le trafic continue de passer par votre connexion locale

Le nœud de sortie est annoncé, mais pas approuvé. tailscale exit-node list n’affiche rien sur le client, et aucune des deux machines n’enregistre d’erreur. Ouvrez la page Machines et activez Use as exit node.

Le client ne l’a jamais sélectionné. L’approbation rend le nœud disponible pour le tailnet. La sélection est une action distincte sur chaque appareil. Relancez sudo tailscale set --exit-node=<name>, puis vérifiez de nouveau curl -4 https://ifconfig.me.

Le forwarding est désactivé. Le symptôme est précis : tailscale ping <vps> réussit, le tunnel est clairement actif et toutes les adresses externes expirent. sysctl net.ipv4.ip_forward renvoie 0. Corrigez le fichier sysctl, puis exécutez sudo sysctl -p /etc/sysctl.d/99-tailscale.conf.

Un firewall bloque les paquets transférés. tailscaled insère sa propre chaîne ts-forward, ce qui suffit sur un VPS vierge. Sur une machine qui utilise déjà ufw ou Docker, la policy FORWARD peut être définie sur DROP, avec des règles placées avant celles de Tailscale. Ne devinez pas laquelle est en cause : exécutez sudo iptables -L FORWARD -n -v pendant que le client tente de charger une page et surveillez les compteurs qui évoluent. Sur une machine utilisant ufw, la correction habituelle consiste à exécuter DEFAULT_FORWARD_POLICY="ACCEPT" dans /etc/default/ufw, puis sudo ufw reload. Vérifiez également le firewall réseau de votre fournisseur dans le panneau de contrôle : il est indépendant de tous les firewalls exécutés sur le serveur.

Cela fonctionne, mais c’est lent. Exécutez tailscale netcheck sur les deux machines. Si la commande indique que l’UDP est bloqué, les deux appareils ne peuvent pas établir de chemin direct et basculent vers un relais DERP, ce qui ajoute de la latence à chaque connexion. Autoriser l’UDP entrant sur le port 41641 vers le VPS dans le firewall réseau du fournisseur rétablit généralement le chemin direct.

Quand laisser le serveur de coordination Tailscale

Tout ce qui précède dépend du serveur de coordination hébergé de Tailscale pour l’échange de clés et pour l’approbation que vous avez validée. Votre trafic va toujours directement de l’ordinateur portable au VPS. Le serveur de coordination ne le transporte jamais, mais il détermine quels utilisateurs peuvent rejoindre le tailnet et quelles ressources chaque appareil peut atteindre. Le prix est rarement une raison suffisante pour changer, car l’offre gratuite couvre six utilisateurs avec un nombre illimité de leurs propres appareils. Évaluez donc plutôt cette dépendance que le montant de la facture. Le changement intervient à partir de la septième personne. Comme Tailscale facture par utilisateur et non par appareil, calculez ce qu’un foyer ou une équipe de cinq personnes paie réellement avant de prendre une décision pour des raisons de coût. Pour l’évaluer correctement, vous devez savoir ce qu’un serveur de coordination compromis ou un compte d’identité volé pourrait réellement atteindre. C’est ce que décrit le modèle de confiance de Tailscale. Si vous souhaitez supprimer cette dépendance, exécutez Headscale comme votre propre serveur de contrôle Tailscale et configurez les deux clients pour l’utiliser. Les étapes relatives au nœud de sortie restent ensuite identiques. L’approbation de la route s’effectue toutefois avec la ligne de commande de Headscale, et non depuis la console hébergée. Headscale remplace le plan de contrôle tout en conservant les clients Tailscale. Si vous préférez héberger vous-même toute la pile, NetBird fournit son propre serveur de coordination et ses propres clients, que vous hébergez sur un VPS.

FAQ

Pourquoi mon trafic utilise-t-il encore ma connexion locale après la sélection du nœud de sortie ?

Deux causes sont fréquentes. Le nœud de sortie a été annoncé, mais jamais approuvé : ouvrez la page Machines dans la console d’administration, recherchez le VPS, sélectionnez Edit route settings, puis activez Use as exit node. L’approbation se fait avec un bouton dans la console. Aucune commande exécutée sur le serveur ne permet de l’effectuer. L’autre cause est différente : le forwarding IP est désactivé. Le tunnel s’établit, tailscale ping vers le VPS fonctionne, mais toutes les adresses externes finissent en timeout. Vérifiez avec sysctl net.ipv4.ip_forward, qui doit renvoyer 1.

Dois-je approuver manuellement le nœud de sortie à chaque fois ?

L’activation est une action unique pour chaque machine. Si vous recréez souvent le VPS, ajoutez un bloc autoApprovers à votre fichier de stratégie tailnet contenant "exitNode": ["tag:exit"], définissez tag:exit sous tagOwners, puis démarrez le nœud avec --advertise-tags=tag:exit. Un appareil marqué appartient au tailnet plutôt qu’à votre compte utilisateur. Les règles d’accès qui s’y appliquent sont donc également différentes.

Quel serveur DNS mon ordinateur portable utilise-t-il lorsqu’un nœud de sortie est activé ?

Celui du nœud de sortie. Un appareil qui utilise un nœud de sortie lui envoie toutes les requêtes DNS. Cela remplace les nameservers DNS globaux et split DNS configurés pour le tailnet. Le réseau local ne voit ainsi pas les noms que vous recherchez. Pour conserver l’utilisation d’un nameserver du tailnet, activez Use with exit node pour ce nameserver dans la page DNS de la console d’administration. Les noms MagicDNS continuent de se résoudre, car le client Tailscale y répond localement à 100.100.100.100.

Un même VPS peut-il être à la fois un nœud de sortie et un subnet router ?

Oui. sudo tailscale set --advertise-exit-node et sudo tailscale set --advertise-routes=10.0.0.0/24 sont indépendants. Chacun dispose de son propre bouton d’approbation sous Edit route settings. Le forwarding IP doit être activé sur le VPS dans les deux cas. Évitez d’annoncer une plage qui correspond au réseau local de votre ordinateur portable. La route annoncée est plus spécifique que la route par défaut, et vos appareils locaux deviennent alors injoignables.

Un nœud de sortie masque-t-il mon trafic à mon fournisseur de VPS ?

Non. Le tunnel se termine sur le VPS. Le trafic quitte donc le serveur sous la forme attendue par la destination, et votre fournisseur le transporte en clair lorsque le site lui-même n’est pas chiffré. Un nœud de sortie déplace le point où votre trafic rejoint Internet : il passe du réseau auquel vous êtes connecté au serveur que vous louez. Votre navigation est masquée au Wi-Fi du café et à votre FAI résidentiel. En revanche, elle reste visible par votre fournisseur de VPS, avec votre nom de compte associé.