Pourquoi une route de sous-réseau Tailscale approuvée arrive toujours en délai dépassé

L’approbation dans la console d’administration ressemble à la dernière étape, et ce n’est pas le cas. L’application dépasse d’abord le délai, et ce n’est qu’ensuite que vous trouvez le routeur en ligne et la route approuvée. L’approbation est une étape de distribution, ni une autorisation ni une garantie de transfert. Quatre étapes doivent s’aligner avant qu’un paquet atteigne un hôte derrière un routeur de sous-réseau, et chacune peut réussir alors que la suivante échoue. Parcourez-les dans l’ordre et arrêtez-vous à la première étape qui ne tient pas.

Quatre étapes, une défaillance

Le routeur annonce le préfixe, le tailnet approuve cette annonce, le client accepte la route qu’il a reçue, et la politique d’accès autorise la connexion précise. Ce sont quatre décisions distinctes prises par trois composants différents. Une route approuvée ne dit donc que ceci : le réseau fait désormais partie de la table de routage du tailnet.

La quatrième étape est la plus souvent omise, car les trois premières produisent un état visible. Une autorisation qui couvre l’adresse tailnet du routeur lui-même ne couvre pas automatiquement un sous-réseau privé derrière lui. Ce sont des destinations différentes, et la politique s’évalue par destination.

Sous Linux, la troisième étape a aussi un comportement par défaut qui surprend : accepter les routes de sous-réseau est facultatif. Plusieurs clients graphiques acceptent par défaut les routes annoncées, si bien qu’un parc mixte peut montrer une machine en échec alors que les autres fonctionnent.

Confirmez le réglage sur la machine en échec plutôt que de supposer une plateforme. La route n’a jamais été la pièce manquante sur les machines qui fonctionnent, alors laissez-les prouver que le côté tailnet est sain. La documentation de Tailscale sur les routeurs de sous-réseau couvre l’approbation, l’acceptation des routes par le client et l’étape de politique.

Vérifiez la route là où le client s’exécute

Commencez par le client en échec, pas par le routeur. Confirmez que la route est présente et que le réglage du client autorise du tout l’acceptation des routes.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

La première commande montre la liste des pairs et si le routeur de sous-réseau est joignable, la deuxième imprime les préférences du client, dont l’indicateur d’acceptation des routes, et la troisième demande au noyau quelle interface il utiliserait pour un hôte réel du sous-réseau. Si cette dernière commande nomme l’interface physique au lieu de l’interface Tailscale, la route n’est jamais entrée dans la table. Une route absente est un problème côté client, pas un problème d’approbation. Corrigez-la avant de regarder la politique.

Pour accepter des routes sous Linux, reconnectez-vous avec l’indicateur au lieu de supposer qu’il est défini : tailscale up --accept-routes. Un client joint avec d’autres indicateurs les conserve jusqu’à ce qu’ils soient modifiés, alors vérifiez le réglage actuel avant d’en ajouter un autre. Relancer la première commande après le changement devrait montrer la route dans la table.

Prouvez le transfert et le chemin de retour

L’approbation ne configure pas le routeur pour transférer des paquets et n’organise pas la réponse. Les deux relèvent de l’hôte, côté LAN du routeur. Testez-les sur le routeur, pas sur le client.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

La première commande doit rapporter 1, sinon le noyau rejettera le paquet transféré. La deuxième montre si le masquage de la route de sous-réseau réécrit la source, ce qui est le comportement par défaut et généralement ce que vous voulez. La troisième montre si la requête atteint la destination et si quelque chose revient ; une requête sans réponse est un problème de chemin de retour, pas d’approbation. Lisez les trois résultats ensemble avant d’en modifier un seul.

Si le masquage a été désactivé, le réseau de destination a besoin d’une route de retour vers les adresses du tailnet, et chaque saut intermédiaire doit la connaître. Réactiver le masquage est la correction la plus rapide pour un seul service, au prix de cacher l’adresse d’origine du client à la destination. Cet arbitrage compte lorsque la destination journalise les adresses source pour l’audit, alors décidez-le délibérément au lieu de basculer l’indicateur pendant un incident. Documentez le choix retenu, car la personne suivante ne verra qu’un seul des deux comportements.

Lisez la règle d’accès pour la ressource

La route étant présente et le transfert prouvé, le suspect restant est la politique. Lisez l’autorisation censée permettre la connexion et vérifiez sa destination, pas seulement sa source. L’identité du client doit aussi correspondre au sélecteur de la politique, alors relevez-la depuis la même machine qui échoue.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

La sortie d’état identifie les adresses propres du client et les pairs qu’il voit, ce à quoi le sélecteur de source de la politique doit correspondre. tailscale ping prouve le chemin tailnet jusqu’au routeur de sous-réseau lui-même ; il résout les noms de pairs et les adresses tailnet, pas les hôtes d’un sous-réseau annoncé. La troisième commande envoie un écho ICMP ordinaire par la route de sous-réseau, son résultat décrit donc la destination plutôt que le routeur. Un refus au niveau du tailnet revient généralement comme un refus, tandis qu’un paquet qui part et ne revient jamais dépasse le délai.

Un nom qui échoue est une autre question qu’une adresse qui échoue ; résolvez l’hôte directement avant d’accuser la route. Écrivez l’autorisation selon le besoin réel de la ressource et non selon tout le sous-réseau. Ouvrir un /24 entier pour qu’une application fonctionne, c’est ainsi qu’une demande étroite devient une autorisation large que personne n’ose ensuite retirer.

Si l’objectif était une sortie internet et non un sous-réseau privé, le bon composant est un nœud de sortie, pas un routeur de sous-réseau, et la politique comme le routage diffèrent en conséquence. Vérifiez cette décision avant d’élargir une autorisation. Un nœud de sortie change la route par défaut ; un routeur de sous-réseau ne fait qu’annoncer un préfixe.