Que devez-vous vérifier lorsque Tailscale ne peut pas atteindre votre serveur domestique ?

Lorsque Tailscale ne peut pas atteindre votre serveur domestique, la panne ne se situe pas toujours dans le réseau Tailscale lui-même. Le serveur peut être hors ligne, le nom de l'appareil peut ne pas se résoudre, une règle d'accès peut rejeter la connexion, le pare-feu du système d'exploitation peut bloquer le service, ou l'application peut n'écouter que sur localhost.

La façon la plus rapide de trouver la cause est de dépanner par couches. Confirmez d'abord que les deux nœuds Tailscale sont en ligne. Testez ensuite l'IP brute Tailscale du serveur, séparez la connectivité basique du nœud de l'accès à l'application, et ne passez au routage de sous-réseau ou au dépannage DERP que lorsque les symptômes l'indiquent réellement.

Commencez par identifier quelle couche échoue

Une erreur courante lors du dépannage est de traiter chaque expiration comme le même problème. Un serveur domestique qui semble hors ligne dans le tailnet est différent d'un serveur qui répond au ping Tailscale mais refuse une connexion SSH ou web.

Tailscale fournit le chemin réseau privé entre les appareils, mais le service final dépend toujours du système d'exploitation du serveur, du pare-feu, du port d'écoute, de la configuration de l'application, du réseau Docker et de la politique d'accès. Corriger la mauvaise couche peut créer des problèmes supplémentaires sans rétablir la connexion.

Avant de modifier quoi que ce soit, notez le symptôme exact. Vérifiez si le serveur apparaît en ligne, si son IP Tailscale répond, si son nom MagicDNS se résout, et si le port d'application spécifique accepte une connexion.

Confirmez que les deux nœuds Tailscale sont en ligne

Commencez par les deux appareils impliqués dans la connexion. L'ordinateur portable ou le téléphone distant doit être connecté au tailnet, et le serveur domestique doit également être en ligne sous le compte, le tag ou l'identité de l'appareil attendus.

Sur un serveur Linux, vérifiez le service Tailscale et exécutez tailscale status. Sur les systèmes de bureau, vérifiez que le client est connecté et non en pause, déconnecté ou en attente d'authentification. Un serveur qui n'a pas réussi à démarrer Tailscale après un redémarrage ne peut pas être réparé en modifiant les ports DNS ou d'application.

Vérifiez également si le serveur apparaît sous le nom d’appareil et l’IP Tailscale attendus. Si le nœud est hors ligne, corrigez le service, l’état de connexion, le comportement de démarrage système ou la version du client avant de dépanner quoi que ce soit au-dessus de la couche réseau.

Utilisez l’IP Tailscale brute avant de tester un nom d’hôte

Un nom d’hôte ajoute la résolution DNS au chemin de connexion. Si vous commencez par un nom de serveur tel que serveurdomestique ou appareil-nas, vous ne pouvez pas immédiatement dire si l’échec vient du réseau ou de la résolution de nom.

Trouvez l’adresse IPv4 Tailscale du serveur, normalement dans la plage 100.x.x.x, et essayez cette adresse directement. Lorsque les routes LAN, les nœuds de sortie ou les sous-réseaux qui se chevauchent compliquent le chemin, il est particulièrement utile de tester l’IP Tailscale de l’appareil avant son adresse LAN privée.

Si l’IP brute fonctionne mais que le nom d’hôte ne fonctionne pas, la connectivité de base du nœud est probablement saine. Passez à MagicDNS et aux paramètres DNS du client au lieu de réinstaller Tailscale ou de changer le routeur.

Si l’IP fonctionne mais que le nom échoue, vérifiez MagicDNS

MagicDNS permet aux appareils d’utiliser des noms de machine lisibles au lieu de mémoriser les adresses IP Tailscale. Lorsqu’il fonctionne, un appareil nommé serveur-domestique peut être atteint par ce nom depuis un autre appareil dans le même tailnet.

La fonctionnalité crée des noms d’appareils automatiques dans le tailnet, mais la résolution réussie dépend toujours de la connexion de l’appareil et de l’acceptation par le client de la configuration DNS du tailnet. Les filtres DNS locaux, les outils de sécurité d’entreprise, les résolveurs personnalisés ou les enregistrements mis en cache obsolètes peuvent interférer.

Comparez le nom d’hôte court, le nom complet du tailnet et l’IP Tailscale brute. Si seuls les noms échouent, vérifiez si MagicDNS est activé, si la machine a été renommée et si un autre produit DNS ne remplace pas la configuration du résolveur.

Séparez la connectivité Tailscale de la connectivité applicative

Une connexion réussie de nœud à nœud ne prouve pas que chaque service sur le serveur est accessible. Vous pouvez être capable de pinguer l’IP Tailscale alors que SSH, Jellyfin, un tableau de bord, SMB ou une interface web Docker expirent encore.

Cela signifie généralement que le chemin Tailscale existe mais que la couche application refuse ou manque la connexion. Le service peut être arrêté, écouter sur un autre port, lié à la mauvaise interface, bloqué par le pare-feu du serveur ou non publié depuis son conteneur.

Testez la destination exacte dont vous avez besoin, comme 100.x.x.x:22 pour SSH ou http://100.x.x.x:8080 pour un service web. Si le nœud répond mais que le port ne répond pas, arrêtez de dépanner MagicDNS et DERP jusqu'à ce que le service côté serveur soit vérifié.

Vérifiez si le service écoute sur la bonne interface

Une application peut fonctionner normalement sur le serveur domestique et rester inaccessible depuis tous les autres appareils. Cela se produit lorsque le service écoute uniquement sur 127.0.0.1, qui accepte les connexions du serveur lui-même mais pas via ses interfaces LAN ou Tailscale.

Un service à l’écoute sur 0.0.0.0 accepter le trafic IPv4 sur toutes les interfaces disponibles, alors qu’un service peut aussi être lié explicitement à l’adresse LAN ou Tailscale du serveur. Le choix correct dépend de si le service doit être accessible depuis le LAN, le tailnet, ou uniquement via un proxy inverse local.

Ne changez pas automatiquement chaque service pour 0.0.0.0. Confirmez d’abord le chemin d’accès prévu, puis utilisez des règles de pare-feu et une authentification applicative pour limiter qui peut atteindre le port.

Le pare-feu du serveur peut bloquer le trafic Tailscale

Un service peut fonctionner via l’IP LAN du serveur domestique mais échouer via son IP Tailscale parce que le système d’exploitation considère l’interface Tailscale comme un chemin réseau distinct. Les règles LAN ne s’appliquent pas toujours au trafic arrivant par tailscale0.

Les systèmes Linux peuvent utiliser UFW, firewalld, iptables ou nftables. Windows peut classer l’adaptateur Tailscale différemment du LAN domestique. Des pare-feux réseau plus larges peuvent aussi empêcher les connexions UDP directes et forcer le trafic à passer par des relais. La vérification pertinente est de savoir si votre pare-feu autorise le chemin de connexion Tailscale prévu.

Ne désactivez pas le pare-feu entier comme solution permanente. Autorisez uniquement le port de service requis depuis l’interface Tailscale, les adresses Tailscale sélectionnées ou une politique tailnet appropriée. Puis testez à nouveau l’application directement.

Vérifiez les politiques d’accès, les autorisations, les tags et l’identité des appareils

Si un appareil Tailscale peut atteindre le serveur domestique alors qu’un autre ne le peut pas, la différence peut être une politique intentionnelle plutôt qu’une panne réseau. L’accès peut dépendre de l’utilisateur, de l’appareil source, du tag de destination, du protocole et du port.

Un serveur tagué pour l’accès à l’infrastructure peut ne pas accepter le trafic d’un appareil personnel sauf si la politique autorise cette combinaison. Une règle qui permet SSH n’autorise pas nécessairement le tableau de bord web sur un autre port, et un appareil partagé peut avoir des permissions différentes d’un appareil appartenant au même utilisateur.

Examinez ensemble l’identité source, l’identité de destination, les tags du serveur et le port demandé. Une règle temporaire large peut aider à isoler un problème de politique, mais remplacez-la par la règle la plus précise correcte après les tests.

Un serveur domestique direct n’a pas besoin d’un routeur de sous-réseau

Si Tailscale est installé directement sur le serveur domestique, utilisez l’adresse IP Tailscale propre au serveur ou le nom MagicDNS. Un routeur de sous-réseau n’est pas nécessaire pour atteindre cette machine.

Les routeurs de sous-réseau résolvent un problème différent : ils fournissent un accès aux appareils qui n’exécutent pas eux-mêmes Tailscale, comme une imprimante, une caméra, un NAS plus ancien, un appareil domotique ou une autre machine sur le LAN domestique.

Ajouter le routage de sous-réseau à un problème simple de nœud direct crée plus d’endroits où la connexion peut échouer. Prouvez d’abord que le client Tailscale sur le serveur domestique est accessible. Ne dépannez les routes LAN annoncées que lorsque la cible réelle se trouve derrière ce serveur.

Le routage de sous-réseau nécessite une chaîne de routage complète

Lorsque la cible est un appareil LAN sans Tailscale, le routeur de sous-réseau doit faire plus que simplement apparaître en ligne. Il doit recevoir le trafic du tailnet, le transférer dans le LAN domestique et permettre la réponse pour qu’elle revienne.

Une configuration fonctionnelle nécessite normalement le transfert IP sur le dispositif de routage, l’annonce des routes de sous-réseau, l’approbation des routes, des contrôles d’accès correspondants et l’acceptation des routes côté client lorsque cela est requis. Le but est de annoncer un sous-réseau privé via une passerelle afin que les appareils du tailnet puissent atteindre des machines qui n’exécutent pas le client.

Si la route est visible mais que le trafic échoue, vérifiez chaque étape séparément. Confirmez que le sous-réseau correct a été annoncé, vérifiez qu’il a été approuvé, inspectez le pare-feu de transfert et assurez-vous que le dispositif LAN dispose d’un chemin de retour valide.

Les sous-réseaux privés qui se chevauchent peuvent envoyer le trafic dans la mauvaise direction

De nombreux réseaux domestiques, de bureau et d’hôtel réutilisent des adresses telles que 192.168.1.0/24. Si votre Wi-Fi actuel et votre sous-réseau domestique utilisent la même plage, le système d’exploitation peut considérer la destination comme locale au lieu de l’envoyer via Tailscale.

Cela crée un symptôme déroutant : l’IP Tailscale directe du serveur fonctionne, mais son IP LAN domestique ne fonctionne pas. La requête peut être envoyée au réseau actuel plutôt qu’au routeur du sous-réseau distant.

Utilisez l’IP Tailscale de la cible autant que possible. Si l’accès au sous-réseau est nécessaire, envisagez de changer un LAN pour une plage privée moins courante ou d’appliquer une conception de routage qui gère délibérément les réseaux qui se chevauchent.

Un nœud de sortie peut modifier l’accès au LAN actuel

Si l’appareil client utilise un nœud de sortie Tailscale, sa sélection de route diffère d’une connexion tailnet normale. L’accès aux appareils LAN proches peut être bloqué à moins que l’accès au réseau local soit explicitement autorisé.

Cela est important lors du dépannage depuis un ordinateur portable connecté au Wi-Fi d’un hôtel, d’un bureau ou d’un domicile tout en utilisant également un nœud de sortie. L’échec d’accès à une adresse LAN privée peut venir du comportement du nœud de sortie plutôt que du serveur domestique.

Testez sans le nœud de sortie, ou activez l’accès LAN uniquement lorsque vous faites confiance au réseau local. N’activez pas automatiquement un accès local large sur un Wi-Fi public inconnu.

Docker ajoute une autre limite de port et d’interface

Un service hôte comme SSH peut fonctionner via Tailscale alors qu’une application Docker sur le même serveur échoue. Cela indique généralement un problème de réseau de conteneur plutôt que de connectivité du nœud.

Vérifiez si le conteneur fonctionne, si l’application écoute à l’intérieur du conteneur, et si son port est publié sur l’hôte. Un mappage Compose tel que 8080:80 expose le port 80 du conteneur via le port 8080 de l’hôte, tandis qu’un port lié uniquement à 127.0.0.1 peut rester inaccessible via l’IP Tailscale.

Vérifiez également les routes de reverse-proxy, le réseau hôte, les règles de pare-feu Docker, et si l’application elle-même autorise les connexions depuis des adresses hors LAN. Testez directement le port hôte avant de déboguer les domaines ou certificats de niveau supérieur.

DERP explique généralement plus la lenteur que l’échec complet

Tailscale tente de créer des connexions directes entre les appareils. Lorsque le comportement NAT ou les restrictions du pare-feu l’en empêchent, il peut utiliser un chemin relais à la place.

DERP fournit un relais chiffré de secours lorsque la connectivité directe échoue. Le relais transmet un trafic déjà chiffré et peut connecter des appareils à travers des combinaisons complexes d’IPv4, IPv6, NAT et pare-feu.

Un chemin DERP fonctionne souvent avec plus de latence ou un débit plus faible, il est donc un suspect sérieux lorsque SSH semble lent ou que les transferts de fichiers sont lents. Si la connexion ne fonctionne pas du tout, vérifiez d'abord l'état du nœud, la politique d'accès, le pare-feu local, le port de l'application et l'adresse de liaison.

Utilisez le diagnostic de connexion avant de modifier le routeur

Commandes telles que ping tailscale aide à séparer un chemin de nœud d'un chemin d'application. Un résultat réussi prouve plus qu'un onglet de navigateur échoué car il teste la connectivité sans dépendre du port, du proxy ou du certificat de l’application.

tailscale netcheck peut aider à montrer la disponibilité UDP, le comportement NAT, la connectivité IPv4 ou IPv6, et les régions de relais proches. Ces résultats sont les plus utiles lorsque la connexion ne fonctionne que via un relais ou change entre réseaux.

Ne commencez pas par ajouter un transfert de port public au routeur domestique. Tailscale est conçu pour fonctionner sans exposer directement les ports d'application du serveur domestique à Internet. Les modifications du routeur doivent répondre à un problème de chemin confirmé, pas remplacer les étapes de diagnostic précédentes.

Redémarrez et mettez à jour uniquement après avoir identifié la couche défaillante

Redémarrer Tailscale peut restaurer un démon défaillant ou un état client obsolète, mais des redémarrages répétés ne constituent pas un diagnostic. Si la même défaillance revient après chaque redémarrage, le problème sous-jacent est probablement la configuration de démarrage, la politique de pare-feu, le routage ou la liaison de l'application.

Confirmez que le serveur domestique démarre Tailscale sans connexion interactive au bureau et reste connecté après le redémarrage. Comparez également les versions des clients si un appareil se comporte différemment du reste du tailnet.

Après une mise à jour ou un redémarrage, répétez les mêmes tests dans le même ordre : statut du nœud, IP brute, nom d'hôte, ping Tailscale et port de l'application. Une séquence de test cohérente montre quelle couche a réellement changé.

Suivez un ordre unique de dépannage

Le chemin le plus rapide est de passer du nœud Tailscale vers l'application. Ne modifiez pas simultanément le DNS, les routes de sous-réseau, les règles de pare-feu et le réseau Docker.

Confirmez d'abord que les deux nœuds sont en ligne. Testez ensuite l'IP brute Tailscale, puis le nom MagicDNS. Testez le chemin du nœud, puis le port de l'application. Ce n'est qu'après ces vérifications que vous devez examiner le pare-feu du serveur, l'adresse de liaison, la politique d'accès, le mappage Docker ou le routage de sous-réseau.

Cet ordre empêche qu'un simple service arrêté ne devienne un projet de routage compliqué. Chaque test doit répondre à une question avant de passer à la couche suivante.

Conclusion finale

Lorsque Tailscale ne peut pas atteindre votre serveur domestique, commencez par la distinction la plus simple : les deux nœuds Tailscale peuvent-ils communiquer, et l'application peut-elle accepter le trafic ? Confirmez que les deux nœuds sont en ligne, testez l'IP brute Tailscale, puis testez le nom MagicDNS et le port exact du service.

Si le chemin du nœud fonctionne mais pas l'application, concentrez-vous sur le pare-feu du serveur, l'interface d'écoute, les paramètres de l'application, le mappage des ports Docker et la politique d'accès. Si la cible n'exécute pas Tailscale, passez à la configuration du routeur de sous-réseau, à l'approbation des routes, au transfert IP et à la vérification des sous-réseaux qui se chevauchent.

Les chemins de relais DERP expliquent généralement une performance plus lente plutôt qu'une panne complète. Un test cohérent couche par couche est plus efficace que de réinstaller Tailscale, désactiver le pare-feu ou ajouter une redirection de port public sans savoir où la connexion s'arrête.

FAQ

Pourquoi puis-je pinguer mon serveur Tailscale mais pas ouvrir son interface web ?

La connexion nœud-à-nœud fonctionne, mais le service web peut être arrêté, écouter sur un autre port, lié uniquement à localhost, bloqué par le pare-feu du serveur, ou non publié depuis son conteneur Docker.

Pourquoi l'IP Tailscale fonctionne-t-elle mais pas le nom du serveur ?

Cela indique un problème de MagicDNS ou une autre configuration DNS. Vérifiez si MagicDNS est activé, si le nom de la machine a changé, et si un autre résolveur DNS remplace les paramètres de Tailscale.

Ai-je besoin d'un routeur de sous-réseau pour accéder à mon serveur domestique ?

Non, pas lorsque Tailscale est installé directement sur ce serveur. Utilisez son IP Tailscale ou son nom MagicDNS. Un routeur de sous-réseau est nécessaire pour atteindre d'autres appareils LAN qui n'exécutent pas Tailscale.

Un pare-feu peut-il bloquer Tailscale même lorsque le nœud est en ligne ?

Oui. Le client Tailscale peut se connecter au tailnet alors que le pare-feu du système d'exploitation bloque toujours SSH, le web, SMB ou un autre port d'application arrivant via l'interface Tailscale.

Une connexion DERP signifie-t-elle que Tailscale est cassé ?

Non. DERP est une solution de secours chiffrée lorsqu'une connexion directe ne peut être établie. Elle peut ajouter de la latence ou réduire le débit, mais elle assure toujours la connectivité entre les appareils.

Pourquoi puis-je atteindre le serveur mais pas un autre appareil sur mon LAN domestique ?

Le serveur est un nœud Tailscale direct, tandis que l'autre appareil nécessite un routeur de sous-réseau. Vérifiez le transfert IP, les routes annoncées, l'approbation des routes, les règles d'accès et le chemin de retour de l'appareil LAN.

Des sous-réseaux domestiques et distants qui se chevauchent peuvent-ils empêcher l'accès à Tailscale ?

Oui. Si les deux emplacements utilisent le même sous-réseau privé, le client peut envoyer le trafic vers son LAN actuel au lieu de la route du sous-réseau distant. Préférez l'IP Tailscale de la cible ou changez la plage d'adresses d'un des réseaux.

Dois-je ouvrir des ports sur mon routeur pour réparer Tailscale ?

Habituellement non. Confirmez d'abord l'état du nœud, le comportement du pare-feu, la liaison de l'application, la politique d'accès, et si la connexion est directe ou relayée. Le fait de rediriger publiquement le port de l'application ne remplace pas la recherche de la véritable cause de l'échec Tailscale.