Tailscale sans redirection de port : comment ça marche

Tailscale a-t-il besoin d’une redirection de port ?

Tailscale n’a pas besoin de redirection de port. Pour accéder à vos propres machines, il remplace complètement ce mécanisme. Chaque appareil de votre tailnet (le réseau privé que Tailscale crée entre vos appareils) ouvre ses propres connexions sortantes. Vous n’avez rien à modifier sur votre routeur domestique : aucun port redirigé, aucun hôte en DMZ (zone démilitarisée), aucun enregistrement DNS dynamique et aucune adresse IP publique requise. Un NAS (boîtier de stockage connecté au réseau), un Raspberry Pi ou un serveur de jeu situé derrière un routeur ipTIME ou Fritz!Box devient accessible depuis votre ordinateur portable, où que vous soyez, à sa propre adresse privée, tandis que le trafic entrant du routeur reste bloqué.

Ce que Tailscale ne fait pas est tout aussi simple. Tailscale connecte les appareils connectés à votre tailnet ou ceux qui y ont été partagés. Un inconnu sur Internet ou un ami qui n’a pas rejoint le réseau ne peut rien atteindre par ce moyen. Exposer un service à l’ensemble d’Internet est une autre tâche, traitée vers la fin.

Comment Tailscale traverse le NAT sans redirection de port

La redirection de port existe à cause du NAT (traduction d’adresses réseau). Sur la plupart des connexions domestiques, le routeur possède l’unique adresse IPv4 publique, et chaque appareil derrière lui en possède une privée. Un paquet entrant qui arrive sur le routeur n’indique pas quel appareil privé est concerné. Le routeur le supprime donc. Une redirection de port est une règle manuelle qui indique que « le port 25565 appartient à 192.168.0.20 ». Tailscale obtient le même résultat sans cette règle, en quatre étapes.

Premièrement, chaque nœud établit une connexion sortante. Au démarrage, tailscaled se connecte au serveur de coordination. Il privilégie HTTP sur TCP 80, encapsulé dans son propre transport chiffré, puis bascule sur HTTPS via TCP 443 lorsque le port 80 ne répond pas. Il envoie sa clé publique WireGuard et récupère les clés publiques et les adresses de tous les autres nœuds du tailnet. Le serveur de coordination ne transporte jamais votre trafic. Il ne fournit que les clés et le carnet d’adresses.

Deuxièmement, chaque nœud détermine ce qu’il est possible de voir depuis l’extérieur. Il envoie une requête STUN (session traversal utilities for NAT) en UDP vers le port 3478 des serveurs relais de Tailscale. La réponse contient l’adresse IP publique et le port que le routeur a attribués à ce paquet sortant. Il s’agit du mapping qu’une redirection de port aurait créé manuellement, sauf que le routeur l’a créé automatiquement pour un flux sortant. Si le routeur prend en charge UPnP ou NAT-PMP, Tailscale lui demande aussi automatiquement de créer un mapping. Cela peut aider, mais son fonctionnement n’en dépend pas.

Troisièmement, les deux côtés effectuent un hole punching. Le nœud A et le nœud B apprennent le endpoint public de l’autre par l’intermédiaire du serveur de coordination. Ils envoient simultanément des paquets UDP depuis leur propre listener, sur le port 41641 par défaut, vers l’endpoint public de l’autre côté. Chaque routeur possède déjà un mapping sortant pour son nœud. Le paquet arrivant de l’autre côté correspond donc à ce mapping et est autorisé à entrer. À partir de ce moment, les deux nœuds communiquent directement via WireGuard, sans que le routeur ait besoin d’une règle.

Quatrièmement, lorsque le hole punching échoue, le trafic reste relayé. Chaque connexion commence en réalité par passer par un serveur DERP (designated encrypted relay for packets), qui transporte les paquets WireGuard chiffrés via HTTPS sur TCP 443. Tailscale tente ensuite de basculer vers le chemin UDP direct de la troisième étape. Le CGNAT (carrier-grade NAT, lorsque le FAI vous place derrière un second NAT qu’il contrôle) et le NAT symétrique (lorsque le routeur choisit un nouveau port pour chaque destination, ce qui rend la réponse STUN inutilisable) empêchent tous deux cette bascule. Il en va de même pour un firewall d’entreprise qui bloque UDP. Lorsque la bascule échoue, Tailscale tente d’abord un relais pair à pair : il s’agit d’un appareil de votre propre tailnet que vous avez configuré pour relayer le trafic en UDP. Si aucun n’est disponible, la connexion reste sur DERP. Le relais ne voit que du ciphertext. Cette solution augmente aussi la latence et réduit le débit. Pourquoi une connexion Tailscale relayée est lente et comment la rendre directe explique comment déterminer le chemin utilisé et quoi modifier.

Aucune de ces quatre étapes ne constitue une connexion entrante vers votre routeur. C’est la raison pour laquelle aucune redirection de port n’est nécessaire.

Installer le client et vérifier le chemin

L’installation consiste en un script et une connexion sur chaque appareil.

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

tailscale up affiche une URL de connexion. Ouvrez-la, connectez-vous, puis l’appareil rejoint le tailnet. tailscale ip -4 affiche l’adresse tailnet de l’appareil dans la plage 100.64.0.0/10. Cette adresse reste identique après les redémarrages et d’un réseau à l’autre. C’est donc celle que vous indiquez dans les configurations SSH et les clients de jeu.

Depuis un deuxième appareil du tailnet, vérifiez le chemin vers le premier :

tailscale ping nas

Utilisez le nom d’hôte ou l’adresse tailnet. La première réponse indique souvent via DERP, car chaque connexion commence par un relais pendant la négociation du chemin direct. Après quelques secondes, les réponses devraient afficher une adresse IP publique et un port. Cela signifie que le hole punching a fonctionné. Si les réponses indiquent encore via DERP après une minute, le hole punching n’a pas pu aboutir. La cause est généralement un côté situé derrière un NAT que le hole punching ne peut pas traverser, ou sur un réseau qui bloque UDP. La connexion passe alors par un relais.

La seule règle de pare-feu qui vaille la peine d’être ajoutée

Tailscale fonctionne sans modifier le pare-feu sur la plupart des réseaux, car les connexions UDP sortantes sont généralement autorisées. Une règle facultative augmente les chances d’établir un chemin direct : autoriser les connexions UDP sortantes depuis le port 41641.

Sur un routeur domestique ou un pare-feu d’entreprise qui restreint les connexions UDP sortantes, il faut autoriser les appareils à envoyer des paquets UDP avec le port source 41641 vers n’importe quelle adresse et n’importe quel port de destination. Il faut également autoriser les connexions UDP sortantes vers le port de destination 3478 pour STUN. Autoriser uniquement le port de destination 41641 ne suffit pas, car le NAT ou la configuration d’un pair peut placer son extrémité de la connexion sur n’importe quel port. La plupart des routeurs domestiques autorisent déjà toutes les connexions UDP sortantes. Il n’y a donc rien à faire.

Sur un VPS, le sens utile est le sens entrant. Un VPS possède généralement son adresse IP publique sur sa propre interface réseau, ou au plus un NAT one-to-one fixe, comme celui effectué par une internet gateway AWS. Une règle entrante pour UDP 41641 fournit donc à chaque pair une cible stable et joignable. Un pair situé derrière un NAT difficile peut alors souvent se connecter directement, à condition que son propre réseau autorise les connexions UDP sortantes. Un pair situé sur un réseau qui bloque l’UDP reste relayé, quelles que soient les règles autorisées par le VPS. Avec ufw :

sudo ufw allow 41641/udp
sudo ufw status

ufw status doit afficher 41641/udp comme ALLOW depuis Anywhere. Les fournisseurs qui utilisent un pare-feu réseau distinct dans leur control panel doivent appliquer la même règle à cet endroit, car un paquet bloqué à la périphérie du fournisseur n’atteint jamais ufw. Cette règle est pratique, mais elle n’est pas obligatoire. Si le port est fermé, le VPS rejoint tout de même le tailnet et les pairs peuvent toujours l’atteindre, certains via un relay plutôt que directement.

Accéder à un NAS domestique ou à un Raspberry Pi depuis l’extérieur

Le premier cas est le plus simple. C’est ce que la plupart des utilisateurs entendent par « port forwarding avec Tailscale » : accéder à une machine chez soi depuis un ordinateur portable ou un téléphone qui ne se trouve pas à domicile.

Installez le client sur la machine à domicile et sur l’ordinateur portable. C’est toute la configuration nécessaire. Le NAS ou le Pi répond alors sur son adresse tailnet pour chaque service qui écoute sur toutes ses interfaces, sans aucune redirection de port. Un service lié uniquement à 127.0.0.1 ou à l’adresse du LAN reste invisible sur le tailnet tant que vous ne modifiez pas l’adresse d’écoute.

ssh pi@100.101.102.103
curl -I http://100.101.102.103:8080/

Remplacez l’adresse par la sortie de tailscale ip -4 sur la machine à domicile. La connexion SSH doit se comporter exactement comme sur le Wi-Fi domestique, et curl -I doit afficher la ligne d’état HTTP de l’application web exécutée par la machine. Comme la connexion est authentifiée par des clés WireGuard associées à un appareil connecté, un service qui serait dangereux sur un port redirigé, comme un partage SMB (server message block) ou un panneau d’administration web, est acceptable ici : seuls vos propres appareils peuvent lui envoyer des paquets. Le routeur ipTIME ou Fritz!Box situé entre les deux ne voit aucune connexion entrante et ne nécessite aucune modification. Si votre FAI vous a placé derrière un CGNAT, cela fonctionne également, car la machine à domicile n’établit que des connexions sortantes. Dans le pire des cas, le trafic passe par un relay.

MagicDNS, activé par défaut sur les nouveaux tailnets, attribue également un nom à chaque nœud. ssh pi@nas fonctionne donc dès que l’ordinateur portable est connecté au tailnet.

Lorsqu’un appareil ne peut pas exécuter Tailscale : un subnet router

Certains appareils ne peuvent pas exécuter le client : une imprimante, une caméra IP, un ancien NAS avec un système d’exploitation verrouillé ou un téléviseur connecté. Un subnet router résout ce problème. Une machine du réseau domestique qui peut exécuter Tailscale, par exemple un Pi, annonce l’ensemble du subnet domestique. Les autres appareils du tailnet acheminent alors le trafic vers ce subnet par son intermédiaire.

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
sudo sysctl --system
sudo tailscale up --advertise-routes=192.168.0.0/24

Utilisez le subnet réel de votre réseau domestique. La route doit ensuite être approuvée dans la console d’administration, dans les paramètres de route de la machine. Les clients Linux doivent également l’activer explicitement avec sudo tailscale set --accept-routes. Ensuite, ping 192.168.0.50 exécuté depuis l’ordinateur portable atteint la caméra située à domicile. Le paramètre sysctl de forwarding est nécessaire. Sans lui, le Pi abandonne tous les paquets qui ne lui sont pas destinés. La route apparaît alors comme approuvée, mais aucun appareil situé derrière elle ne répond. L’étape d’approbation, l’activation côté client et les autres causes d’une route approuvée mais inaccessible sont décrites dans exécuter un subnet router Tailscale. Cette procédure utilise un VPS comme routeur, mais elle s’applique aussi telle quelle à un Pi installé dans le salon.

Faire rejoindre des amis à un serveur Minecraft sans ouvrir le routeur

Deuxième cas : un serveur Minecraft sur un PC à domicile, et des amis qui veulent le rejoindre. La méthode classique consiste à rediriger le port TCP 25565 sur le routeur et à communiquer votre IP publique. Cette IP devient alors également visible par tous les scanners sur Internet. Tailscale remplace cette méthode par le partage.

Deux options sont possibles. La première consiste à inviter les amis dans votre tailnet en tant qu’utilisateurs. Cela fonctionne, mais le nombre de comptes utilisateur du forfait gratuit est limité, et, par défaut, un utilisateur invité peut accéder à tous les appareils de votre tailnet. C’est plus que nécessaire pour un jeu, sauf si vous écrivez des règles d’accès pour limiter cet accès. La seconde option, plus simple, est le partage de nœud. Dans la console d’administration, ouvrez la page Machines, recherchez le PC de jeu, ouvrez son menu et choisissez Share. Tailscale crée un lien d’invitation. Chaque ami doit avoir son propre compte Tailscale gratuit. Ce compte devient le propriétaire de son propre petit tailnet. L’ami doit ensuite accepter le lien avec ce compte. La machine partagée apparaît alors dans sa liste de machines, et aucune autre. Le partage donne au destinataire un accès à la machine partagée, et à rien d’autre dans votre tailnet. Par défaut, une machine partagée est mise en quarantaine : elle peut répondre aux connexions provenant du tailnet de l’ami, mais elle ne peut en démarrer aucune.

Les amis ajoutent le serveur dans Minecraft avec son adresse tailnet, 100.101.102.103:25565, ou simplement l’adresse si le port par défaut est utilisé. Le PC de jeu fonctionne sans aucun port redirigé, et le routeur reste inchangé. Les machines partagées n’annoncent pas les routes de sous-réseau. Le partage fonctionne donc pour un service exécuté directement sur la machine partagée, ce qui correspond exactement au cas d’un serveur de jeu.

La limite est que chaque joueur doit exécuter Tailscale et accepter le partage. Pour un groupe d’amis, cela convient. Pour un serveur public auquel n’importe qui peut se connecter, ce n’est pas adapté. Les deux sections suivantes présentent la solution.

Exécuter le serveur de jeu sur un VPS et garder RCON sur le tailnet

L’autre solution pour éviter la redirection de ports consiste à ne plus héberger le jeu chez vous. Un VPS dispose d’une adresse IP publique qui permet de le joindre directement. Le port du jeu peut donc être exposé publiquement, sans passer par le routeur domestique. Exécuter un serveur Minecraft sur un VPS explique comment dimensionner le serveur, choisir les options Java, configurer les sauvegardes et créer l’unité systemd. Ce qui nous intéresse ici, ce sont les ports exposés sur Internet.

Un serveur Minecraft ouvre deux ports. TCP 25565 correspond au jeu et doit être accessible aux joueurs. TCP 25575 correspond à RCON (console distante). Ce port accepte un mot de passe, puis exécute n’importe quelle commande du serveur, notamment op et stop. Un port RCON exposé sur Internet peut faire l’objet de tentatives de devinette du mot de passe. Ajoutez le VPS à votre tailnet et appliquez des règles différentes aux deux ports :

sudo ufw allow OpenSSH
sudo ufw allow 25565/tcp
sudo ufw allow in on tailscale0 to any port 25575 proto tcp
sudo ufw enable
sudo ufw status

La deuxième règle ouvre le jeu à tout le monde. La troisième autorise RCON uniquement pour les paquets arrivant sur l’interface tailscale0. Cela signifie que seuls les appareils de votre tailnet et les personnes avec lesquelles vous avez partagé le VPS peuvent y accéder. Si vous partagez le VPS, utilisez des règles d’accès dans la policy de votre tailnet pour empêcher les utilisateurs invités d’atteindre le port 25575. La règle appliquée à l’interface seule ne permet pas de les distinguer de vos propres appareils. L’adresse IP publique continue de répondre sur le port 25565. En revanche, une connexion au port 25575 depuis le réseau public est bloquée par la policy deny par défaut de ufw. Vérifiez les deux accès depuis votre ordinateur portable, qui se trouve dans le tailnet :

nc -zv 100.101.102.103 25575
nc -zv <vps-public-ip> 25575

La première commande doit afficher succeeded. La seconde doit rester bloquée, puis expirer, car le paquet est arrivé par l’interface publique et ne correspond à aucune règle d’autorisation. Le même modèle s’applique à SSH, à une carte web, à une base de données ou à un dashboard de métriques : port public sur l’adresse IP publique, ports d’administration uniquement sur tailscale0.

Exposer un service sur tout Internet : Funnel ou tunnel inverse via un VPS

C’est le troisième cas, que Tailscale ne résout pas à lui seul. Un blog, une API publique, un serveur de jeu public ou une page d’état : les visiteurs ne sont pas dans votre tailnet et ne le seront jamais. Deux outils permettent de gérer ce cas, chacun faisant l’objet d’un article distinct.

Tailscale Funnel publie un service HTTPS d’un nœud sur Internet, via les relais Tailscale. Il fonctionne uniquement avec TLS (Transport Layer Security) et uniquement sur les ports 443, 8443 et 10000. Il convient donc à une application web, mais pas à un protocole de jeu brut sur le port 25565. Tailscale Serve ou Funnel explique ce que chacun expose et à qui.

Un tunnel inverse via un VPS gère tous les autres cas. La machine du domicile ouvre un tunnel sortant vers un VPS doté d’une adresse IP publique, puis le VPS redirige un port public vers la machine à travers ce tunnel, en TCP ou en UDP, avec n’importe quel numéro de port. C’est l’outil adapté à un serveur Minecraft public hébergé chez vous derrière un CGNAT. Un tunnel inverse via un VPS pour un serveur domestique derrière un CGNAT explique la procédure. Choisissez l’une de ces deux solutions et ne cherchez plus un paramètre Tailscale permettant d’ouvrir un port sur Internet. Ce paramètre n’existe pas.

Ce que Tailscale ne fait pas

• Il ne redirige pas un port pour des clients publics quelconques. Un paquet provenant de l’extérieur du tailnet n’atteint jamais votre nœud, car aucune clé WireGuard ne lui est associée. Un paquet WireGuard sans clé valide est abandonné sans réponse.
• Il ne permet pas au public d’entrer. Les utilisateurs doivent être membres de votre tailnet ou avoir accepté un nœud partagé.
• Il ne garantit pas un chemin direct. Avec un NAT difficile à traverser, la connexion passe par un relais, ce qui la ralentit.
• Il n’ouvre pas le routeur. Le routeur reste fermé, et c’est précisément le but.

FAQ

Tailscale nécessite-t-il une redirection de port ?

Non. Chaque nœud Tailscale établit uniquement des connexions sortantes. Il contacte le serveur de coordination sur TCP 80, puis bascule vers HTTPS sur TCP 443 si le port 80 ne répond pas. Il découvre son adresse publique avec STUN sur UDP 3478. Chaque connexion entre pairs commence par un relais DERP sur TCP 443, toujours en sortie. Elle passe ensuite sur un chemin direct grâce au hole punching UDP depuis le port 41641. Si le hole punching échoue, le trafic passe par un relais pair si vous en avez configuré un, ou reste sur DERP. Un routeur domestique n’a jamais besoin d’une redirection de port ni d’un hôte en DMZ. Un appareil derrière un CGNAT rejoint le réseau de la même manière.

Tailscale peut-il remplacer la redirection de port pour un serveur Minecraft ?

Oui, pour un serveur que vos amis rejoignent. Installez Tailscale sur le PC de jeu, partagez cette machine avec chaque ami depuis la page Machines de la console d’administration, puis ils se connectent à son adresse tailnet sur le port 25565, sans redirection de port. Tailscale ne remplace pas la redirection de port pour un serveur public, car les joueurs situés en dehors de votre tailnet ne peuvent pas atteindre le nœud. Dans ce cas, hébergez le jeu sur un VPS doté d’une IP publique et gardez RCON sur le tailnet, ou utilisez un reverse tunnel depuis le serveur domestique vers un VPS.

Quels ports Tailscale utilise-t-il ?

Quatre. TCP 80 en sortie est la connexion privilégiée au serveur de coordination, transportée dans le protocole chiffré de Tailscale. TCP 443 en sortie est utilisé pour cette connexion si le port 80 ne répond pas. Il transporte toujours le trafic des relais DERP. UDP 3478 en sortie est utilisé par STUN pour découvrir l’adresse publique. UDP 41641 est le port WireGuard local utilisé par défaut pour les connexions directes : les paquets partent de ce port vers le port utilisé par le pair, quel qu’il soit. Vous pouvez le modifier si 41641 est déjà utilisé. Aucun de ces ports ne doit être ouvert en entrée. Bloquer TCP 80 ne pose donc pas de problème, car le client bascule vers 443. Autoriser UDP 41641 en entrée sur un VPS est facultatif. Cela permet plus souvent aux pairs d’utiliser un chemin direct.

Pourquoi ma connexion Tailscale passe-t-elle par un relais au lieu d’être directe ?

tailscale ping continue de répondre via DERP lorsque le hole punching UDP ne peut pas aboutir. Les causes habituelles sont un NAT que le hole punching ne peut pas traverser (CGNAT ou NAT symétrique qui attribue un nouveau port pour chaque destination) et un firewall qui bloque l’UDP sortant. Corrigez ce que vous contrôlez : autorisez l’UDP sortant depuis le port 41641 vers n’importe quel port de destination, autorisez l’UDP sortant vers le port 3478, ou placez un pair sur un VPS avec UDP 41641 ouvert en entrée. L’autre côté disposera ainsi d’une cible fixe et accessible pour le hole punching. Un pair dont le réseau bloque l’UDP restera relayé dans tous les cas.