Was schützt Tailscales Tailnet Lock wirklich?

Wovor Tailnet Lock schützt

Tailnet Lock ist eine Funktion von Tailscale, die verhindert, dass der eigene Koordinationsserver von Tailscale ein Gerät zu Ihrem Tailnet hinzufügt. Wenn die Funktion aktiviert ist, akzeptieren Ihre Nodes keinen Node Key, der nicht mit einem Schlüssel signiert wurde, der auf einem bereits vertrauenswürdigen Rechner gespeichert ist. Die Control Plane verteilt also weiterhin Schlüssel, kann aber keine Mitglieder mehr anlegen. Diese Aussage ist bewusst eng gefasst. Tailnet Lock schützt den Zeitpunkt, an dem ein Gerät beitritt. Es schützt kein Gerät, dessen Schlüssel bereits gestohlen wurde.

In einem gewöhnlichen Tailnet erzeugt jeder Node seine eigenen WireGuard-Schlüssel und überträgt den privaten Teil niemals an einen anderen Ort. Der Koordinationsserver ist die Control Plane, mit der jeder Client kommuniziert. Er verteilt öffentliche Schlüssel und teilt jedem Node mit, wer zum Tailnet gehört. Darauf basiert das Design von Tailscales Koordinationsserver und Schlüsselverteilung. Deshalb gilt auch: Tailscale besitzt niemals die Schlüssel, die Ihren Datenverkehr verschlüsseln. Das bedeutet außerdem, dass die Control Plane die Mitgliedschaft eigenständig festlegt. Wer die Kontrolle über sie erlangt, könnte einen zusätzlichen Node Key in Ihrem Tailnet veröffentlichen. Ihre Nodes würden den Datenverkehr dann für diesen Node verschlüsseln, weil das Protokoll keinen Mechanismus bietet, mit dem ein Node einen eingeschleusten Schlüssel von einem echten Schlüssel unterscheiden kann.

Das Bedrohungsmodell, präzise formuliert

Tailnet Lock beantwortet die Frage nach dem Angreifer, der den Coordination Server kontrolliert. Das umfasst eine Kompromittierung der Tailscale-Infrastruktur, einen böswilligen Insider bei Tailscale sowie eine Anordnung, die Tailscale zum Handeln zwingt. Gegen diesen Angreifer, und nur gegen diesen, ändert Tailnet Lock die Antwort von „er kann einen Node hinzufügen“ zu „er kann es nicht, und der Versuch ist sichtbar“.

Der Mechanismus ist eine Signaturkette, die Sie selbst kontrollieren. Jeder signierende Node erzeugt lokal einen Tailnet-Lock-Schlüssel (TLK) und bewahrt ihn auf diesem Gerät auf. Ihr Tailnet erhält ein Append-only-Protokoll der Berechtigungsänderungen, die Tailnet Key Authority (TKA), und jeder Node besitzt eine eigene Kopie dieses Protokolls. Ein Node-Schlüssel, der ohne gültige Signatur eines aktuell vertrauenswürdigen TLK eintrifft, wird abgelehnt. Der Peer erhält dadurch keine Konnektivität und wird als ausgesperrt angezeigt. Das Whitepaper von Tailscale formuliert das Ergebnis eindeutig: Die Tailscale-Infrastruktur kann einem Tailnet mit aktiviertem Tailnet Lock keinen nicht autorisierten Node hinzufügen. Jeder entsprechende Versuch kann erkannt und blockiert werden.

Vier Dinge deckt Tailnet Lock nicht ab. Für die meisten Tailnets ist jedes davon wichtiger als der Aspekt, den Tailnet Lock tatsächlich abdeckt.

• Ein gestohlenes Gerät. Eine Signatur belegt, dass ein vertrauenswürdiger Administrator den Node-Schlüssel irgendwann genehmigt hat. Sie sagt nichts darüber aus, wer den Laptop jetzt besitzt.
• Ein kompromittierter signierender Node. Die eigene Liste der Einschränkungen von Tailscale sagt es direkt: Tailnet-Lock-Schlüssel werden auf dem Gerät gespeichert. Ein Angreifer, der Zugriff auf das Gerät erhält, kann daher auch den Schlüssel erlangen. Einen signierenden Node sollten Sie genauso sorgfältig absichern wie einen Rechner, auf dem sich ein Root-SSH-Schlüssel befindet. Das entspricht derselben Vorgehensweise wie beim Erzeugen, Speichern und Rotieren von SSH-Schlüsseln.
• Denial of Service. Das Whitepaper stellt ausdrücklich fest, dass Tailnet Lock vor nicht autorisierten Nodes schützt, nicht vor Denial of Service. Eine böswillige Control Plane kann weiterhin die Verteilung von Updates stoppen und Ihre Konnektivität unterbrechen. Sie kann jedoch kein Mitglied werden.
• Die ersten fünf Minuten. Lesen Sie den nächsten Abschnitt. Diesen Teil überspringen viele.

Warum tailnet lock Trust-on-First-Use ist

Wenn Sie tailnet lock aktivieren, erreicht der anfängliche Satz vertrauenswürdiger Schlüssel Ihre Nodes über die Control Plane. Genau dieser Instanz soll das Vertrauen entzogen werden. Jeder Node akzeptiert beim ersten Mal die erhaltenen Informationen und setzt sie danach durch. Im Whitepaper von Tailscale wird diese Lücke beschrieben: Wenn tailnet lock erstmals aktiviert wird, verlässt sich jeder Node auf den initialen Zustand von tailnet lock, den er von der Control Plane erhält. Wenn die Control Plane zu diesem Zeitpunkt bereits kompromittiert war, konnte sie einen Schlüsselsatz mit dem Schlüssel eines Angreifers hinterlegen. Jede spätere Signatur wäre dann gültig.

Das ist Trust on First Use (TOFU), dasselbe Modell wie bei einem SSH-Hostschlüssel-Fingerabdruck, den Sie bei der ersten Verbindung akzeptieren. Es gibt keine externe Instanz, mit der Sie den Wert abgleichen können. Die Prüfung erfolgt daher manuell und liegt in Ihrer Verantwortung.

tailscale lock status

Führen Sie den Befehl nach der Aktivierung auf mehreren Nodes aus. Vergleichen Sie die von jedem Node gemeldeten vertrauenswürdigen Werte tlpub: mit den Schlüsseln, die Ihre signierenden Nodes tatsächlich ausgegeben haben. Führen Sie den Vergleich über einen Kanal durch, der nicht vom Tailnet abhängt. Eine kompromittierte Control Plane, die einen manipulierten Schlüsselsatz hinterlegt hat, kann auch den Chat einsehen, den Sie für die Prüfung verwenden. Dieser einmalige Vorgang dauert zehn Minuten. Er ist das Einzige, was zwischen Ihnen und einer Sperre steht, die nichts schützt.

Prüfen Sie diese Punkte, bevor Sie die Funktion aktivieren

• Jeder Node, den Sie weiterhin verwenden möchten, benötigt Tailscale v1.46.1 oder höher. Dies ist die Mindestversion, die in der Tailscale-Dokumentation für tailnet lock genannt wird. Führen Sie tailscale version auf jedem Node aus, einschließlich des Routers oder der Appliance, die Sie einmal registriert und danach vergessen haben.
• Sie müssen mindestens zwei Signing-Nodes auswählen. Der Grund ist nicht die Zeremonie: Die Signing-Keys liegen auf diesen Geräten. Ein einzelner Signing-Node bedeutet daher, dass bereits ein einziger ausgefallener Datenträger dazu führen kann, dass Sie Ihrem Tailnet nie wieder eine Maschine hinzufügen können.
• Ein Android-Gerät kann nicht als Signing-Node fungieren, weil es den Signiervorgang nicht ausführen kann.
• Tailnet lock und Device Approval sind sich gegenseitig ausschließende Funktionen. Wenn Ihr Tailnet bereits die manuelle Genehmigung von Geräten erfordert, müssen Sie sich zwischen beiden Funktionen entscheiden. Sie können sie nicht kombinieren.
• In der Tailscale-Dokumentation wird tailnet lock mit Stand September 2026 für die Tarife Personal und Enterprise aufgeführt. Bestätigen Sie daher Ihren Tarif, bevor Sie die Funktion in einem Security Review zusagen.

So aktivieren Sie Tailnet Lock

Die Admin-Konsole erstellt den Befehl, den Sie anschließend auf einem Rechner ausführen. Keine der beiden Hälften funktioniert allein.

1. Öffnen Sie in der Admin-Konsole die Seite für die Geräteverwaltung, und aktivieren Sie Tailnet Lock.
2. Wählen Sie die Nodes aus, deren Tailnet-Lock-Schlüsseln Sie vertrauen möchten. Wählen Sie mindestens zwei Nodes auf Hardware aus, auf die Sie physisch zugreifen können.
3. Entscheiden Sie, ob Sie ein Deaktivierungsgeheimnis an den Tailscale-Support senden möchten. Lesen Sie den nächsten Abschnitt, bevor Sie diese Frage beantworten.
4. Kopieren Sie den von der Konsole erzeugten Befehl tailscale lock init. Er enthält für jeden ausgewählten Signatur-Node ein Argument tlpub:.
5. Führen Sie ihn auf einem dieser Signatur-Nodes aus.

tailscale lock init "tlpub:SIGNING_NODE_1_KEY" "tlpub:SIGNING_NODE_2_KEY"

Jeder Node, der sich bereits im Tailnet befindet, wird bei der Initialisierung mit den vertrauenswürdigen Schlüsseln signiert. Daher funktionieren vorhandene Verbindungen weiterhin. Neu hinzugekommene Nodes verhalten sich anders. Ein Rechner, der einem gesperrten Tailnet beitritt, erhält einen nicht signierten Node-Schlüssel. tailscale lock status auf diesem Rechner zeigt das an:

This node is LOCKED OUT by tailnet-lock, and action is required to establish connectivity.

Die Admin-Konsole zeigt denselben Status als Locked out-Badge an. Der Filter für die Maschinenliste property:locked-out findet alle betroffenen Nodes gleichzeitig. Die Statusausgabe auf dem ausgesperrten Node gibt außerdem den genauen Befehl aus, der das Problem behebt. Kopieren Sie diese Zeile, und führen Sie sie auf einem Signatur-Node aus:

tailscale lock sign "nodekey:NODE_KEY" "tlpub:ROTATION_KEY"

Signatur-Nodes ändern sich im Lauf der Zeit. Dafür gibt es zwei Befehle. tailscale lock add tlpub:<key> vertraut einem neuen Signatur-Node. tailscale lock remove tlpub:<key> nimmt einen Signatur-Node außer Betrieb. Standardmäßig signiert der Befehl die Nodes, die der ausgemusterte Schlüssel signiert hatte, erneut, damit sie weiterhin funktionieren. Mit --re-sign=false unterdrücken Sie dieses Verhalten. Wurde ein Signatur-Node gestohlen und nicht regulär außer Betrieb genommen, verwenden Sie tailscale lock revoke-keys tlpub:<key>. Der Befehl wird mithilfe von --cosign und anschließend --finish schrittweise auf den verbleibenden Signatur-Nodes ausgeführt. tailscale lock log --limit 20 gibt den aktuellen Verlauf der Autorität aus. Dort suchen Sie nach Informationen, wenn ein Node ausgesperrt ist und sich niemand an eine Änderung erinnert.

Die zehn Deaktivierungsgeheimnisse und warum sie der riskante Teil sind

tailscale lock init gibt zehn Deaktivierungsgeheimnisse aus. Sie werden bei der Initialisierung einmal angezeigt und danach nie wieder. Jedes einzelne davon deaktiviert tailnet lock für das gesamte Tailnet:

tailscale lock disable "DISABLEMENT_SECRET"

In der Tailscale-Dokumentation wird die Folge ohne Beschönigung beschrieben: Wenn Sie Ihre Deaktivierungsgeheimnisse verlieren und Tailscale support keines davon erhalten hat, kann das Tailnet nicht wiederhergestellt werden. Stellen Sie sich die konkrete Situation vor. Ihre beiden Signaturknoten sind ein gelöschter Laptop und ein gelöschter VPS. Niemand kann einen neuen Node-Key signieren, einen Signaturknoten hinzufügen oder die Sperre deaktivieren. Das Tailnet läuft für bestehende Mitglieder weiter und nimmt dauerhaft keine neuen Mitglieder an. Der Ausweg besteht darin, ein neues Tailnet aufzubauen und alle Geräte erneut zu registrieren.

Speichern Sie die Geheimnisse daher wie die Wiederherstellungscodes, die sie sind. Bewahren Sie mindestens zwei Kopien an Orten auf, die nicht beide davon abhängen, dass das Tailnet erreichbar ist, und halten Sie eine davon offline. Eine Kopie, die nur auf einem Server liegt, den Sie über das Tailnet erreichen, ist keine Sicherung.

Die Support-Option erfordert eine bewusste Entscheidung und sollte nicht einfach standardmäßig verwendet werden. Wenn Sie ein Geheimnis an Tailscale support senden, kann Tailscale Ihr tailnet lock deaktivieren. Damit geben Sie einen Teil der Garantie an genau die Partei zurück, deren Einfluss diese Funktion begrenzen soll. Gleichzeitig verhindert diese Option, dass ein verlorener Ordner Ihr Tailnet unbrauchbar macht. Wenn Sie tailnet lock aktiviert haben, weil eine Prüfung des Risikos durch Drittanbieter klären sollte, was bei einem Einbruch in die Systeme Ihres VPN-Anbieters geschieht, senden Sie das Geheimnis nicht. Wenn Sie die Funktion aktiviert haben, weil Administratoren wechseln und Sie die Aufnahme neuer Nodes an Geräte binden möchten, senden Sie es und können beruhigter sein.

Warum unbeaufsichtigte Bereitstellung fehlschlägt und wie Sie das beheben

Das ist die Folge, auf die Teams innerhalb einer Woche stoßen. In einem gesperrten Tailnet wird eine Maschine, die startet und tailscale up mit einem gewöhnlichen Authentifizierungsschlüssel ausführt, ausgesperrt eingebunden. Die Automatisierung meldet Erfolg, der Knoten erscheint in der Konsole, und niemand kann ihn erreichen. Die Signatur muss vor der Erstellung des Knotens erfolgen, nicht danach. Dazu muss der Authentifizierungsschlüssel signiert werden.

AUTH_KEY="tskey-auth-xxxxxxxxxxxxxxxx"
tailscale lock sign $AUTH_KEY

Führen Sie den Befehl auf einem Signaturknoten aus. Er gibt eine signierte Version des Authentifizierungsschlüssels aus. Dieser signierte Wert wird von Ihrem Image, Ihrer cloud-init-Datei oder Ihrer Terraform-Variable an tailscale up --auth-key übergeben. Jeder damit erstellte Knoten wird bereits signiert und erreichbar eingebunden.

Bevor Sie darauf stoßen, sollten Sie zwei Fehlerfälle kennen. Erstens kommt die Signierung mit parallelen Aufrufen nicht gut zurecht. Issue 15266 im Repository tailscale/tailscale wurde im März 2025 eröffnet und ist weiterhin offen. Es beschreibt Terraform-Ausführungen, bei denen parallele Aufrufe von tailscale lock sign leere signierte Schlüssel zurückgaben. Dadurch wurden einige Knoten ausgesperrt gestartet, während die übrigen funktionierten. Als Workaround signierte der Melder jeweils nur einen Schlüssel und wartete kurz zwischen den Aufrufen. Lassen Sie Ihre Automatisierung prüfen, ob der Befehl einen nicht leeren Schlüssel zurückgegeben hat, bevor sie ihn speichert.

Zweitens hinterlassen signierte Authentifizierungsschlüssel Zustandsdaten. Durch die Signierung wird der Autorität ein Schlüssel hinzugefügt. Dieser Schlüssel bleibt erhalten, nachdem der damit erstellte Knoten entfernt wurde. Issue 16607 vom Juli 2025 beschreibt eine Automatisierung, die pro Bereitstellung einen neuen Schlüssel signierte, bis die Autorität ihr Limit erreichte:

network-lock modify failed: modify network-lock keys: generating checkpoint: generated update was invalid: checkpoint state: too many keys (552, max 512)

Ab diesem Zeitpunkt konnte das Tailnet weder neue Schlüssel hinzufügen noch die überzähligen Schlüssel entfernen. Das Entfernen ist selbst eine Aktualisierung der Autorität und muss ein gültiges Prüfsummenprotokoll erzeugen. Signieren Sie wenige Schlüssel und verwenden Sie diese wieder, statt für jede Maschine einen eigenen Schlüssel zu signieren. Prüfen Sie tailscale lock log außerdem gelegentlich, damit Sie die Anzahl kennen und nicht erst durch einen Fehler erfahren.

Ephemere und CI-Knoten benötigen einen Plan

Ephemere Knoten, die sich beim Abmelden aus dem Tailnet entfernen, sind weiterhin Knoten. Sie benötigen daher weiterhin eine Signatur, um mit anderen Systemen zu kommunizieren. Ein CI-Job, der dem Tailnet beitritt, um ein Deployment auszuführen, benötigt genau wie ein langlebiger Server einen vorab signierten Authentifizierungsschlüssel. In CI wirkt sich auch die oben beschriebene Ansammlung von Schlüsseln am stärksten aus, weil dort die meisten Knoten erstellt und wieder entfernt werden.

Das praktikable Muster ist ein signierter, wiederverwendbarer Authentifizierungsschlüssel für ephemere Knoten, der im Secret Store der CI-Umgebung gespeichert und nach einem von Ihnen festgelegten Zeitplan anstatt bei jedem Job erneuert wird. Bei jeder Erneuerung wird ein Schlüssel in der Authority verbraucht. Diese Anzahl lässt sich einplanen. Die Signierung für jeden einzelnen Job hat die 552 Schlüssel erzeugt.

Das Gleiche gilt für Server, die den Datenverkehr anderer Rechner weiterleiten. Ein Subnet-Router, der einen privaten Bereich von einem VPS aus bekannt gibt, spricht für jede dahinterliegende Adresse. Ein eingeschleuster Knoten an dieser Position erreicht daher weit mehr als nur einen Host. Diese Systeme sollten Sie mit signierten Schlüsseln provisionieren und aus dem vollständig automatisierten Pfad heraushalten.

Die beiden Notfallmechanismen und ihre jeweilige Funktion

tailscale lock disable <disablement-secret> deaktiviert tailnet lock für das gesamte Tailnet. Dafür ist eines der zehn Secrets erforderlich. Verwenden Sie diesen Befehl, wenn die Authority selbst das Problem ist.

tailscale lock local-disable

tailscale lock local-disable ist der Notfallmechanismus für einzelne Nodes. Sein Geltungsbereich wird häufig missverstanden. Der Node, auf dem Sie den Befehl ausführen, setzt tailnet lock anschließend nicht mehr durch. Dadurch akzeptiert dieser Node Peers mit nicht signierten Schlüsseln. Andere Nodes akzeptieren den nicht signierten Schlüssel dieses Nodes dadurch nicht. Ein ausgesperrter Server wird nicht erreichbar, nur weil Sie local-disable auf ihm ausgeführt haben. Deshalb beschreibt die Tailscale-Dokumentation, dass Sie den Befehl auf jedem Ihrer Nodes ausführen sollen, damit das Tailnet tailnet lock praktisch ignoriert. Behandeln Sie dies als Notfallmaßnahme für einen Node, der momentan nicht signiert werden kann. Signieren Sie den Node anschließend ordnungsgemäß und lassen Sie die Durchsetzung nicht dauerhaft deaktiviert.

Wer sollte tailnet lock aktivieren und wer nicht?

Aktivieren Sie die Funktion, wenn die Aufnahme neuer Knoten auch dann sicher bleiben muss, wenn Personen das Unternehmen verlassen. Ohne tailnet lock kann jede Person mit Administratorrechten in der Konsole eine Maschine hinzufügen. Mit tailnet lock ist dafür zusätzlich ein Gerät erforderlich, das einen vertrauenswürdigen Signaturschlüssel enthält. Ein ausgeschiedener Administrator, dessen Konsolenzugriff Sie nicht widerrufen haben, kann dann trotzdem keinen Knoten hinzufügen. Aktivieren Sie die Funktion auch, wenn ein Fragebogen zu Risiken durch Drittanbieter wissen will, was verhindert, dass Ihr VPN-Anbieter Ihrem Netzwerk beitritt. tailnet lock beantwortet diese Frage mit einem technischen Mechanismus statt mit einer Zusicherung.

Aktivieren Sie die Funktion nicht für ein Tailnet mit nur einer Person, einem Laptop, einem Telefon und einem VPS. Die realistische Bedrohung für dieses Tailnet besteht darin, dass Sie den Zugriff darauf verlieren, nicht darin, dass Tailscale kompromittiert wird. tailnet lock fügt zehn Geheimnisse hinzu, die Sie dauerhaft korrekt speichern müssen. Wenn Sie diese Geheimnisse verlieren, ist die Wiederherstellung nicht möglich. Dadurch steigt das Risiko, dem Sie tatsächlich ausgesetzt sind, um ein Risiko zu senken, dem Sie nicht ausgesetzt sind. Das gilt ebenso für ein kleines Team, das kein Verzeichnis darüber führt, wer welches Signaturgerät besitzt. Sorgen Sie zuerst für eine korrekte Dokumentation. tailnet lock ist im Kern Dokumentation mit einem dauerhaften Ausfallmodus.

Headscale beantwortet dieselbe Frage auf andere Weise

Wenn der Einwand lautet, dass ein Dritter entscheidet, wer zu Ihrem Netzwerk gehört, gibt es zwei Antworten. Tailnet lock behält den Tailscale-Koordinierungsserver bei und entzieht ihm die Möglichkeit, Mitglieder hinzuzufügen. Headscale ausführen, den Open-Source-Koordinierungsserver, den Sie selbst hosten entfernt stattdessen den Server. Damit behalten Sie sowohl die Kontrolle als auch den Aufwand für seinen Betrieb: Patches, Backups und einen Ausfall, den Sie um zwei Uhr morgens selbst beheben müssen. Keine der beiden Optionen ist grundsätzlich sicherer. Entscheiden Sie anhand des Fehlers, für den Sie lieber selbst verantwortlich wären: eine von Ihnen eingeschränkte, gehostete Steuerungsebene oder eine Steuerungsebene, die Sie selbst betreiben.

FAQ

Was verhindert tailnet lock tatsächlich?

Es verhindert, dass der Tailscale-Koordinationsserver einen Node zu Ihrem tailnet hinzufügt. Wenn tailnet lock aktiviert ist, wird ein Node-Schlüssel erst akzeptiert, nachdem ein von Ihnen kontrollierter Signing-Node ihn mit seinem tailnet-lock-Schlüssel signiert hat. Eine kompromittierte Control Plane kann dann zwar Schlüssel verteilen, aber kein Mitglied hinzufügen. Zusätzliche Verschlüsselung bietet tailnet lock nicht, weil der Datenverkehr zwischen den Nodes bereits mit WireGuard-Schlüsseln Ende-zu-Ende-verschlüsselt ist, die der Koordinationsserver nie besitzt. Gegen ein gestohlenes Gerät, einen kompromittierten Signing-Node oder eine Control Plane, die Ihr tailnet einfach nicht mehr bereitstellt, hilft es ebenfalls nicht.

Was passiert, wenn ich alle zehn Deaktivierungsgeheimnisse verliere?

Die Geheimnisse werden einmal ausgegeben, wenn tailscale lock init ausgeführt wird, und danach nie wieder angezeigt. Wenn Sie alle verlieren und keines an den Tailscale-Support gesendet haben, kann das tailnet laut Dokumentation nicht wiederhergestellt werden. Wenn Sie in diesem Fall auch Ihre Signing-Nodes verlieren, können Sie nie wieder einen Node-Schlüssel signieren und die Sperre nie deaktivieren. Der einzige verbleibende Weg ist dann ein neues tailnet, in dem jedes Gerät erneut registriert wird. Bewahren Sie zwei Kopien an Orten auf, die nicht beide davon abhängen, dass das tailnet verfügbar ist. Bewahren Sie eine davon offline auf.

Muss ich jedes neue Gerät manuell signieren?

Nein. Signieren Sie stattdessen den Auth-Schlüssel und nicht den Node. Exportieren Sie den Schlüssel auf einem Signing-Node und führen Sie tailscale lock sign $AUTH_KEY aus. Übergeben Sie anschließend den ausgegebenen signierten Wert an tailscale up --auth-key in Ihrem Image- oder Provisioning-Tool. Auf diese Weise erstellte Nodes werden bereits signiert angelegt. Signieren Sie eine kleine Anzahl wiederverwendbarer Schlüssel statt eines Schlüssels pro Maschine. Jeder signierte Schlüssel fügt der Authority einen Schlüssel hinzu, der auch nach dem Entfernen des Nodes bestehen bleibt. Außerdem ist die Authority auf 512 Schlüssel begrenzt. Dieses Limit wurde in der Praxis bereits durch Automatisierung erreicht.

Ist tailnet lock dasselbe wie die Gerätefreigabe?

Nein. Sie können nicht beide Funktionen verwenden, weil sie sich gegenseitig ausschließen. Die Gerätefreigabe ist eine Richtlinienprüfung in der Administrationskonsole: Ein Administrator aktiviert eine Option, bevor ein neues Gerät Zugriff erhält, und der Koordinationsserver setzt diese Entscheidung durch. tailnet lock ist eine kryptografische Prüfung durch Ihre eigenen Nodes. Dabei werden Schlüssel verwendet, die auf Ihrer eigenen Hardware gespeichert sind. Deshalb bleibt die Prüfung auch dann wirksam, wenn der Koordinationsserver feindlich agiert. Die Gerätefreigabe ist die einfachere Kontrolle für die Verwaltung von Benutzern. tailnet lock beantwortet die Frage, ob Sie dem Anbieter vertrauen müssen.