Le piège des deux tailnets : une clé périmée qui a modifié le mauvais réseau

Nos clients joignent leur Mac loué par Tailscale. Nous gardons la règle d’accès SSH dans la policy du tailnet, et nous gérons cette règle depuis du code. Quand une location commence, l’adresse du client est ajoutée. Quand elle se termine, elle est retirée. C’est un petit système ennuyeux. Puis il nous a dit que chaque client avait perdu son accès, et il mentait.

Ce que l’outil a signalé

Une vérification de routine a annoncé que la règle SSH des clients était vide. Trois clients payants, disait-elle, ne pouvaient plus se connecter. C’est une alerte maximale pour une entreprise dont le produit est l’accès à une machine.

La règle n’était pas vide. Nous lisions un autre tailnet.

Deux réseaux, un alias

Le compte avait deux tailnets. L’un contient le parc : les Mac loués, la machine centrale, chaque partage client. L’autre était un ancien réseau personnel, resté de la mise en place, avec une machine morte et un portable.

L’API Tailscale vous permet de nommer un tailnet, ou de passer -, qui signifie "le tailnet auquel appartient la clé appelante". Notre code passait -. Ça va tant qu’il n’y a qu’une clé. Les clés sont des chaînes impossibles à distinguer, donc - suit sans rien dire celle qui est dans l’environnement. Une clé périmée s’était glissée dans un fichier de configuration.

Le danger, c’était l’écriture

Une lecture qui ment fait perdre un après-midi. Une écriture qui ment provoque un incident. Le même outil a un mode de réparation qui aligne la règle d’accès sur les clients actuels. Lancé sur le mauvais tailnet, il a fidèlement écrit trois vraies adresses e-mail de clients dans la policy de l’ancien réseau, où elles ne servaient à rien.

Aucun client n’a réellement été touché, car le tailnet du parc est resté intact et correct tout du long. Mais pendant quelques minutes, l’automatisation modifiait le contrôle d’accès du mauvais réseau et annonçait un succès.

La correction : nommer le réseau

Nous avons cessé de passer -. Le code nomme désormais explicitement le tailnet du parc. Une clé qui ne peut pas le voir échoue bruyamment au lieu de dériver vers ce qu’elle peut voir.

Chaque exécution affiche désormais le tailnet auquel elle a parlé. Si cette ligne n’est pas le parc, les résultats en dessous ne veulent rien dire, et vous le savez avant d’agir.

La leçon générale

Une valeur par défaut pratique qui signifie "ce vers quoi pointe cet identifiant" devient un piège dès que vous avez plus d’un identifiant. Elle transforme une mauvaise clé, au lieu d’une erreur, en une redirection silencieuse. Tout ce qui écrit doit nommer sa cible. Ainsi, un mauvais identifiant échoue au lieu de réussir là où vous ne vouliez pas.

C’est la même forme que les autres pannes silencieuses décrites dans des vérifications qui ne peuvent pas échouer. L’outil était sûr de lui. L’outil avait tort. Et rien de ce qu’il affichait ne vous l’aurait dit, jusqu’à ce qu’il nomme le réseau qu’il modifiait.