Pourquoi le client Tailscale sous Linux ignore les routes de sous-réseau annoncées

Vous êtes sur un ordinateur portable Linux, tailscale status liste les autres machines, et le NAS à 10.80.0.25 expire toujours. Le tailnet est sain, le routeur de sous-réseau est en ligne, et rien dans la sortie du client ne dit pourquoi le LAN derrière lui est injoignable. Le parcours ci-dessous part de ce symptôme vers l'extérieur : l'indicateur sur ce client, puis l'annonce sur le routeur, puis l'approbation, puis la politique, et seulement ensuite la destination elle-même. Chaque porte échoue avec le même délai d'expiration, donc l'ordre compte plus que les commandes.

Ce que le client Linux refuse d'installer

Les clients Tailscale sous Linux n'acceptent pas les routes de sous-réseau annoncées sauf si vous le leur demandez. Sans ce réglage, le client rejoint le tailnet et atteint les adresses des pairs, tandis que chaque préfixe annoncé par le routeur reste inutilisé. La valeur par défaut est délibérée, et c'est pourquoi le symptôme ressemble à un routeur cassé plutôt qu'à une décision locale.

Deux choses différentes s'appellent ici routage, et une seule est la vôtre. Le routeur annonce un préfixe dans le tailnet ; votre machine décide de l'installer ou non. Une défaillance de l'un ou de l'autre produit le même délai, c'est pourquoi deviner fait perdre un après-midi. Trouvez quel côté refuse avant de modifier quoi que ce soit.

Activez l'acceptation des routes pour cette machine

Réglez la préférence sur le client, puis regardez ce qui a changé au lieu de supposer que la commande a pris effet. La forme actuelle applique le réglage sans répéter le flux de connexion, ce qui compte lorsque vous êtes au milieu d'une session.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale installe les routes acceptées dans sa propre table sous Linux, donc un préfixe qui apparaît dans la table 52 est la preuve directe que ce client a installé l'annonce. Si votre plage est absente de cette table, arrêtez-vous : le problème est local et aucun travail sur le routeur ne le changera.

Les clients plus anciens exposent la même préférence comme indicateur de la commande de connexion, donc sudo tailscale up --accept-routes est la solution de repli quand tailscale set manque. Utilisez-la plutôt que de modifier les routes à la main, car le démon réécrit sa propre table et votre modification disparaît à la prochaine reconnexion. Vérifiez la version avant de copier une commande d'un ancien article.

Vérifiez l'annonce et l'approbation séparément

Sur le routeur de sous-réseau, le préfixe doit être annoncé, et le noyau doit transférer les paquets entre les interfaces. Annoncer sans transférer vous donne une route approuvée qui supprime silencieusement le trafic, ce qui est la configuration à moitié terminée la plus courante.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Comparez le préfixe annoncé à l'adresse que vous essayez réellement d'atteindre, caractère par caractère. Un routeur qui annonce 10.70.0.0/24 ne dit rien d'un NAS à 10.80.0.25, et la discordance est invisible dans toute sortie d'état car les deux nombres semblent également plausibles. La plupart des signalements de route cassée s'arrêtent ici. Corrigez l'annonce avant de toucher quoi que ce soit en aval.

L'approbation est la porte suivante, et il est facile de l'omettre quand le routeur a été configuré depuis un shell. L'annonce doit être activée pour cet appareil dans la console d'administration avant que d'autres machines puissent l'utiliser. Accepter des routes sur le client n'approuve rien et ne contourne aucune règle d'accès.

Testez l'adresse privée avant le nom d'hôte

Une connexion réussie à l'adresse tailnet du routeur lui-même prouve que le tailnet fonctionne, ce que vous saviez déjà. Le test utile est le service dont vous avez réellement besoin, d'abord contre l'adresse privée, afin qu'une défaillance DNS ne puisse pas se faire passer pour une défaillance de routage.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

Si l'adresse répond et pas le nom d'hôte, vous avez un problème de résolution de noms et vous devriez cesser de le traiter comme un problème de route. Si aucun des deux ne répond, revenez une section en arrière et confirmez que l'annonce couvre l'adresse. Les deux défaillances sont identiques vues de l'application et se corrigent à des endroits différents.

Une vérification locale vaut la peine avant d'accuser le tailnet. Lorsque votre LAN actuel utilise le même préfixe que le sous-réseau distant, le noyau préfère la route directement connectée et le trafic ne quitte jamais la machine ; c'est ce qui se passe quand une maison et un bureau choisissent tous deux 192.168.1.0/24.

Pourquoi un indicateur client n'est pas un réglage de routeur

Ce sont des rôles différents avec des exigences différentes, et copier un indicateur client sur un routeur est la façon dont un tailnet fonctionnel acquiert une boucle. Une machine qui annonce des routes a besoin du transfert, de règles de pare-feu autorisant le trafic transféré et d'une décision sur les préfixes qu'elle annonce. Rien de tout cela n'est impliqué par --accept-routes.

La documentation des routeurs de sous-réseau déconseille d'activer l'acceptation des routes sur des routeurs redondants qui annoncent un seul préfixe, car un nœud de secours peut pousser du trafic déjà local à travers le nœud actif. Si vous exploitez une paire HA, traitez cela comme une contrainte de conception et non comme une note de bas de page, et décidez quel nœud possède le préfixe avant de l'approuver sur les deux. Sur un routeur unique, le même avertissement se lit comme un rappel que l'acceptation appartient aux clients, pas à la machine qui annonce. Notez quelle porte était fermée.

Pour un client ordinaire, la séquence se termine par le test applicatif qui a échoué au début. Pour le routeur, passez en revue le transfert, l'annonce, l'approbation et le pare-feu dans cet ordre, car le premier manquant produit exactement le délai avec lequel vous avez commencé.