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 transporte tout le trafic Internet de vos autres appareils. Un VPS (virtual private server) convient bien, car il possède une adresse publique fixe et reste en ligne. Sa configuration se fait en cinq étapes : installer Tailscale sur le serveur, annoncer l’exit node, activer le transfert IP, approuver la route dans la console d’administration, puis sélectionner le nœud sur votre ordinateur portable. La quatrième étape consiste à cocher une case sur une page web, et non à exécuter une commande. C’est à ce stade que la plupart des utilisateurs bloquent.

Une fois l’exit node activé, votre ordinateur portable chiffre chaque paquet et l’envoie au VPS. Le VPS applique une translation d’adresse réseau 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. Sans exit node, Tailscale transporte uniquement le trafic entre vos propres appareils. Chaque site web voit toujours votre adresse réelle. C’est la distinction qui détermine si Tailscale est réellement un VPN.

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 complète des compromis, consultez la comparaison entre Tailscale et WireGuard classique. Si vous préférez gérer vous-même chaque élément 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 sont connectées au même tailnet. Un tailnet est votre réseau Tailscale privé. Sauf si un administrateur a désactivé IPv4 pour ce réseau, 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 dans la console d’administration et trouvez le VPS, qui devrait maintenant afficher le badge Exit Node. Ouvrez le menu de cet appareil, choisissez Edit exit node, cochez la case Use as exit node, puis sélectionnez Save.

Tant que cette case n’est pas cochée et enregistrée, le control plane conserve la proposition et ne l’attribue à 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’apparaît tout simplement jamais.

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 doté d’un tag appartient au tailnet et non à votre compte utilisateur, et les règles d’accès qui s’y appliquent changent également. Pour un seul VPS, la case à cocher 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. Effectuez ce test sur le VPS avant de lui faire confiance :

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

Si la requête ne parvient pas à se connecter, le VPS ne dispose d’aucun chemin IPv6 fonctionnel vers l’extérieur. Si curl signale plutôt « Could not resolve host », le problème vient de la résolution de noms et non d’IPv6. Corrigez donc le DNS sur le VPS, puis relancez le test. Les sites en double pile continuent généralement de se charger, car les clients qui implémentent Happy Eyeballs, notamment curl, lancent une tentative IPv4 en parallèle lorsque la tentative IPv6 ne s’est pas connectée après un court délai, puis conservent la connexion qui aboutit en premier. Par défaut, curl attend 200 millisecondes. Cette attente ajoute donc un délai aux nouvelles connexions, mais ne provoque pas d’erreur. Les destinations accessibles uniquement en IPv6 restent injoignables.

L’autre aspect concerne la transmission des paquets. net.ipv4.ip_forward = 1 avec net.ipv6.conf.all.forwarding laissé à 0 fournit un chemin IPv4 fonctionnel et crée un trou noir pour IPv6. Pour l’utilisateur, cela ressemble à « certains sites sont lents », et non à une erreur facilement identifiable par une recherche. Les deux lignes doivent figurer dans le fichier sysctl.

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

Un nœud de sortie 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. Il s’agit de fonctionnalités distinctes, avec des validations distinctes, et une même machine peut assurer les deux rôles. Aucune des deux n’expose un service exécuté directement sur le VPS. Si vous voulez en réalité obtenir une URL HTTPS pour une application exécuté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 joindre via leurs adresses privées. Validez cette route dans sa propre boîte de dialogue, séparément de celle du nœud de sortie : dans la page Machines, sélectionnez le VPS, ouvrez la section Subnets, sélectionnez Edit pour ouvrir Edit subnet routes, sélectionnez la route, puis sélectionnez Save. 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 expliquées en détail dans le guide des routeurs de sous-réseau.

Choisissez soigneusement la plage. Une fois la route validée, un ordinateur portable qui l’accepte (Windows, macOS, iOS et Android le font par défaut, Linux après --accept-routes) peut envoyer dans le tunnel le trafic destiné à cette plage. Si vous validez 192.168.1.0/24 sur le VPS et qu’un ordinateur portable connecté à un réseau domestique utilise la même plage, les adresses correspondantes peuvent être redirigées vers le tunnel et les appareils présents sur votre bureau 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 le forwarding 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 forwardé. Le GRO (generic receive offload) regroupe les paquets entrants avant que le kernel ne les traite un par un. En octobre 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. Le GRO aide uniquement un chemin qui fonctionne déjà correctement. Si l’exit node reste lent ensuite, mesurez directement le chemin, comme vous le feriez pour un tunnel WireGuard classique plus lent que la liaison sous-jacente.

Ce réglage 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’exécute pas networkd-dispatcher. Une petite unité systemd qui exécute la ligne ethtool au démarrage remplit la même fonction.

Ce que la politique d’utilisation acceptable de votre fournisseur implique pour le trafic de l’exit node

Chaque paquet qu’un client envoie via l’exit node sort 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 du droit 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 exit node à des personnes dont vous ne pouvez pas répondre.

La bande passante est comptabilisée une seule fois, à la sortie. Chaque octet qui traverse l’exit node passe deux fois par le VPS : il arrive d’un côté, puis repart de l’autre. Sur la plupart des offres VPS, seule la moitié sortante est comptabilisée. En octobre 2026, SSD Nodes indique la limite de chaque offre KVM sous la forme d’un volume de transfert sortant, de 4TB à 48TB par mois. La documentation de Vultr précise que le trafic entrant n’est pas comptabilisé. Pour un téléchargement, la partie comptabilisée est le trajet du VPS vers votre ordinateur portable à travers le tunnel. Pour un envoi, c’est le trajet du VPS vers Internet. Dans les deux cas, tout ce que vous faites passer par l’exit node est décompté une fois de la limite. Un flux vidéo regardé via un exit node représente donc un volume plus important que beaucoup ne l’imaginent. Vérifiez votre propre offre, car un hébergeur qui comptabilise les deux directions compte ce flux deux fois.

Les plages d’adresses des datacenters ont aussi une réputation. Certains sites leur présentent davantage de CAPTCHA, et certains services de streaming les refusent complètement. Aucun réglage de votre configuration ne peut changer cela, car c’est une caractéristique 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, choisissez Edit exit node dans le menu du VPS, cochez Use as exit node, puis cliquez sur Save.

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 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> fonctionne, le tunnel est clairement établi et toutes les adresses externes expirent. sysctl net.ipv4.ip_forward affiche 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 crée sa propre chaîne ts-forward, ce qui suffit sur un VPS vierge. Une machine qui utilise déjà ufw ou Docker peut avoir une policy FORWARD à 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 essaie de charger une page, puis surveillez les compteurs qui augmentent. 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 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. Si la commande indique que l’UDP est bloqué, les deux appareils ne peuvent pas établir de chemin direct et utilisent un relay DERP, ce qui ajoute de la latence à chaque connexion. Autoriser les connexions UDP entrantes sur le port 41641 vers le VPS dans le firewall réseau du fournisseur rétablit généralement le chemin direct. Si votre ordinateur portable se connecte depuis chez vous derrière une Freebox en IPv4 partagée, vous ne pouvez ouvrir aucun port de ce côté, mais Tailscale derrière une Freebox obtient souvent un chemin direct grâce à l’IPv6.

Quand se passer du 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 circule directement de votre ordinateur portable vers le VPS, ou via l’un des relais DERP de Tailscale lorsqu’aucun chemin direct ne peut être établi. Le serveur de coordination ne transporte jamais ce trafic, même s’il détermine qui peut rejoindre le tailnet et à quelles ressources chaque appareil peut accéder. Le prix justifie rarement un changement, car le forfait gratuit couvre six utilisateurs avec un nombre illimité d’appareils leur appartenant. Évaluez donc plutôt la dépendance elle-même que le coût. Le septième utilisateur change la situation. Tailscale facturant 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 motivée par le coût. Pour évaluer honnêtement cette dépendance, vous devez savoir à quelles ressources un serveur de coordination compromis ou un compte d’identité volé pourrait réellement accéder. C’est ce que décrit le modèle de confiance de Tailscale. Si vous voulez 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 concernant le nœud de sortie restent ensuite identiques. L’approbation de la route se fait toutefois avec la ligne de commande de Headscale, et non depuis la console hébergée. Headscale remplace le control plane, tout en vous laissant utiliser les clients Tailscale. Si vous préférez gérer toute la pile vous-même, NetBird fournit son propre serveur de coordination et des 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, trouvez le VPS, choisissez Edit exit node dans son menu, cochez Use as exit node, puis sélectionnez Save. L’approbation s’effectue dans la console. Aucune commande exécutée sur le serveur ne permet de l’effectuer. L’autre cause est différente : la redirection IP est désactivée. Le tunnel est alors établi, tailscale ping vers le VPS fonctionne, mais toutes les adresses externes expirent. Vérifiez avec sysctl net.ipv4.ip_forward, qui doit retourner 1.

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

L’approbation est une action unique pour chaque machine. Si vous recréez souvent le VPS, ajoutez un bloc autoApprovers à votre fichier de règles 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 changent donc également.

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 vers ce nœud. Cela remplace les serveurs DNS globaux et split DNS configurés pour le tailnet. Le réseau local ne voit ainsi plus les noms que vous recherchez. Pour conserver l’utilisation d’un serveur DNS du tailnet, activez Use with exit node pour ce serveur sur la page DNS de la console d’administration. Les noms MagicDNS continuent à ê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 routeur de sous-réseau ?

Oui. sudo tailscale set --advertise-exit-node et sudo tailscale set --advertise-routes=10.0.0.0/24 sont indépendants, et chacun est approuvé dans sa propre boîte de dialogue : le nœud de sortie avec Edit exit node dans le menu de l’appareil sur la page Machines, et le sous-réseau avec Edit dans la section Subnets de l’appareil, ce qui ouvre Edit subnet routes. La redirection IP doit être activée sur le VPS dans les deux cas. Évitez d’annoncer une plage qui correspond au réseau domestique de votre ordinateur portable. Une fois cette route approuvée et acceptée par votre ordinateur portable, elle peut détourner ces adresses du réseau local. 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. Cela masque votre navigation au Wi-Fi d’un café et à votre FAI domestique. En revanche, cette même navigation reste visible par votre fournisseur de VPS, associée au nom de votre compte.