Die Zwei-Tailnet-Falle: ein alter Schlüssel, der das falsche Netz bearbeitete
Kunden erreichen ihren gemieteten Mac über Tailscale. Die SSH-Zugriffsregel steht in der Tailnet-Policy, und wir verwalten diese Regel per Code. Beginnt eine Miete, wird die Adresse des Kunden hinzugefügt. Endet sie, wird sie entfernt. Ein kleines, langweiliges System. Dann sagte es uns, alle Kunden hätten ihren Zugriff verloren. Und es log.
Was das Werkzeug meldete
Eine Routineprüfung meldete, die SSH-Regel für Kunden sei leer. Drei zahlende Kunden könnten sich nicht mehr verbinden, hieß es. Für ein Unternehmen, dessen Produkt der Zugang zu einer Maschine ist, ist das Großalarm.
Die Regel war nicht leer. Wir lasen ein anderes Tailnet.
Zwei Netze, ein Alias
Das Konto hatte zwei Tailnets. Eines enthält die Flotte: die gemieteten Macs, den Hub, jede Freigabe für Kunden. Das andere war ein altes privates Netz aus der Einrichtungszeit, mit einer toten Maschine und einem Laptop.
In der Tailscale-API können Sie ein Tailnet beim Namen nennen oder - übergeben. Das bedeutet "das Tailnet, dem der aufrufende Schlüssel gehört". Unser Code übergab -. Das geht gut, bis es zwei Schlüssel gibt. Die Schlüssel sind ununterscheidbare Zeichenketten, also folgt - stillschweigend dem, der gerade in der Umgebung steht. Ein alter Schlüssel war in eine Konfigurationsdatei gerutscht.
Gefährlich war das Schreiben
Ein Lesevorgang, der lügt, kostet einen Nachmittag. Ein Schreibvorgang, der lügt, verursacht einen Vorfall. Dasselbe Werkzeug hat einen Reparaturmodus, der die Zugriffsregel mit den aktuellen Kunden abgleicht. Gegen das falsche Tailnet ausgeführt, schrieb er brav drei echte Kunden-E-Mail-Adressen in die Policy des alten Netzes. Dort bewirkten sie gar nichts.
Betroffen war tatsächlich kein Kunde. Das Flotten-Tailnet blieb die ganze Zeit unberührt und korrekt. Aber ein paar Minuten lang bearbeitete die Automatisierung die Zugriffskontrolle im falschen Netz und meldete Erfolg.
Die Lösung: das Netz beim Namen nennen
Wir übergeben kein - mehr. Der Code nennt das Flotten-Tailnet jetzt ausdrücklich. Ein Schlüssel, der es nicht sieht, scheitert laut, statt auf das abzudriften, was er sieht.
Jeder Lauf gibt jetzt das Tailnet aus, mit dem er gesprochen hat. Ist das nicht die Flotte, bedeuten die Ergebnisse darunter nichts. Das wissen Sie, bevor Sie danach handeln.
Die allgemeine Lehre
Ein bequemer Standard, der "worauf dieser Zugang gerade zeigt" bedeutet, wird zur Falle, sobald Sie mehr als einen Zugang haben. Aus einem falschen Schlüssel wird dann kein Fehler, sondern eine stille Umleitung. Alles, was schreibt, sollte sein Ziel nennen. Dann scheitert ein falscher Zugang, statt irgendwo Erfolg zu haben, wo Sie es nicht wollten.
Das ist dasselbe Muster wie bei den anderen stillen Fehlern, die wir in Prüfungen, die nicht fehlschlagen können beschrieben haben. Das Werkzeug war sich sicher. Das Werkzeug lag falsch. Und nichts, was es ausgab, hätte es Ihnen verraten, bis es das Netz nannte, das es bearbeitete.
Fragen
- Wie bestimmt ein Tailscale-API-Schlüssel, welches Tailnet er bearbeitet?
- Der Schlüssel gehört zu einem Tailnet. Der Tailnet-Name '-' in der API bedeutet 'das Tailnet, dem dieser Schlüssel gehört'. Zwei Schlüssel für zwei Tailnets sehen gleich aus, also folgt '-' stillschweigend dem Schlüssel.
- Wie unterscheidet man zwei Tailnets sicher?
- Nie nach Augenmaß. Vergleichen Sie, welche Geräte jeder Schlüssel auflisten kann. Der richtige Schlüssel sieht Ihre Flotte. Der falsche sieht, was dieses Konto sonst noch besitzt.
- Sollten Werkzeuge den Tailnet-Alias '-' überhaupt nutzen?
- Nicht für etwas, das schreibt. Nennen Sie das Tailnet ausdrücklich. Dann scheitert ein Schlüssel für das falsche Netz mit einem 404, statt still die falsche ACL zu bearbeiten.
Rechnen Sie selbst nach mit dem Kostenrechner oder mieten Sie einen Runner.