Un hôte Tailscale injoignable : routeur de sous-réseau ou nœud de sortie ?

Un hôte Tailscale répond pendant qu’un autre reste muet, ou tout fonctionne jusqu’à ce que les sites web publics se mettent à signaler le mauvais pays. Les deux plaintes arrivent sous la forme « Tailscale est cassé », et les deux sont généralement la mauvaise construction activée pour la mauvaise destination. Un routeur de sous-réseau expose un réseau privé au tailnet, tandis qu’un nœud de sortie change l’endroit d’où part le trafic internet. Trie d’abord la destination qui échoue, puis choisis le rôle qui la couvre.

Commence par la destination qui a échoué

Note l’adresse ou le nom qui n’a pas fonctionné, et de quel type d’objet il s’agit. Un appareil sur un LAN privé derrière un autre site, un service sur ton propre segment et un site web public sont trois problèmes de routage qui partagent un seul client par hasard. La distinction n’est pas cosmétique, car les deux constructions couvrent des ensembles de destinations différents. Activer l’une ne fait rien pour l’autre, et c’est toute la source de la confusion.

Note aussi la famille d’adresses. Un sous-réseau annoncé uniquement en IPv4 laisse les destinations IPv6 sur le chemin local, ce qui se lit comme une défaillance partielle jusqu’à ce que quelqu’un compare les deux tables de routage. Note le chemin que tu attendais, pour que le test ait ensuite quelque chose à contredire.

Atteins un appareil qui n’exécute jamais Tailscale

Le routeur annonce des plages précises au tailnet, puis relaie les paquets entre le tailnet et le segment privé, si bien que les appareils de ce segment n’ont pas besoin de leur propre client. Atteindre un NAS au bureau depuis un portable à la maison est exactement ce cas. Le routeur est le seul membre du tailnet de ce côté.

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

L’annonce n’est que la première de trois conditions. La route doit être approuvée pour le tailnet, le client doit accepter les routes annoncées, et une règle d’accès doit autoriser la connexion. C’est cette chaîne qui explique que le symptôme soit si souvent que le routeur fonctionne et que le NAS non. Un routeur joignable prouve que le tunnel fonctionne ; il ne prouve rien sur l’approbation, l’acceptation par le client ou la politique.

Chacune de ces trois défaillances se présente différemment dans la console d’administration. Vérifie-les dans l’ordre plutôt que de changer les trois à la fois, car un second changement masque laquelle comptait.

Fais sortir le trafic public par une autre machine

Un nœud de sortie achemine ton trafic internet général à travers lui-même, ce qui est l’équivalent le plus proche du tunnel complet des autres produits VPN. Il demande lui aussi trois consentements distincts : l’appareil annonce le rôle, un administrateur l’autorise et le client le sélectionne. Rejoindre un tailnet n’envoie rien via un autre membre par défaut.

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

Sélectionner un nœud de sortie ne donne pas automatiquement accès à son propre LAN. L’option d’accès au LAN existe précisément parce que ce sont des permissions différentes, et la laisser désactivée est la valeur par défaut la plus sûre. Les routes vers d’autres ressources Tailscale gardent leur propre traitement même lorsqu’un nœud de sortie est actif. C’est pourquoi un service hébergé sur un sous-réseau peut continuer à fonctionner alors que le chemin internet public a changé.

Un nœud de sortie change aussi la façon dont internet te voit, pas seulement la vitesse ressentie. Attends-toi à ce que la géolocalisation, les catalogues de streaming et les limites de débit suivent l’adresse de la sortie plutôt que la tienne.

Lis la répartition en trois quand un seul hôte échoue

Une imprimante sur ton segment, un NAS derrière un routeur de sous-réseau distant et un site public sont trois destinations avec trois chemins différents. Si exactement l’une d’elles échoue, le défaut appartient au chemin de cette destination et non au client dans son ensemble. Pour l’imprimante locale pendant qu’un nœud de sortie est utilisé, le réglage d’accès au LAN est la réponse habituelle. Pour le NAS distant, vérifie la plage annoncée, son état d’approbation et les règles d’accès dans cet ordre. Pour un site public, vérifie quel nœud de sortie est sélectionné et si le client l’a réellement accepté.

Si l’adresse fonctionne et que le nom non, arrête de regarder les routes. Le DNS privé se configure séparément, et un nom qui résout vers la mauvaise adresse échoue d’une manière identique à une route bloquée. Teste d’abord l’adresse, puis le nom, et les deux résultats te disent quelle couche ouvrir.

Confirme le chemin que tu crois avoir construit

La vérification est une recherche de route plus un contrôle d’adresse, pas un ping. La recherche indique quelle interface une destination utiliserait, et le contrôle d’adresse indique dans quelle plage la destination vit réellement. Un ping qui réussit dit que l’hôte est vivant quelque part, ce qui n’est pas la question. Exécute les deux avant de modifier une configuration.

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

Complète cela avec la vue propre au tailnet, qui montre si le pair est connecté directement ou relayé. Un chemin relayé fonctionne quand même, et cela explique des plaintes de latence qui n’ont rien à voir avec la route que tu déboguais. la documentation du routeur de sous-réseau couvre l’étape d’approbation si elle ne t’est pas familière. Note ensuite quelle construction couvre quelle destination dans ton propre réseau, car la prochaine personne qui ajoutera un site posera la même question.