Configurer un 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 comporte cinq étapes : installer Tailscale sur le serveur, annoncer l’exit node, activer le routage 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 généralement à ce stade que les utilisateurs restent bloqués.

Une fois l’exit node activé, votre ordinateur portable chiffre chaque paquet et l’envoie au VPS. Le VPS applique une translation d’adresse source (source NAT, 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 derrière un NAT. C’est grâce à ce serveur de coordination qu’aucune copie de clé n’est nécessaire dans les étapes ci-dessous. Pour une comparaison détaillée des compromis, consultez la comparaison entre Tailscale et WireGuard classique. Si vous préférez gérer vous-même chaque partie du tunnel, hébergez vous-même 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 correspondant à 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 du tout fournir de service à votre ordinateur portable.

tailscale status
tailscale ip -4

tailscale status doit maintenant afficher les deux machines. tailscale ip -4 affiche l’adresse tailnet du VPS. C’est cette adresse que vous indiquerez au client par la suite.

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 reposant sur 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 continuer.

Activer le forwarding 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 exit node accepterait votre trafic, le déchiffrerait, puis le supprimerait. Écrivez ce paramètre dans un fichier pour qu’il soit conservé après 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 fonctionnera toujours, 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 avec set ne prouve donc pas que le forwarding 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 firewall, nommées ts-input, ts-forward et ts-postrouting. La règle NAT pour le trafic du exit node se trouve dans ts-postrouting. Affichez-les avec sudo iptables-save | grep ts-, ou avec sudo nft list ruleset sur une machine utilisant nftables.

Annoncer 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 annonce également le nœud, avec un effet secondaire : up considère les options de sa ligne de commande comme l’ensemble complet des paramètres non définis par défaut. Ainsi, un sudo tailscale up exécuté ultérieurement sans argument refuse 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.

L’annonce correspond à une proposition. Le VPS indique maintenant au serveur de coordination 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, recherchez le VPS, ouvrez le menu à trois points à la fin de sa ligne, sélectionnez 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 à personne. tailscale exit-node list sur votre ordinateur portable n’affiche rien et votre trafic conserve son routage normal. Aucun message d’erreur n’apparaît sur l’une ou l’autre machine. Le nœud de sortie n’est tout simplement jamais visible.

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’attribution 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 également. Pour un VPS unique, 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’approbation n’a pas été effectuée. Sur macOS, Windows, iOS et Android, le même choix se trouve dans l’élément de 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 ne répondent alors plus. Conservez le réseau local dans la route locale :

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

Pourquoi votre DNS change dès que l’exit node est activé

Par défaut, un appareil qui utilise un exit node utilise également cet exit node comme resolver DNS (domain name system) pour tous les domaines. Cela remplace les nameservers DNS global et split DNS configurés pour votre tailnet. Ce comportement est volontaire. Si les requêtes continuaient à utiliser le resolver du réseau local, le routeur du café verrait toujours 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 resolver interne : un nameserver du tailnet dont vous dépendez cesse d’être utilisé lorsque l’exit node est activé. Activez Use with exit node pour ce nameserver 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 l’exit node. 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 répertorie 100.100.100.100 comme serveur DNS.

Si vous désactivez la gestion DNS de Tailscale avec --accept-dns=false, le client conserve le resolver fourni par le réseau local. Le trafic est tunnelé, mais les requêtes DNS ne le sont pas. C’est 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 exit node

Un exit node 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 n’a pas d’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. Cette nouvelle tentative 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. net.ipv4.ip_forward = 1 avec net.ipv6.conf.all.forwarding laissé à 0 vous donne un chemin IPv4 fonctionnel et un black hole pour IPv6. Pour l’utilisateur, le symptôme est que « certains sites sont lents », et non une erreur facilement identifiable dans un moteur de recherche. Les deux lignes doivent figurer dans le fichier sysctl.

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

Un exit node transporte tout le trafic Internet. Une route de sous-réseau transporte une plage privée située derrière la machine qui l’annonce. Il s’agit de fonctionnalités distinctes, avec des validations distinctes. Une même machine peut utiliser les deux.

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 joindre à l’aide de leurs adresses privées. Validez cette route dans le même panneau Edit route settings, avec son propre bouton à bascule.

Choisissez la plage avec soin. Une route annoncée est plus spécifique que la route par défaut de votre ordinateur portable. Ainsi, annoncer 192.168.1.0/24 depuis le VPS 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, avec un kernel Linux 6.2 ou ultérieur, peuvent utiliser un mécanisme de receive offload qui augmente le débit du trafic transféré. Le GRO (generic receive offload) regroupe les paquets entrants avant que le kernel ne 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 au hasard entre eth0, ens3 et enp1s0. Vérifiez avec ethtool -k $NETDEV | grep udp-gro-forwarding, qui doit maintenant afficher on.

Ce paramètre est perdu au redémarrage. Sur un système qui utilise networkd-dispatcher, rendez-le 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. Si ce n’est pas le cas, la machine n’utilise pas networkd-dispatcher. Une petite unité systemd qui exécute la ligne ethtool au démarrage produit le même résultat.

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 attribué à votre compte. Les signalements d’abus arrivent dans votre boîte de réception : notifications de violation de droits d’auteur, plaintes concernant des scans de ports. Lisez l’AUP (acceptable use policy) de votre fournisseur avant de faire passer 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 volume de transfert autorisé par l’offre. Un flux vidéo regardé via un nœud de sortie consomme donc plus de données 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 complètement. Votre configuration ne change rien à cela, car cette réputation dépend du bloc d’adresses détenu par votre fournisseur.

Pourquoi le trafic sort toujours par votre connexion locale

Le nœud de sortie est annoncé, mais pas approuvé. La commande tailscale exit-node list exécutée sur le client n’affiche rien, 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 dans le tailnet. La sélection est une action distincte à effectuer sur chaque appareil. Exécutez de nouveau sudo tailscale set --exit-node=<name>, puis vérifiez encore 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 établi 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 forwardés. tailscaled insère sa propre chaîne ts-forward, ce qui suffit sur un VPS vierge. Une machine qui utilise déjà ufw ou Docker peut se retrouver avec une policy FORWARD à DROP et 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, puis 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, car il s’agit d’un contrôle distinct de tout ce qui s’exécute sur le serveur.

Cela fonctionne, mais c’est lent. Exécutez tailscale netcheck sur les deux machines. S’il 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 quitter 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’autorisation que vous avez validée. Votre trafic circule toujours directement entre votre ordinateur portable et le VPS. Le serveur de coordination ne le transporte jamais. En revanche, il détermine qui peut rejoindre le tailnet et quelles ressources chaque appareil peut atteindre. 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 à l’exit node restent ensuite identiques. L’autorisation de la route s’effectue toutefois avec la ligne de commande de Headscale, et non depuis la console hébergée.

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, trouvez 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 transfert IP est désactivé. Le tunnel s’établit, tailscale ping vers le VPS fonctionne, mais toutes les adresses externes expirent. 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 policy 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 actif ?

Le nœud de sortie lui-même. Un appareil qui utilise un nœud de sortie envoie toutes ses requêtes DNS à ce nœud. Cela remplace les serveurs de noms DNS globaux et split DNS définis pour le tailnet. Le réseau local ne voit ainsi pas les noms que vous recherchez. Pour conserver l’utilisation d’un serveur de noms du tailnet, activez Use with exit node pour ce serveur dans la page DNS de la console d’administration. Les noms MagicDNS continuent d’être résolus, car le client Tailscale y répond localement sur 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, et chacun dispose de son propre bouton d’approbation dans Edit route settings. Le transfert IP doit être activé sur le VPS pour les deux fonctions. Évitez d’annoncer une plage qui correspond au réseau local de votre domicile, car la route annoncée est plus spécifique que la route par défaut et vos appareils locaux deviennent inaccessibles.

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 domestique, mais elle reste visible par votre fournisseur de VPS, avec votre nom de compte associé.