Tailscale : corriger « relay server unavailable »

« Relay server unavailable » : la réponse courte

Quand Tailscale affiche « relay server unavailable », le client n'arrive plus à ouvrir une connexion vers un serveur relais DERP. Le tailnet n'est pas cassé et vos clés sont intactes. Ce qui a changé se trouve sur la machine ou devant elle : la sortie réseau, la résolution DNS ou l'horloge. Le diagnostic ci-dessous se déroule dans un ordre précis, et il s'arrête presque toujours avant la fin.

La documentation Tailscale publie cet avertissement sous l'identifiant no-derp-connection. Son titre est « Relay server unavailable » et son texte est « Tailscale could not connect to the <derp-server> relay server. Your internet connection might be down, or the server might be temporarily unavailable. » Un message voisin existe, no-derp-home, intitulé « No home relay server », avec le texte « Tailscale could not connect to any relay server. » La formulation a changé au fil des versions du client, donc notez la vôtre avec tailscale version et comparez avec la référence officielle des messages plutôt qu'avec une capture trouvée sur un forum.

Que sont les relais DERP

Tailscale opère un réseau de relais qu'il nomme DERP (Designated Encrypted Relay for Packets). Ces serveurs font deux choses. Ils aident deux machines à percer leur NAT (network address translation, la traduction d'adresses faite par votre box), et ils transportent le trafic WireGuard chiffré quand aucun chemin direct n'existe. Le relais ne voit jamais votre trafic en clair : il transmet des paquets déjà chiffrés de bout en bout, ce qui est aussi la raison pour laquelle un relais hébergé par Tailscale ne détient pas les clés qui chiffrent vos données.

Un relais se joint en TCP sur le port 443, avec du TLS (transport layer security, le chiffrement du web). C'est volontaire : le 443 sort de presque tous les réseaux, y compris ceux qui bloquent l'UDP. Chaque nœud choisit ensuite une région de relais « maison » et s'y enregistre, pour que ses pairs sachent où le trouver. La région parisienne porte le code par, et la liste complète des régions et de leurs noms d'hôtes est publique, servie par https://login.tailscale.com/derpmap/default.

Pourquoi plus rien n'est joignable, pas même en direct

C'est le point qui surprend. Une session Tailscale ne commence pas en direct : elle commence par le relais, puis elle est promue en direct si les deux côtés y arrivent. Donc un client sans relais joignable ne peut ouvrir aucune session, même avec un pair posé sur le même réseau local. Le nœud apparaît hors ligne dans la console d'administration parce que c'est sa connexion au plan de contrôle (controlplane.tailscale.com) qui le marque en ligne, et cette connexion emprunte les mêmes ports et le même TLS que les relais.

Tailscale échoue en fermant, pas en ouvrant. Il n'existe aucun repli en clair, donc le client préfère ne rien transporter plutôt que de transporter mal. C'est pour cela qu'un seul problème de sortie réseau vous coupe de tout votre parc d'un coup. Si vous voulez l'image d'ensemble avant de creuser, le rôle du plan de contrôle et celui du plan de données est expliqué à part.

Un détail aggrave souvent le tableau. Si MagicDNS est actif, votre /etc/resolv.conf pointe vers 100.100.100.100, une adresse servie par tailscaled lui-même. Quand le démon va mal, la résolution des noms en .ts.net échoue aussi, donc votre ssh monvps s'arrête au DNS et pas au réseau. Le message d'erreur n'est alors pas celui que vous attendez, et savoir distinguer un refus de connexion d'un délai d'attente vous évite de chercher au mauvais endroit.

Étape 1 : lire tailscale status avant tout

tailscale status
tailscale version

Ne lisez pas d'abord la liste des pairs. Lisez le bloc de santé que tailscale status ajoute, sur les lignes commençant par #. C'est là que le client écrit ses avertissements, dont celui qui nous occupe. Pour chaque pair, la colonne d'état indique soit un chemin direct, soit relay suivi du code de la région utilisée. Cette information ne vaut que si le client parle déjà aux relais.

Si la commande ne répond pas du tout et se plaint de ne pas joindre le démon local, le problème est plus bas que le réseau : tailscaled ne tourne pas.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 100 --no-pager

Le journal du démon est la source la plus utile de toute cette page. Les erreurs de certificat, les échecs de résolution et les délais d'attente vers les relais y apparaissent avec le nom d'hôte exact que le client a essayé. Si le service ne démarre pas du tout, ou s'il a disparu après une mise à jour du système, le sujet est ailleurs et les erreurs d'installation du paquet Tailscale sur Ubuntu couvrent ce cas.

Étape 2 : tailscale netcheck et les champs à regarder

tailscale netcheck

Cette commande sonde vos conditions réseau réelles. Voici ce que veulent dire les champs utiles ici. Les valeurs, elles, dépendent de votre ligne : lisez les vôtres, ne cherchez pas à les comparer à des chiffres recopiés.

• UDP indique si la machine arrive à envoyer des paquets UDP sortants. Une réponse négative signifie que les serveurs STUN (session traversal utilities for NAT, ceux qui vous renvoient votre adresse publique) n'ont rien reçu, donc le chemin direct est exclu.
• IPv4 et IPv6 donnent l'adresse et le port publics tels qu'ils sont vus de l'extérieur. Un champ IPv6 rempli sur une machine dont la route IPv6 est cassée est un piège, traité à l'étape 6.
• MappingVariesByDestIP dit si votre adresse vue change d'un relais à l'autre. Une réponse positive désigne un NAT symétrique, celui qui choisit un port différent pour chaque destination.
• PortMapping liste les protocoles de mappage de ports que votre routeur propose, parmi UPnP, NAT-PMP et PCP.
• La liste des latences par région de relais est le champ décisif pour cette page. Si aucune région ne répond, le client n'a pas de chemin vers les relais, et c'est bien le problème que vous cherchez.

La distinction est importante. Des latences qui s'affichent pour plusieurs régions prouvent que les relais sont joignables, donc vous n'avez pas le problème de cette page. Un chemin qui reste relayé alors que les relais répondent est une autre histoire, traitée dans pourquoi une connexion Tailscale reste relayée au lieu de passer en direct.

Étape 3 : est-ce simplement le DNS ?

Le client ne peut pas ouvrir de TLS vers un nom qu'il n'arrive pas à résoudre. Vérifiez les deux noms qui comptent, celui du plan de contrôle et celui d'un relais.

resolvectl query controlplane.tailscale.com
resolvectl query derp18b.tailscale.com
dig +short controlplane.tailscale.com @1.1.1.1

Le troisième appel contourne votre résolveur local et interroge un résolveur public. S'il réussit alors que les deux premiers échouent, votre résolveur est le coupable. Sur un VPS, la cause la plus fréquente est une boucle : /etc/resolv.conf pointe encore vers 100.100.100.100, l'adresse servie par tailscaled, alors que le démon est arrêté ou en mauvaise santé. Le client a besoin du DNS pour joindre le plan de contrôle, et le DNS attend le client.

cat /etc/resolv.conf
resolvectl status

Pour sortir de cette boucle, remettez un résolveur public dans la configuration du système le temps de relancer le tunnel, ou coupez la reprise du DNS avec sudo tailscale set --accept-dns=false, puis réactivez-la une fois le nœud revenu. Le mécanisme est celui décrit dans la réparation du DNS qui casse au montage d'un tunnel WireGuard, puisque Tailscale réécrit le resolv.conf de la même façon.

Étape 4 : la sortie réseau, TCP 443 pour les relais et UDP pour le direct

Un client Tailscale a besoin de sortir sur ces destinations. TCP vers *:443 pour le plan de contrôle et les relais. TCP vers *:80 pour la sélection du plan de contrôle et la détection de portail captif. UDP depuis le port 41641 vers n'importe quelle destination, pour les tunnels WireGuard directs. UDP vers *:3478 pour le STUN. Les noms à autoriser sont controlplane.tailscale.com, login.tailscale.com, console.tailscale.com, log.tailscale.com et les noms de relais en derp*.tailscale.com. Tailscale demande d'autoriser des noms et des plages larges plutôt que des adresses IP figées, parce que ces adresses changent.

Notez la séparation, elle vous fait gagner du temps. Les relais n'ont besoin que du TCP 443. Si le blocage ne portait que sur l'UDP, vous auriez un tunnel lent mais vivant. Un message de relais injoignable veut dire que même le 443 ne passe plus.

curl -sS -I --max-time 10 https://controlplane.tailscale.com
nc -vz derp18b.tailscale.com 443

Sur le premier appel, le code HTTP renvoyé n'a aucune importance. Ce qui compte est d'obtenir une réponse TLS plutôt qu'un délai d'attente. Un délai d'attente sur les deux commandes désigne un filtre en sortie. Cherchez-le sur la machine elle-même, dans le pare-feu réseau de votre hébergeur, qui est un réglage séparé sur la plupart des panneaux, puis sur la box ou le proxy placé devant. Si vous avez récemment durci la machine, une politique de sortie fermée est le premier suspect, et les règles de base d'ufw sur un VPS rappellent qu'un deny outgoing casse Tailscale sans écrire le moindre message côté pare-feu. Pour tester un port sans nc, plusieurs méthodes pour vérifier qu'un port est ouvert sous Linux donnent des équivalents disponibles partout.

Étape 5 : l'horloge d'un VPS sans écran

Les relais et le plan de contrôle sont joints en TLS, et la validation d'un certificat compare ses dates de validité à l'horloge locale. Un décalage de quelques minutes suffit à faire échouer la poignée de main. Le journal de tailscaled montre alors une erreur x509 disant que le certificat a expiré ou n'est pas encore valide, ce qui ressemble à une panne de Tailscale sans en être une.

Ce cas arrive surtout après une restauration de snapshot, après une longue suspension de la machine, ou quand le service NTP (network time protocol, la synchronisation de l'heure) n'a jamais démarré sur une image minimale.

timedatectl status
sudo timedatectl set-ntp true
sudo systemctl restart tailscaled

timedatectl status doit annoncer une horloge synchronisée. Si elle ne l'est pas, aucune autre étape de cette page ne servira, parce que chaque tentative de connexion sera rejetée au moment du certificat.

Étape 6 : l'IPv6 à moitié configurée

Voici le cas le plus difficile à voir. La machine a une adresse IPv6 globale, le résolveur renvoie bien des enregistrements AAAA, mais la route IPv6 de l'hébergeur ou du fournisseur d'accès ne fonctionne pas. Le client résout un relais en IPv6, tente cette adresse, et la connexion reste suspendue au lieu d'échouer tout de suite. Le résultat ressemble à une panne de relais alors que la même machine joindrait ce relais en IPv4 sans problème.

curl -4 -sS -I --max-time 10 https://derp18b.tailscale.com
curl -6 -sS -I --max-time 10 https://derp18b.tailscale.com

Si l'appel en -4 répond et que l'appel en -6 expire, votre IPv6 est cassée. Réparez la route, ou retirez l'adresse IPv6 que l'hébergeur vous a attribuée sans route utilisable. Ne coupez pas l'IPv6 par réflexe sur tout votre parc : là où elle fonctionne, elle donne souvent le meilleur chemin direct.

Freebox, Livebox, box 4G et réseaux d'hôtel

La plupart des conseils que vous trouverez en français parlent d'ouvrir un port sur la box. Pour ce problème précis, c'est hors sujet, et il faut le dire clairement. Un relais se joint en sortie sur le 443 : aucune box grand public ne bloque cela, et aucune redirection de port n'est nécessaire. Le NAT de votre Freebox ou de votre Livebox gêne le chemin direct, pas le chemin relayé.

Ce qui casse vraiment un relais derrière une box française est ailleurs. Un contrôle parental ou un filtrage DNS activé sur la box peut refuser de résoudre les noms de Tailscale, et vous obtenez alors le symptôme de l'étape 3. Un profil horaire de contrôle parental peut couper l'accès d'un appareil entier à heure fixe, ce qui donne un tailnet vivant le matin et muet le soir. Un serveur DNS personnalisé saisi dans l'interface de la box, oublié là après un changement d'opérateur, produit le même effet.

Sur une box 4G ou 5G, vous êtes derrière du CGNAT (carrier grade NAT, le partage d'une même adresse publique entre plusieurs abonnés). Le CGNAT interdit les connexions entrantes et complique le chemin direct. Il n'empêche pas de sortir en 443, donc il ne produit pas ce message. Un tailnet en CGNAT est relayé et parfois lent, pas silencieux.

Le vrai réseau hostile est celui d'une entreprise ou d'un hôtel. Deux cas s'y présentent. Le portail captif, où rien ne sort avant que vous n'ayez accepté les conditions dans un navigateur : le message de relais injoignable est alors le premier symptôme, et il disparaît dès l'authentification. Puis le proxy à inspection TLS, qui présente son propre certificat à la place de celui du relais. Le client valide la chaîne, la validation échoue, et la connexion est refusée. Aucune option de Tailscale ne contourne ce proxy : il faut que l'exploitant du réseau exempte les noms de domaine listés à l'étape 4.

Redémarrer le client proprement

Quand la cause est corrigée, relancez la pile dans cet ordre.

sudo tailscale down --accept-risk=lose-ssh
sudo systemctl restart tailscaled
sudo tailscale up
tailscale status

Attention avec tailscale down si votre seul accès à la machine passe par Tailscale SSH : vous perdez la session tout de suite. Gardez une console de secours ouverte chez votre hébergeur avant de lancer cette commande. Si rien n'a bougé, tailscale bugreport produit un identifiant de diagnostic à joindre à une demande au support, et https://status.tailscale.com vous dit si une région de relais est réellement en incident. Une panne de région reste rare, et le client bascule normalement vers la région suivante.

Où cette page s'arrête

Cette page traite un client qui ne joint aucun relais. Elle ne traite pas un client qui les joint et qui reste lent. Si tailscale netcheck liste des latences et que vos pairs restent en relay, le sujet devient l'analyse du chemin, couverte par le diagnostic d'une liaison Tailscale qui reste relayée. Si vous administrez votre propre plan de contrôle, les noms d'hôtes et les relais cités ici ne sont pas les vôtres, et un plan de contrôle Headscale auto-hébergé change la liste des destinations à autoriser en sortie.

FAQ

Pourquoi mon nœud est-il hors ligne alors que le VPS répond au ping ?

Parce que l'état « en ligne » dans la console d'administration décrit la connexion du nœud au plan de contrôle de Tailscale, pas sa joignabilité en ICMP. Le VPS répond au ping sur son adresse publique pendant que tailscaled n'arrive pas à sortir en TCP 443 vers controlplane.tailscale.com. Lisez le bloc de santé de tailscale status, puis journalctl -u tailscaled : la cause y est nommée, le plus souvent un délai d'attente, un échec de résolution ou une erreur x509.

« Relay server unavailable » signifie-t-il que Tailscale est en panne ?

Presque jamais. Le message décrit l'échec de votre client à joindre un relais, pas l'état du relais. Vérifiez d'abord votre sortie réseau, votre DNS et votre horloge, puis consultez https://status.tailscale.com si ces trois points sont sains. En cas d'incident réel sur une région, le client tente la région suivante de lui-même, donc une panne régionale isolée ne coupe pas un tailnet entier.

Faut-il ouvrir un port sur ma Freebox pour que les relais fonctionnent ?

Non. Les relais se joignent en connexion sortante sur le port 443 en TCP, et toutes les box autorisent cela par défaut. Ouvrir l'UDP 41641 en entrée aide le chemin direct, ce qui améliore la latence et le débit, mais cela ne change rien à un client qui ne joint aucun relais. Si le blocage vient bien de la box, regardez son contrôle parental et son filtrage DNS, pas ses redirections de port.

Une horloge décalée peut-elle vraiment casser Tailscale ?

Oui, et c'est une cause classique sur un VPS restauré depuis un snapshot. La connexion au plan de contrôle et aux relais utilise TLS, et la validation du certificat compare ses dates à l'heure locale. Un décalage de quelques minutes fait échouer cette validation, et le journal du démon affiche une erreur x509 signalant un certificat expiré ou pas encore valide. timedatectl status doit annoncer une horloge synchronisée avant tout autre test.