Tailscale : VPN sans douleur et les erreurs d’accès qui font encore mal

Ce qu’est réellement Tailscale (et ce que ce n’est pas)

Tailscale est un réseau superposé basé sur WireGuard qui relie la connectivité à l’identité.
Vous obtenez une plage d’adresses privées (typiquement 100.64.0.0/10), les nœuds s’authentifient via un fournisseur d’identité,
et le plan de contrôle coordonne les clés et les routes pour que les appareils puissent communiquer directement quand c’est possible.

Le modèle mental crucial : Tailscale n’est pas « un serveur VPN ». C’est un maillage distribué avec une couche de coordination.
La plupart du trafic est pair-à-pair. S’il ne peut pas l’être (NAT, pare-feu, NAT symétrique, etc.), le trafic transite par DERP.
DERP n’est pas une « porte dérobée » ; c’est un relais pragmatique pour que votre portable puisse atteindre une machine dans un datacenter poussiéreux.

Ce que Tailscale n’est pas : un substitut à une hygiène réseau basique. Vous avez toujours besoin de pare-feux sur les hôtes,
d’un routage correct, d’un DNS sensé et d’un plan pour l’accès privilégié. Tailscale facilite ces tâches.
Il ne les fait pas pour vous.

Et oui, vous pouvez toujours vous verrouiller dehors. Tailscale vous aide juste à le faire plus rapidement et depuis plus d’endroits.

Faits et historique à connaître

• WireGuard est jeune selon les standards VPN. Il a été intégré au noyau Linux en 2020, ce qui compte quand on le compare aux piles IPsec vieilles de plusieurs décennies.
• L’espace d’adresses par défaut de Tailscale (100.64.0.0/10) vit dans la plage CGNAT, réduisant les collisions avec les réseaux RFC1918 internes — en général.
• DERP est un relais, pas un concentrateur de tunnels. Il existe pour gérer les cas où le contournement NAT échoue et bloquerait autrement la connectivité.
• « Zero trust » est devenu une ligne budgétaire après que les modèles basés sur le périmètre aient échoué dans les environnements cloud hybrides et de travail à distance.
• Les VPN traditionnels ont normalisé les secrets partagés et les configs statiques (profils clients, PSK, certificats longue durée). Tailscale pousse vers une authentification liée à l’identité et de courte durée.
• Le split tunneling combat les anciennes habitudes. Beaucoup de VPNs d’entreprise forçaient « tout le trafic via le siège » ; Tailscale le rend optionnel via les nœuds de sortie, volontairement.
• Les ACL sont désormais policy-as-code. C’est excellent — jusqu’à ce que quelqu’un traite le fichier ACL comme une incantation magique plutôt que comme une frontière de sécurité.
• Le routage de sous-réseau préexistait à Tailscale depuis des décennies, mais le routage de sous-réseau en superposition incite à « simplement router tout le datacenter », ce qui déclenche les audits.
• Les fournisseurs d’identité sont devenus le nouveau périmètre, c’est pourquoi une panne IdP peut ressembler à une panne réseau habillée en costume.

Une configuration « VPN sans douleur » sensée

Si vous voulez que Tailscale reste ennuyeux, décidez ce que « ennuyeux » signifie avant de cliquer sur n’importe quel bouton.
Ma définition : les ingénieurs peuvent atteindre ce dont ils ont besoin, l’accès est par défaut au moindre privilège,
et le mode de défaillance est « ne peut pas se connecter » plutôt que « connecté à tout ».

Commencez par une topologie minimale

Ne commencez pas avec des routes de sous-réseau, des nœuds de sortie et des exceptions astucieuses basées sur des tags dès la première semaine.
Commencez par la connectivité appareil-à-appareil entre un petit ensemble de postes administrateurs et quelques hôtes cibles.
Confirmez les performances, le flux d’identité, les journaux. Puis montez en charge.

Choisissez votre modèle d’identité et engagez-vous

Si vous utilisez un IdP (Google Workspace, Microsoft Entra ID, Okta, etc.), imposez la MFA et la confiance des appareils quand c’est possible.
L’IdP est maintenant votre « login VPN ». Traitez-le comme critique pour la production.
Si votre organisation est allergique au SSO, utilisez les clés d’authentification Tailscale — mais comprenez leur cycle de vie, leur rotation et leur portée.

Décidez comment les nœuds sont autorisés

Pour les environnements de production, préférez un modèle où :

• Les utilisateurs ne peuvent pas simplement ajouter des appareils au hasard sans approbation (ou au moins sans visibilité).
• Les serveurs sont enregistrés avec des clés d’authentification ciblées et réutilisables (ou des clés éphémères à usage unique) plus des tags.
• La désactivation d’un utilisateur ou d’un appareil est une action unique qui fonctionne réellement.

Rendez explicite le plan réseau

Les réseaux superposés invitent aux décisions « juste cette fois » qui deviennent permanentes.
Écrivez :

• Quels services doivent être accessibles (SSH, RDP, Postgres, web interne, etc.).
• Depuis quels rôles (astreinte, CI, DBA, support).
• Si vous utiliserez des routes de sous-réseau, ou si vous exigerez l’installation de Tailscale sur les hôtes réels.
• Si vous autoriserez les nœuds de sortie, et pour qui.

Blague n°1 : Un VPN, c’est comme une cuisine de bureau partagée — si vous ne marquez pas les choses, quelqu’un boira le lait, et ce sera votre panne.

Identité, ACL, tags : où l’accès réussit ou échoue

Le grand atout de Tailscale est aussi son plus grand piège : le contrôle d’accès devient tellement simple que les gens arrêtent d’y penser.
Dans le monde VPN classique, vous aviez une frontière réseau et une pile de règles de pare-feu. Dans le monde Tailscale, ce sont les ACL qui font office de pare-feu.
Si vous les traitez comme « ce fichier de config qu’on copie-colle », vous introduirez des bugs de sécurité.

Utilisez des groupes pour les humains, des tags pour les machines

Une règle pratique : les humains appartiennent à des groupes, les serveurs reçoivent des tags.
Les humains changent de poste, partent en congé, apportent des appareils personnels. Les serveurs ne doivent pas hériter de l’identité humaine.
Les tags expriment les rôles machines (« tag:db », « tag:bastion », « tag:monitoring »).

Écrivez ensuite les ACL comme si vous alliez en être interrogé en justice.
Moindre privilège. Ports explicites. Pas de politiques larges « tout autoriser » pour « que ça marche ».
Faire fonctionner les choses est facile ; les rendre sûres est le travail.

Évitez les règles larges « temporaires »

La règle ACL la plus dangereuse est celle ajoutée pendant un incident.
La deuxième plus dangereuse est celle que personne ne se rappelle avoir ajoutée pendant un incident.
Mettez-vous une contrainte de temps : si vous ajoutez une exception d’urgence, planifiez sa suppression tant que vous vous souvenez encore pourquoi elle existe.

Pensez en termes de rayon d’impact

Si un portable est compromis, à quoi peut-il accéder ?
Si une clé d’authentification fuit, que peut-elle enregistrer ?
Si l’IdP est mal configuré, qu’obtient un attaquant ?
Répondez à ces questions avant que votre auditeur ne vous les pose dans une salle calme sous éclairage fluorescent.

Routes de sous-réseau et nœuds de sortie : puissant, facile à abuser

Le routage de sous-réseau permet aux clients Tailscale d’atteindre des réseaux qui n’exécutent pas le client Tailscale.
Les nœuds de sortie permettent de router le trafic internet par défaut d’un client via un nœud Tailscale.
Ces deux fonctionnalités sont utiles opérationnellement. Elles peuvent toutes deux devenir silencieusement le « nouveau VPN d’entreprise », avec tous les anciens problèmes.

Routeurs de sous-réseau : quand et comment

Utilisez des routeurs de sous-réseau pour :

• Des réseaux legacy que vous ne pouvez pas modifier (appliances, anciens hyperviseurs, matériel de laboratoire).
• Migrations à court terme où installer Tailscale partout est irréaliste.
• Une connectivité site-à-site où vous voulez un accès basé sur l’identité, pas une confiance par site entière.

Évitez les routeurs de sous-réseau par défaut si vous pouvez installer Tailscale sur les hôtes. Les clients au niveau hôte vous donnent une meilleure attribution,
une meilleure segmentation et moins de surprises du type « pourquoi tout le trafic fait demi-tour via cette VM ».

Nœuds de sortie : traitez-les comme de l’infra privilégiée

Les nœuds de sortie ne sont pas seulement des fonctions de routage ; ce sont des points d’application de politique et des concentrateurs de trafic.
Si vous les autorisez, appliquez :

• Nœuds de sortie dédiés et durcis (pas « le desktop de quelqu’un »).
• ACL restreintes : seuls des groupes spécifiques peuvent les utiliser.
• Surveillance : bande passante, CPU, pertes de paquets, et si les clients utilisent DERP de façon inattendue.

Les nœuds de sortie compliquent aussi la réponse aux incidents. Si votre IP de sortie est soudainement « incorrecte », cela peut venir du fait qu’un client a sélectionné un nœud de sortie
(intentionnellement ou par erreur). Ce n’est pas un mystère réseau ; c’est une case à cocher.

DNS et MagicDNS : la résolution de noms comme fonction de fiabilité

La plupart des rapports « le VPN est en panne » sont en réalité des pannes DNS déguisées en réseau.
MagicDNS de Tailscale peut nettoyer cela en donnant des noms stables aux nœuds et en gérant le DNS partagé pour les domaines internes.
Il peut aussi créer de nouveaux modes d’échec si vous le configurez à moitié.

Décidez ce que signifie « DNS interne »

Si vous exécutez déjà un DNS interne (Bind, Unbound, Infoblox, zones privées Route 53, etc.), décidez si :

• Les noms Tailscale suffisent (node-name.tailnet), ou
• Vous avez besoin que les domaines internes soient résolus via Tailscale (DNS partagé), ou
• Vous avez besoin des deux, avec des règles de priorité claires.

Puis testez sur macOS, Windows, Linux et mobile. Les piles DNS ne sont pas cohérentes ; c’est un zoo avec de la paperasse.

Tailscale SSH : supprimer les clés, pas la responsabilité

Tailscale SSH peut remplacer la distribution traditionnelle des clés SSH en liant l’accès SSH à l’identité Tailscale et à la politique.
C’est attractif : moins de clés longue durée, moins de « qui possède cette ligne dans authorized_keys », et de meilleures traces d’audit.
C’est aussi un changement dans vos habitudes opérationnelles.

Une bonne approche :

• Activez Tailscale SSH sur un petit ensemble d’hôtes d’abord.
• Conservez un accès break-glass (console, série cloud, hors bande) car vous configurerez quelque chose de travers tôt ou tard.
• Décidez si vous autorisez toujours openssh sur des réseaux non-Tailscale. En général, non.

Une citation de fiabilité qui reste vraie : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan.
Ce n’est pas exclusivement une citation ops, mais c’est douloureusement exact quand votre chemin d’accès est un unique plan de contrôle fragile.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les commandes que vous lancez quand quelqu’un dit « Tailscale est en panne », plus ce que la sortie signifie et la décision à prendre ensuite.
Elles sont volontairement banales. Le banal sauve la production.

Tâche 1 : Vérifier que le nœud est réellement connecté

cr0x@server:~$ tailscale status
100.64.10.12   web-01           linux   active; direct 198.51.100.24:41641, tx 123456 rx 234567
100.64.10.20   db-01            linux   active; relay "iad", tx 45678 rx 56789
100.64.10.99   cr0x-laptop      macOS   active; direct 203.0.113.77:54012, tx 98765 rx 87654

Sens : Si vous ne voyez pas votre pair, vous n’êtes pas dans le même tailnet ou le pair est hors ligne. « direct » vs « relay » vous indique le chemin.

Décision : Si les pairs manquent, vérifiez la connexion/l’autorisation. Si c’est relayé de façon inattendue, commencez par regarder le NAT/pare-feu.

Tâche 2 : Vérifier l’état du démon local et l’état de connexion

cr0x@server:~$ tailscale status --json | jq '.BackendState, .Self.DNSName, .Self.Online'
"Running"
"web-01.tailnet-abc.ts.net."
true

Sens : BackendState « Running » est bon. DNSName confirme dans quel tailnet vous êtes.

Décision : Si ce n’est pas running, redémarrez le service. Si DNSName est incorrect, vous êtes connecté à la mauvaise organisation.

Tâche 3 : Confirmer quelles routes et paramètres DNS sont appliqués

cr0x@server:~$ tailscale netcheck
Report:
        * UDP: true
        * IPv4: yes, 198.51.100.24:41641
        * IPv6: no
        * MappingVariesByDestIP: false
        * HairPinning: true
        * Nearest DERP: iad
        * DERP latency:
                - iad: 18.2ms   (nearest)
                - ord: 35.4ms
                - lax: 72.9ms

Sens : UDP true est-clé pour WireGuard direct. Le DERP le plus proche est là où vous relayerez si nécessaire.

Décision : Si UDP est false, corrigez le pare-feu/NAT. Si la latence DERP est énorme, prévoyez des sessions interactives lentes.

Tâche 4 : Voir les préférences actives (nœud de sortie, SSH, routes)

cr0x@server:~$ tailscale prefs
{
  "ControlURL": "https://controlplane.tailscale.com",
  "RouteAll": false,
  "ExitNodeID": "",
  "CorpDNS": true,
  "RunSSH": false
}

Sens : RouteAll false signifie pas de nœud de sortie. CorpDNS true signifie qu’il utilise la configuration DNS du tailnet.

Décision : Si quelqu’un se plaint « internet est lent », vérifiez RouteAll/ExitNodeID d’abord. C’est souvent auto-infligé.

Tâche 5 : Confirmer que vous pouvez atteindre un pair via l’IP du tailnet

cr0x@server:~$ ping -c 2 100.64.10.20
PING 100.64.10.20 (100.64.10.20) 56(84) bytes of data.
64 bytes from 100.64.10.20: icmp_seq=1 ttl=64 time=22.4 ms
64 bytes from 100.64.10.20: icmp_seq=2 ttl=64 time=22.1 ms

--- 100.64.10.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 22.141/22.262/22.384/0.121 ms

Sens : La connectivité de base fonctionne.

Décision : Si le ping échoue mais que status affiche « active », suspectez les ACL ou un pare-feu hôte bloquant ICMP (ou le ping désactivé).

Tâche 6 : Tester le port du service réel (parce que le ping ment)

cr0x@server:~$ nc -vz 100.64.10.20 5432
Connection to 100.64.10.20 5432 port [tcp/postgresql] succeeded!

Sens : Le chemin TCP vers Postgres est ouvert.

Décision : Si cela échoue mais que le ping fonctionne, c’est l’ACL ou le pare-feu hôte ou le service n’écoute pas sur l’interface tailnet.

Tâche 7 : Vérifier que le service écoute sur les bonnes interfaces

cr0x@server:~$ sudo ss -lntp | grep 5432
LISTEN 0      244          127.0.0.1:5432       0.0.0.0:*    users:(("postgres",pid=1342,fd=6))

Sens : Postgres est lié à localhost uniquement. Tailscale ne peut pas l’atteindre à distance.

Décision : Lieez-vous à l’IP Tailscale ou à 0.0.0.0 (avec des contraintes pare-feu/ACL), puis retestez.

Tâche 8 : Inspecter la table de routage Linux pour des surprises de route de sous-réseau

cr0x@server:~$ ip route show
default via 192.0.2.1 dev eth0
100.64.0.0/10 dev tailscale0 scope link
10.20.0.0/16 dev tailscale0 scope link

Sens : 10.20.0.0/16 est routé via tailscale0 — probablement une route de sous-réseau que vous avez acceptée.

Décision : Si cette route est inattendue, identifiez le routeur qui l’annonce et décidez de désactiver l’acceptation de routes.

Tâche 9 : Confirmer quelles routes de sous-réseau sont annoncées depuis un nœud routeur

cr0x@server:~$ tailscale status --json | jq '.Self.PrimaryRoutes, .Self.AdvertisedRoutes'
null
[
  "10.20.0.0/16"
]

Sens : Ce nœud annonce 10.20.0.0/16 au tailnet.

Décision : Si vous ne l’aviez pas prévu, supprimez le paramètre advertise-routes et faites pivoter toute automatisation qui le réapplique.

Tâche 10 : Vérifier si votre client utilise DERP (relais) de façon inattendue

cr0x@server:~$ tailscale ping 100.64.10.99
pong from cr0x-laptop (100.64.10.99) via DERP(iad) in 36ms

Sens : Vous relayez via DERP, pas en direct.

Décision : Si les performances comptent, enquêtez sur la portée UDP et le comportement NAT des deux côtés.

Tâche 11 : Vérifier les compteurs du pare-feu hôte (exemple Linux nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "tailscale0" tcp dport { 22, 5432 } accept
    counter packets 0 bytes 0 drop
  }
}

Sens : tailscale0 est autorisé pour les ports 22 et 5432 ; la politique drop sinon.

Décision : Si les compteurs montrent des drops qui augmentent pendant votre test, corrigez les règles de pare-feu avant de blâmer Tailscale.

Tâche 12 : Valider la résolution DNS pour les noms MagicDNS

cr0x@server:~$ dig +short web-01.tailnet-abc.ts.net
100.64.10.12

Sens : Le nom se résout en l’IP du tailnet.

Décision : Si ce n’est pas résolu, vérifiez l’activation de MagicDNS et les paramètres DNS du client ; ne perdez pas de temps sur le routage d’abord.

Tâche 13 : Inspecter les journaux systemd du service pour erreurs d’auth et réseau

cr0x@server:~$ sudo journalctl -u tailscaled -n 50 --no-pager
Dec 27 11:02:14 web-01 tailscaled[812]: wgengine: Reconfig: configuring userspace WireGuard config (with 2 peers)
Dec 27 11:02:18 web-01 tailscaled[812]: magicsock: derp-https: connected to derp-iad
Dec 27 11:02:24 web-01 tailscaled[812]: health: state=running

Sens : Vous voyez un démarrage normal, la connexion DERP et un état healthy.

Décision : Si les journaux montrent des échecs d’auth répétés, une expiration de clé, ou « not authorized », arrêtez-vous et corrigez l’identité/l’approbation.

Tâche 14 : Confirmer la cohérence des versions client (pour éviter des bugs d’angle étranges)

cr0x@server:~$ tailscale version
1.76.6
  tailscale commit: 3f2c1a7e4
  go version: go1.22.6

Sens : Vous savez ce que vous exécutez.

Décision : Si un segment est sur une version ancienne, mettez à jour avant un débogage approfondi. Des versions mixtes créent des fantômes qui font perdre du temps.

Mode opératoire de diagnostic rapide

Quand la connectivité casse, vous voulez localiser rapidement la couche goulot d’étranglement : identité, politique, routage, transport, ou le service lui-même.
Voici l’ordre qui tend à minimiser le temps perdu.

Premier : confirmer identité + appartenance

• Est-ce que tailscale status montre le pair du tout ?
• Le nœud est-il connecté au bon tailnet (suffixe DNSName) ?
• L’appareil est-il approuvé/autorisée dans la console admin (si l’approbation est activée) ?

Si cette couche est incorrecte, rien d’autre ne compte. Le routage peut être parfait ; vous n’êtes toujours pas invité à la fête.

Second : confirmer la politique (ACL, tags, politique SSH)

• Pouvez-vous pinguer l’IP du tailnet ?
• Pouvez-vous vous connecter au port réel avec nc -vz ?
• Si vous utilisez Tailscale SSH, est-il activé et autorisé pour cette identité ?

La plupart des pannes en production sont des inadéquations de politique : un tag ne s’est pas appliqué, une règle a été trop large (puis resserrée), ou un groupe a changé.

Troisième : confirmer le transport (direct vs DERP, portée UDP)

• Exécutez tailscale netcheck et regardez UDP.
• Exécutez tailscale ping et voyez si c’est direct ou DERP.

Si c’est DERP et lent, vous n’êtes pas « down », vous payez juste la taxe NAT.
Corriger le NAT/pare-feu peut transformer un shell distant lent en un shell normal.

Quatrième : confirmer le routage (routes de sous-réseau, nœuds de sortie)

• Vérifiez ip route pour des routes inattendues via tailscale0.
• Vérifiez si un nœud de sortie est activé (tailscale prefs).

Les problèmes de routage ressemblent souvent à « un service interne aléatoire est cassé ». Ce n’est pas aléatoire ; c’est déterministe et non documenté.

Cinquième : confirmer le service et le pare-feu hôte

• Le service écoute-t-il sur la bonne interface (ss -lntp) ?
• Le pare-feu autorise-t-il le trafic tailscale0 (nftables/iptables) ?

Si Tailscale est correct mais que le service est lié à 127.0.0.1, votre réseau superposé est sans objet. C’est la partie ennuyeuse. Faites-la quand même.

Erreurs courantes : symptômes → cause racine → correction

1) « Je vois le nœud, mais SSH fait timeout »

Symptômes : Le nœud apparaît dans tailscale status. Le ping peut fonctionner. SSH/RDP/port d’application timeout.

Cause racine : Le pare-feu hôte bloque tailscale0, ou le service n’écoute que localhost, ou l’ACL bloque le port.

Correction : Vérifiez nc -vz, puis ss -lntp, puis nftables/iptables. Assurez-vous que l’ACL autorise explicitement le port de destination et que le démon est lié à une interface accessible.

2) « Tout est lent aujourd’hui »

Symptômes : Les sessions interactives laguent ; les transferts de fichiers ramollissent ; retards intermittents.

Cause racine : Le trafic est relayé via DERP à cause d’UDP bloqué ou NAT symétrique ; parfois un nœud de sortie forcé ajoute de la latence.

Correction : Exécutez tailscale ping pour confirmer DERP vs direct et tailscale netcheck pour UDP. Autorisez la sortie UDP/41641 (ou au moins UDP en général) et évitez les nœuds de sortie pour les workflows sensibles à la latence sauf nécessité.

3) « Nous avons activé une route de sous-réseau et maintenant des choses bizarres arrivent »

Symptômes : Certaines IP internes sont routées différemment ; des services deviennent accessibles depuis des endroits où ils ne devraient pas ; tickets mentionnent « split tunnel cassé ».

Cause racine : Les clients ont accepté une route de sous-réseau qui chevauche des routes existantes, ou une route trop large a été annoncée (comme un /16 alors qu’un /24 suffisait).

Correction : Auditez les routes avec ip route et le tailscale status --json du routeur. Réduisez les préfixes annoncés. Désactivez l’acceptation automatique de routes si besoin, et appliquez des restrictions ACL pour les destinations du sous-réseau.

4) « Un contractuel peut encore atteindre prod après offboarding »

Symptômes : Un utilisateur est retiré du groupe IdP, mais son appareil se connecte toujours ou possède toujours un accès.

Cause racine : L’appareil reste autorisé ; les ACL sont basées sur des tags trop larges ; ou une clé d’authentification longue a enregistré un nœud non lié à l’identité du contractuel.

Correction : Imposer l’approbation/expiration des appareils, purger régulièrement les appareils, et préférer l’identité liée à l’utilisateur pour l’accès humain. Pour les clés machine, limitez leur portée et faites-les tourner. Faites de « l’offboarding inclut les appareils Tailscale » une étape non optionnelle.

5) « MagicDNS ne fonctionne pas sur mon portable, mais fonctionne sur les serveurs »

Symptômes : dig échoue pour les noms tailnet ; l’accès par IP fonctionne ; le comportement varie par OS.

Cause racine : Les paramètres DNS client sont écrasés par un autre VPN, un résolveur local, un portail captif, ou des priorités DNS spécifiques à l’OS.

Correction : Vérifiez avec dig et inspectez les paramètres DNS de l’OS. Désactivez le DNS d’un VPN conflictuel et standardisez la configuration client. Si vous comptez sur le DNS partagé, testez-le sur chaque plateforme supportée.

6) « Nous ne pouvons pas atteindre le sous-réseau du datacenter depuis Tailscale »

Symptômes : Les nœuds du tailnet peuvent se parler entre eux, mais pas aux 10.x/192.168.x derrière un routeur de sous-réseau.

Cause racine : Le routeur de sous-réseau ne fait pas de forwarding (IP forwarding désactivé), le pare-feu bloque, ou les routes ne sont pas approuvées dans l’UI admin.

Correction : Activez le forwarding IP sur le nœud routeur, autorisez le forwarding dans le pare-feu, et confirmez que les routes annoncées sont approuvées et acceptées par les clients. Testez ensuite avec traceroute et nc.

7) « Nœud de sortie activé et maintenant les connexions SaaS semblent suspectes »

Symptômes : Alertes basées sur la géo ; déconnexions répétées ; les sites affichent une région différente ; pics de bande passante sur un nœud.

Cause racine : Des utilisateurs routent involontairement tout leur trafic via un nœud de sortie, changeant l’IP d’egress et la localisation.

Correction : Restreignez l’utilisation des nœuds de sortie à des groupes spécifiques. Formez les utilisateurs à leur usage. Surveillez les nœuds de sortie. Envisagez des « régions d’egress » dédiées si la conformité l’exige.

Trois mini-récits d’entreprise venant du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une société SaaS de taille moyenne a déployé Tailscale pour remplacer un ancien IPsec. Le plan était propre : les ingénieurs se connectent depuis des portables,
atteignent un bastion, puis accèdent aux services internes. Quelqu’un a ajouté un routeur de sous-réseau pour rendre un réseau de supervision legacy accessible.

L’hypothèse erronée était subtile : ils pensaient que « annoncer une route de sous-réseau » signifiait « seule une poignée de personnes peut l’utiliser ».
En réalité, chaque client acceptait les routes par défaut, et les ACL avaient été écrites largement (« engineering peut atteindre interne »)
parce que cela correspondait à la culture du vieux VPN.

Une semaine plus tard, un ingénieur sur un appareil personnel a rejoint le tailnet, installé un outil de débogage, et a scanné accidentellement le sous-réseau de supervision.
Rien de malveillant. Mais les alertes ressemblaient à de la reconnaissance. La sécurité s’est réveillée. La direction s’est fâchée. Tout le monde s’est levé de mauvaise humeur.

La correction n’a pas été dramatique : resserrer les ACL sur des destinations et ports spécifiques, exiger l’approbation des appareils pour les nouveaux nœuds,
et rendre l’acceptation des routes de sous-réseau explicite seulement pour les rôles qui en ont besoin. La vraie leçon : le routage superposé change qui peut « voir » des réseaux.
Si vous ne le rendez pas explicite, vous le découvrirez lors d’un post-mortem.

Mini-récit 2 : L’optimisation qui a mal tourné

Une équipe IT d’entreprise a décidé de standardiser l’accès distant en poussant tout le trafic internet via des nœuds de sortie « pour la surveillance de sécurité ».
Ils ont déployé une paire de nœuds de sortie par région et ont obligé les utilisateurs à les activer. Sur le papier, cela donnait une visibilité centrale et un egress cohérent.

Le revers est venu en trois actes. D’abord, les coûts de bande passante ont grimpé et les nœuds de sortie sont devenus des points chauds. Ensuite, le travail interactif est devenu plus lent pour
les ingénieurs qui faisaient maintenant un aller-retour via un nœud de sortie pour atteindre des services cloud dans une autre région. Enfin, une mise à jour normale du noyau
plus un bug de pilote NIC ont causé des pertes de paquets sur un nœud de sortie, ce qui a déclenché un événement « internet est en panne » pour toute l’entreprise.

L’incident a été brutal parce qu’il ressemblait à tout : DNS, pannes SaaS, « problèmes Wi‑Fi », vous l’appelez.
Le problème de fond était simplement qu’ils avaient réintroduit un goulet central — exactement ce que Tailscale aide normalement à éviter.

Ils ont récupéré en rendant l’usage des nœuds de sortie optionnel, restreint à des scénarios spécifiques (Wi‑Fi public, ressources géo-restreintes, tests de conformité).
Ils ont aussi ajouté de la surveillance et de la marge de capacité pour les nœuds de sortie conservés. L’« optimisation » était en réalité un changement de topologie, et les changements de topologie ont des conséquences.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une fintech utilisait Tailscale sur cloud et on‑prem. Ils avaient pour habitude stricte : chaque changement d’accès production nécessitait une petite demande de changement,
et chaque modification d’ACL nécessitait une relecture par un pair, même si c’était « juste ouvrir le port 443 à un nouveau service ».

Pendant un incident, un ingénieur d’astreinte avait besoin d’un accès urgent à un nœud de stockage pour collecter des logs. Le chemin le plus rapide aurait été
d’ajouter une exception ACL large pour le groupe d’astreinte afin d’atteindre tout le sous-réseau stockage. Cela aurait marché en quelques minutes.

Mais l’équipe a suivi la pratique ennuyeuse : une règle ACL étroite ciblée sur un tag d’hôte unique et un port unique, plus une vérification de posture d’appareil à courte durée.
Ils ont aussi documenté la modification dans les notes d’incident et planifié sa suppression. L’accès a fonctionné, l’incident a avancé, et rien de « supplémentaire » n’est resté ouvert.

Quelques semaines plus tard, un portable de contractuel compromis a été exploité sur le tailnet. La portée de l’attaquant était limitée.
La flotte de stockage n’était pas en portée, parce que les ACL étaient précises et revues. L’équipe n’a pas fait la fête.
Ils ont juste continué. C’est à quoi ressemble la « bonne » opération : c’est presque décevant d’ennui.

Listes de contrôle / plan étape par étape

Étape par étape : déployer Tailscale de manière orientée production

1. Définir les objectifs d’accès. Listez les services et ports qui doivent être atteignables, par rôle. Si vous ne pouvez pas le lister, vous ne pouvez pas le sécuriser.
2. Choisir l’identité et imposer la MFA. Si le SSO est disponible, utilisez-le et exigez la MFA. Sinon, traitez les clés d’authentification comme des secrets avec gestion du cycle de vie.
3. Activer la visibilité et l’approbation des appareils. Décidez si les nouveaux appareils sont auto-approuvés. Pour la production, par défaut exiger l’approbation.
4. Établir la nomenclature et les tags. Humains en groupes. Serveurs en tags. Pas d’exceptions « parce que c’est plus simple ».
5. Commencer par installer Tailscale sur les hôtes quand c’est possible. Les routes de sous-réseau sont un pont, pas un mode de vie.
6. Écrire des ACL minimales. Commencez par une règle unique « admin → bastion:22 » et étendez prudemment.
7. Activer MagicDNS volontairement. Testez sur tous les OS supportés. Documentez le fonctionnement du DNS partagé si vous l’utilisez.
8. Décider des nœuds de sortie. Si autorisés, construire des nœuds de sortie dédiés et restreindre l’utilisation. Sinon, désactiver la fonctionnalité ou la bloquer par politique.
9. Conserver un accès break-glass. Accès console, série cloud, iLO/iDRAC ou équivalent. Vous en aurez besoin un jour.
10. Instrumenter et alerter. Surveillez l’utilisation de DERP, la charge des nœuds de sortie, et les journaux tailscaled sur les nœuds critiques.
11. Former l’astreinte avec le playbook de diagnostic. Assurez-vous que les gens distinguent un échec ACL d’un échec DNS d’un problème de binding de service.
12. Faire une hygiène d’accès trimestrielle. Purger les anciens appareils, faire tourner les clés, revoir les ACL, et auditer les routes de sous-réseau.

Checklist : avant d’activer le routage de sous-réseau

• Confirmer que le sous-réseau ne chevauche pas des routes existantes utilisées par les clients.
• Confirmer que le nœud routeur a l’IP forwarding activée et des règles de forwarding pare-feu en place.
• Annoncer le plus petit préfixe qui fonctionne (éviter le /16 si un /24 suffit).
• Restreindre l’accès au sous-réseau via des ACL (ne comptez pas sur « seules quelques personnes l’utiliseront »).
• Décider quels clients acceptent les routes et le rendre explicite.

Checklist : avant d’activer les nœuds de sortie

• Utiliser des nœuds de sortie dédiés avec correctifs et surveillance.
• Verrouiller qui peut les utiliser (groupes uniquement).
• Valider les performances et le chemin MTU, spécialement pour les appels vidéo et les gros téléchargements.
• Planifier la sélection de région et la cohérence d’IP d’egress si la conformité est importante.

Blague n°2 : La façon la plus rapide d’« améliorer la sécurité » est de router tout via une seule machine — jusqu’à ce que cette machine devienne votre nouveau passe-temps.

FAQ

Est-ce que Tailscale est « juste WireGuard » ?

Sous le capot, il utilise WireGuard pour le plan de données. La différence est le plan de contrôle : identité, distribution de clés,
coordination du contournement NAT, ACL, et des fonctionnalités optionnelles comme MagicDNS et Tailscale SSH. C’est la partie qui remplace vos scripts glue DIY.

Pourquoi je vois « relay » dans tailscale status ?

Cela signifie que la connexion n’a pas pu être établie directement (généralement problèmes NAT/pare-feu/UDP), donc le trafic passe par DERP.
C’est toujours chiffré de bout en bout, mais la latence et le débit peuvent en souffrir.

Puis-je utiliser Tailscale sans l’installer sur chaque serveur ?

Oui : utilisez un routeur de sous-réseau. Mais comprenez le compromis : vous perdez l’identité par hôte et créez une dépendance de routage.
C’est bien pour des réseaux legacy et des migrations. Ce n’est pas mon premier choix pour des serveurs greenfield.

Quelle est la différence entre le routage de sous-réseau et un nœud de sortie ?

Le routage de sous-réseau annonce des préfixes internes spécifiques (comme 10.20.0.0/16) dans le tailnet.
Un nœud de sortie route la route par défaut d’un client (0.0.0.0/0) via un nœud du tailnet, affectant le trafic Internet général.

Devons-nous autoriser les appareils personnels sur le tailnet ?

Si vous le faites, traitez-le comme une vraie décision de politique. Exigez l’approbation des appareils et envisagez des contrôles de posture.
Les appareils personnels ne sont pas automatiquement malveillants, mais leur réalité de patching et de contrôle diffère des endpoints gérés.

Comment les ACL et les pare-feux hôtes interagissent-ils ?

Les ACL contrôlent ce que Tailscale permet au niveau de la superposition. Les pare-feux hôtes contrôlent ce que le système d’exploitation autorise.
Vous voulez les deux. Les ACL empêchent une connexion de s’établir ; les pare-feux hôtes bloquent le trafic inattendu même si les ACL sont trop permissives.

Tailscale SSH est-il sûr pour la production ?

Oui, si vous le traitez comme un système d’accès privilégié : politiques serrées, déploiement prudent, et accès break-glass.
Le risque principal est opérationnel — mauvaise configuration qui vous verrouille dehors — pas une faiblesse cryptographique.

Quelle est la fausse alerte « c’est en panne » la plus courante ?

Le DNS. Soit MagicDNS ne se résout pas, soit le DNS partagé n’est pas appliqué, soit un autre VPN/client a détourné les paramètres du résolveur.
Testez en vous connectant directement à l’IP du tailnet ; si cela fonctionne, c’est la résolution de nom, pas le routage.

Comment effectuer proprement l’offboarding ?

Supprimez l’utilisateur des groupes IdP, désactivez leur SSO, et vérifiez et supprimez aussi leurs appareils autorisés du tailnet.
Si vous utilisez des clés d’authentification pour des machines, faites-les tourner selon un calendrier et assurez-vous qu’elles sont limitées pour qu’elles ne puissent pas enregistrer des appareils au hasard.

Utiliser DERP signifie-t-il que Tailscale peut lire notre trafic ?

Non. DERP relaie des paquets chiffrés ; il ne termine pas le chiffrement.
Vos performances peuvent changer, mais le contenu de votre trafic n’est pas exposé par le mécanisme de relais.

Conclusion : prochaines étapes qui vieillissent bien

Tailscale mérite sa réputation de « VPN sans douleur » quand vous le traitez comme un système de production : identité explicite, politique explicite,
et routage explicite. La plupart des pannes ne sont pas mystiques. Ce sont des erreurs basiques : mauvais tailnet, mauvaise ACL, mauvaise route, confusion DNS, ou un service lié à localhost.
L’astuce consiste à déboguer dans le bon ordre et à garder le rayon d’impact réduit.

Prochaines étapes pratiques :

• Adoptez le playbook de diagnostic rapide et formez l’astreinte.
• Auditez vos ACL pour le moindre privilège et retirez les règles larges « temporaires ».
• Inventoriez les routes de sous-réseau et rendez l’acceptation explicite ; réduisez les préfixes si possible.
• Si vous utilisez des nœuds de sortie, traitez-les comme de l’infra critique : hôtes dédiés, surveillance, et accès strict.
• Faites un balayage d’hygiène trimestriel : appareils, clés, tags, et comportement DNS sur les plateformes.

Restez ennuyeux. L’ennui, c’est comment on dort.