Ist Tailscale sicher? Das Vertrauensmodell erklärt

Ist Tailscale sicher? Die kurze Antwort

Ist Tailscale sicher? Für den Punkt, über den sich die meisten Menschen Sorgen machen, lautet die Antwort: ja. Der Coordination Server, der Ihr tailnet betreibt, besitzt niemals die privaten Schlüssel, mit denen Ihr Datenverkehr verschlüsselt wird. Daher kann er nicht lesen, was Ihre Geräte untereinander senden. Tailscale formuliert es auf seiner Security-Seite direkt: „Private Schlüssel verlassen niemals das Gerät. Der gesamte Datenverkehr ist immer Ende-zu-Ende-verschlüsselt.“ Die nützlichere Frage ist eine andere. Ein kompromittierter Coordination Server oder ein Server, der aufgrund einer gerichtlichen Anordnung handeln muss, braucht Ihre Pakete nicht zu lesen. Er entscheidet, welchen öffentlichen Schlüsseln Ihre Geräte vertrauen. Dadurch könnte er ein Gerät registrieren, das Sie nie genehmigt haben.

Das Vertrauensmodell lässt sich in einem Satz zusammenfassen: Die Verschlüsselung schützt die Daten, und die Control Plane entscheidet über die Mitgliedschaft. Jeder folgende Abschnitt nennt eine Partei, der Sie vertrauen müssen, beschreibt, was diese Partei tatsächlich tun kann, und nennt die Kontrolle, die ihre Möglichkeiten begrenzt. Wenn das Produkt für Sie neu ist, beginnen Sie mit was Tailscale ist und wie sein Mesh funktioniert.

Steuerungsebene und Datenebene sind getrennt

Tailscale ist ein Mesh-VPN (virtuelles privates Netzwerk) auf Basis von WireGuard, demselben Protokoll, das Sie manuell auf einem selbst gehosteten WireGuard-VPS konfigurieren würden. Jedes Gerät erzeugt sein eigenes WireGuard-Schlüsselpaar lokal. Der Beitrag How it works von Tailscale bezeichnet den Koordinationsserver als „einen gemeinsam genutzten Ablageort für öffentliche Schlüssel“ und sagt: „Der private Schlüssel verlässt seinen Knoten niemals.“

Die Datenebene besteht aus dem verschlüsselten Datenverkehr zwischen Ihren Geräten. Er wird von Gerät zu Gerät übertragen, sofern das Netzwerk eine direkte Verbindung zulässt. Die Steuerungsebene umfasst alles andere: Welche Geräte zum Tailnet gehören, welcher öffentliche Schlüssel welchem Gerät zugeordnet ist, die Zugriffsrichtlinie, die DNS-Einstellungen und die Relay-Liste. Tailscale betreibt die Steuerungsebene als gehosteten Dienst. Sie betreiben die Datenebene auf Ihren eigenen Rechnern.

Halten Sie diese beiden Ebenen getrennt, lassen sich alle Sicherheitsfragen in diesem Zusammenhang beantworten. Die Verschlüsselung ist eine Eigenschaft der Datenebene. Die Mitgliedschaft wird von der Steuerungsebene festgelegt. Keine Verschlüsselung sagt Ihnen, wer als Peer zugelassen ist.

Was könnte ein kompromittierter Koordinationsserver tun?

Er kann Ihren Datenverkehr nicht entschlüsseln. Die Schlüssel für die Verschlüsselung werden auf Ihren Geräten erzeugt und nie hochgeladen. Es gibt daher nichts, was ein Angreifer übernehmen oder offenlegen könnte, um den Tunnel zu öffnen. Das gilt auch für weitergeleiteten Datenverkehr, auf den weiter unten eingegangen wird.

Er könnte einen Knoten registrieren. Als Tailscale tailnet lock ankündigte, beschrieb das Unternehmen das Risiko mit eigenen Worten: Ein bösartiger Server könnte „einen heimlich hinzugefügten Knoten verwenden, um Datenverkehr an Ihre vorhandenen Knoten zu senden oder von ihnen zu empfangen“. Dann „wäre es unerheblich, dass der Datenverkehr verschlüsselt ist, weil der Peer selbst bösartig wäre“. Ihr Gerät vertraut einem Peer, weil die Control Plane ihm mitgeteilt hat, dass dieser Schlüssel zum Tailnet gehört.

Er könnte ändern, welche Ziele Ihre Geräte erreichen dürfen. Die Zugriffsrichtlinie befindet sich in der Control Plane und wird an die Knoten verteilt. Das Whitepaper zu tailnet lock von Tailscale erklärt, tailnet lock „verhindert nicht, dass eine kompromittierte Control Plane die Konnektivität in Ihrem Netzwerk beeinträchtigt, etwa indem sie neue Knotenschlüssel nicht verteilt oder eine Zugriffsrichtlinie verteilt, die den Zugriff auf alle Knoten verweigert“.

Er sieht in jedem Fall Verbindungsmetadaten. Die Netzwerkflussprotokolle von Tailscale erfassen Öffnungs- und Schließereignisse für jede Verbindung zwischen Maschinen. In der Dokumentation heißt es, diese Protokolle „enthalten ausdrücklich keinerlei Informationen über Clientvorgänge oder die Inhalte des Netzwerkverkehrs“. Die Control Plane kann also wissen, welche Ihrer Geräte miteinander kommuniziert haben und wann. Sie weiß nicht, was sie gesagt haben.

Nur einer dieser Punkte betrifft die Verschlüsselung. Bei den anderen geht es darum, wer Mitglied ist und was die Richtlinie festlegt. Deshalb sollten Sie besonders auf die Kontrollen achten, die die Registrierung von Knoten steuern.

Der Identitätsanbieter ist die Vertrauensbasis Ihres Tailnets

Tailscale führt keine eigene Passwortdatenbank. In der Dokumentation wird ausdrücklich darauf hingewiesen, dass es keine Tailscale-Passwörter gibt. Die Anmeldung wird an einen Identitätsanbieter (IdP) delegiert: Apple, Google, GitHub, Microsoft, Okta, OneLogin oder einen benutzerdefinierten OpenID-Connect-Provider.

Betrachten Sie das als Sicherheitsaussage, denn genau das ist es. Wer sich bei Ihrem Google- oder Microsoft-Konto anmelden kann, kann sich auch bei Ihrem Tailnet anmelden. Ihre Multi-Faktor-Authentifizierung (MFA) entspricht den Vorgaben des IdP. Ihr Offboarding entspricht dem Vorgehen des IdP, wenn eine Person das Unternehmen verlässt. Ein durch Phishing kompromittiertes IdP-Konto ist ein Tailnet-Konto. Der Angreifer muss WireGuard nicht angreifen: Er fügt ein Gerät hinzu und übernimmt alle Berechtigungen, die Ihre Richtlinie diesem Benutzer gewährt.

Zwischen einem gestohlenen Identitätskonto und einem funktionsfähigen Gerät in Ihrem Tailnet stehen zwei Kontrollen: Gerätegenehmigung und Schlüsselablauf. Tailnet lock ist eine dritte Kontrolle. Sie richtet sich jedoch gegen die Steuerungsebene und nicht gegen das Konto.

Gerätegenehmigung: Kein Gerät wird hinzugefügt, bevor eine Person zustimmt

Die Dokumentation von Tailscale beschreibt die Gerätegenehmigung als Funktion, mit der „Tailscale-Netzwerkadministratoren neue Geräte prüfen und genehmigen können, bevor diese dem Tailscale-Netzwerk beitreten“. Ein Owner, Admin oder IT-Admin kann die Genehmigung erteilen. Ein neues Gerät zeigt auf der Seite „Machines“ das Kennzeichen „Needs approval“, bis jemand eine Aktion ausführt.

Aktivieren Sie diese Funktion, ändert sich der Ablauf bei einem gestohlenen Konto. Der Angreifer meldet sich an, das Gerät wird registriert und wartet anschließend, ohne etwas erreichen zu können. In Ihrer Administrationskonsole sehen Sie gleichzeitig ein Kennzeichen, das darauf hinweist, dass ein Ihnen unbekanntes Gerät den Beitritt anfordert. Automatisierung funktioniert weiterhin, weil Sie einen Auth-Key bei seiner Erstellung als vorab genehmigt markieren können. Geräte lassen sich außerdem über die API genehmigen.

Auth-Keys sind der andere Zugangsweg und müssen daher wie Zugangsdaten behandelt werden. Die Dokumentation von Tailscale weist ausdrücklich auf die riskante Variante hin: „Seien Sie bei wiederverwendbaren Keys sehr vorsichtig. Wenn diese gestohlen werden, können sie sehr gefährlich sein. Bewahren Sie sie am besten in einem speziell dafür entwickelten Key-Vault-Produkt auf.“ Im August 2026 liegt der dokumentierte Ablaufbereich für Keys bei 1 bis 90 Tagen. Wenn kein Ablauf angegeben wird, gilt standardmäßig das Maximum von 90 Tagen. Bevorzugen Sie einmalig verwendbare Keys. Markieren Sie sie für Geräte, die nur vorübergehend vorhanden sind, als ephemeral. Bewahren Sie wiederverwendbare Keys in mit Ansible Vault verschlüsselter Form oder in einem Secrets-Manager auf, nicht in einem Shell-Skript.

Schlüsselablauf: der Timer, der jeden anderen Fehler begrenzt

Node-Schlüssel laufen ab. Dadurch wird ein gestohlenes oder vergessenes Gerät zu einem vorübergehenden Problem. In der Tailscale-Dokumentation steht: „By default, new domains are set with an expiry period of 180 days“. Außerdem heißt es dort: „If reauthentication does not occur, keys expire and connections to/from the given endpoint will stop working.“ Sie können ein Gerät selbst erneut authentifizieren:

tailscale up --force-reauth

Die Dokumentation warnt, dass dies „might bring down the tailnet connection and thus should not be done remotely over SSH or RDP without an alternate means to log in if the connection is lost“. Führen Sie den Befehl bei bestehendem Konsolenzugriff oder über einen zweiten Zugangsweg zum Rechner aus. Andernfalls unterbrechen Sie möglicherweise genau die Netzwerkverbindung, die Sie gerade verwenden.

Bei Servern wird diese Kontrolle häufig angepasst. Ein Rechner, der sich alle 180 Tage erneut authentifizieren muss, fällt um 3am aus dem tailnet, wenn niemand ihn überwacht. Deshalb deaktivieren Administratoren den Schlüsselablauf auf solchen Geräten. Dadurch entfällt der Timer, der einen gestohlenen Schlüssel später sperren würde. Für einen Server ist ein getaggtes Gerät die bessere Lösung. Ein Tag ordnet den Rechner einer Maschine und nicht einer Person zu. Dadurch bleibt der Rechner auch aktiv, wenn diese Person das Unternehmen verlässt. Unabhängig von Ihrer Entscheidung sollten Sie dokumentieren, auf welchen Rechnern der Schlüsselablauf deaktiviert ist. Diese Schlüssel bleiben gültig, bis Sie das Gerät löschen.

Tailnet Lock: den Koordinationsserver aus der Vertrauenskette entfernen

Tailnet Lock setzt direkt beim Aufnahmeproblem an. Die Dokumentation zu Tailnet Lock von Tailscale erläutert den Mechanismus: „Wenn ein neuer Knoten dem Tailnet beitritt, muss sein öffentlicher Knotenschlüssel mit einem Tailnet-Lock-Schlüssel signiert werden. Der Koordinationsserver verteilt den signierten öffentlichen Knotenschlüssel an die Peer-Knoten.“ Ihre vorhandenen Geräte prüfen diese Signatur, bevor sie einen Peer akzeptieren. Ein Knotenschlüssel, den die Steuerungsebene eigenständig erzeugt hat, wird daher abgelehnt.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init aktiviert die Funktion. Dabei legen Sie auch Ihre signierenden Knoten fest. Tailscale verlangt bei der Initialisierung mindestens zwei signierende Knoten und erlaubt höchstens 20 in einem Tailnet. Danach benötigt jedes neue Gerät eine Signatur von einem dieser Knoten. Das verursacht einen echten betrieblichen Aufwand: Für das Hinzufügen eines Telefons müssen Sie einen Befehl auf einem Laptop ausführen.

Die Einschränkungen sind dokumentiert und wichtiger als die Funktionsbeschreibung:

• Wenn Sie das Geheimnis zum Deaktivieren verlieren, gibt es keine Wiederherstellung. In der Dokumentation heißt es: „Wenn Sie Ihre Deaktivierungsgeheimnisse verlieren und Tailscale keines davon bereitgestellt haben, kann das Tailnet nicht wiederhergestellt werden.“
• Der Signaturschlüssel liegt auf einem Gerät, das Ihnen gehört. Damit übernimmt er das Sicherheitsniveau dieses Geräts. Die Dokumentation ist eindeutig: „Wenn das Gerät kompromittiert wurde, kann der Schlüssel erlangt werden.“
• Sie können nicht beide Kontrollen gleichzeitig verwenden. Tailscale erklärt, dass Tailnet Lock und die Gerätefreigabe gegenseitig ausschließend sind. Wenn Sie eine Funktion aktivieren, verzichten Sie auf die andere.
• Es handelt sich um Trust on First Use (TOFU). Die Ersteinrichtung läuft weiterhin über die Steuerungsebene. Erst nach diesem ersten Schritt verlagert sich der Vertrauensanker in Ihr eigenes Netzwerk.

Tailnet Lock schützt die Mitgliedschaft. Die Verfügbarkeit schützt es nicht. Das Whitepaper bestätigt dies.

Legt eine Relaisverbindung meinen Datenverkehr offen?

Nein. Wenn zwei Geräte einander nicht direkt erreichen können, wird der Datenverkehr über einen DERP-Server (Designated Encrypted Relay for Packets) geleitet. In der Dokumentation von Tailscale wird diese Eigenschaft eindeutig beschrieben: „Da die privaten Tailscale-Schlüssel das lokale Gerät, auf dem sie erzeugt wurden, nie verlassen, kann ein DERP-Server Ihren Datenverkehr nicht entschlüsseln. Ein DERP-Server leitet bereits verschlüsselten Datenverkehr blind von einem Gerät an ein anderes weiter.“

Ein Relais verringert jedoch die Geschwindigkeit und sieht Metadaten: zwei verschlüsselte Endpunkte sowie den Zeitpunkt und das Volumen des Datenverkehrs zwischen ihnen. Ermitteln Sie, welche Verbindungsart tatsächlich verwendet wird:

tailscale status
tailscale netcheck

tailscale status kennzeichnet jeden Peer entweder als direkt verbunden, dargestellt als direct 203.0.113.10:41641, oder als über ein Relais verbunden, dargestellt als relay gefolgt vom Namen des Relais und den Byte-Zählern. Wenn ein Peer dauerhaft ein Relais verwendet, konnten die beiden Enden keinen direkten Pfad aufbauen. Ursache ist meist, dass UDP an einer Stelle blockiert wird oder dass sich beide Seiten hinter striktem NAT (Network Address Translation) befinden. tailscale netcheck zeigt, ob UDP von diesem Rechner aus grundsätzlich funktioniert, wie das NAT die Ports abbildet und welche Latenz zu den nächstgelegenen Relais besteht. Daran erkennen Sie, welche dieser beiden Ursachen vorliegt. Wenn ein Peer bereits direkt verbunden ist und der Durchsatz trotzdem enttäuscht, ist das Relais nicht die Ursache. Meist ist dann eine nicht übereinstimmende Pfad-MTU für langsames WireGuard verantwortlich.

Ein Exit Node verlagert Ihren Ausgangspunkt, entfernt ihn aber nicht

Ein Exit Node leitet den gesamten öffentlichen Internetverkehr eines Geräts über ein anderes Gerät im Tailnet. Dafür verwendet er die Standardrouten 0.0.0.0/0 und ::/0. Unter Linux kündigt die Maschine, die diesen Dienst anbietet, die Route an. Jeder Client muss die Nutzung ausdrücklich aktivieren:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Ein Exit Node muss in der Admin-Konsole von einem Owner, Admin oder Network admin genehmigt werden. Außerdem muss Ihre Policy autogroup:internet gewähren, bevor ein Client ihn verwenden darf. Beide Schritte sind bewusst vorgesehen: Eine nicht genehmigte Maschine kann nicht unbemerkt zum Ausgang für Ihr gesamtes Tailnet werden. Dieselbe Genehmigung gilt für Subnetzrouten. Eine Maschine, die einen privaten Bereich ankündigt, bleibt daher inaktiv, bis ein Admin ihn akzeptiert. Das ist die erste Hürde beim Ankündigen eines privaten Netzwerks in Ihrem Tailnet über einen VPS.

Nun zur Vertrauensfrage. Der Datenverkehr wird von Ihrem Laptop bis zum Exit Node verschlüsselt. Danach verlässt er diese Maschine als gewöhnlicher Internetverkehr und verwendet deren IP-Adresse. Der Betreiber des Exit Node sieht daher Ihre Zieladressen. Das gilt auch für den Hostinganbieter dieser Maschine und sein Upstream-Netzwerk. Sie verlagern den Beobachtungspunkt, anstatt ihn zu entfernen. Das ist sinnvoll, wenn Sie die Gegenstelle kontrollieren. Genau dafür spricht das Betreiben eines eigenen Exit Node auf einem VPS. Wenn Sie die Gegenstelle nicht kontrollieren, ist es hingegen eine schlechte Lösung.

Die Standardrichtlinie erstellt ein flaches Netzwerk

Ein neues Tailnet wird mit einer permissiven Konfiguration bereitgestellt. In der Dokumentation zur Zugriffskontrolle von Tailscale heißt es, dass die Standardrichtliniendatei „die Kommunikation zwischen allen Geräten innerhalb des Tailnets ermöglicht“. Jedes Gerät kann jedes andere Gerät über jeden Port erreichen. Das ist ein flaches Netzwerk. Sie haben es in den Tunnel verlagert. Das schützt vor externen Angreifern, aber nicht vor einem infizierten Laptop.

Verschärfen Sie die Konfiguration in der Tailnet-Richtliniendatei. Diese unterstützt Zugriffskontrolllisten (ACLs) oder die neueren Grants. Beide werden in einem JSON-Dialekt mit Unterstützung für Kommentare geschrieben:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Mit dieser Richtlinie kann eine Gruppe SSH auf Produktionsservern erreichen. Mitglieder können außerdem einen Exit Node verwenden. Alles andere wird durch das Weglassen entsprechender Regeln verweigert. Tailscale führt auf, welche Ziele für Regeln in welchem Tarif verfügbar sind. Prüfen Sie das, bevor Sie Ihre Konfiguration auf Tags oder Autogroups auslegen, und lesen Sie nach, was der kostenlose Tarif tatsächlich umfasst. Für ein Gerät, das niemals eingehende Verbindungen akzeptieren soll, beispielsweise ein privates Smartphone, blockiert tailscale set --shields-up diese am Client.

Was sich durch das Self-Hosting der Steuerungsebene mit Headscale ändert

Headscale ist „eine quelloffene, selbst gehostete Implementierung des Tailscale-Steuerungsservers“. Die README beschreibt den Umfang sachlich: „Die Implementierung deckt einen begrenzten Umfang ab, ein einziges Tailscale-Netzwerk (Tailnet), das für den persönlichen Gebrauch oder eine kleine Open-Source-Organisation geeignet ist.“ Die Funktionsliste umfasst ACLs und Grants, Subnetzrouter, Exit-Nodes, einen integrierten DERP-Server, Tailscale SSH und Taildrop. Wenn dieser begrenzte Umfang das entscheidende Problem ist, ist NetBird das andere Mesh, das eine selbst hostbare Steuerungsebene anbietet. Wenn Sie den NetBird-Server auf Ihrem eigenen VPS betreiben, verlagern Sie dieselbe Entscheidung über die Geräteaufnahme auf Hardware, die Ihnen gehört.

Dadurch ändert sich die Identität der Partei, die einen nicht autorisierten Node aufnehmen könnte. Bei Headscale liegen das Schlüsselverzeichnis und die Richtlinien auf Ihrem Server. Kein Dritter besitzt jemals die Liste der öffentlichen Geräteschlüssel. Kein Dritter kann gezwungen werden, einen Schlüssel herauszugeben oder einen Schlüssel zu signieren.

Die Datenebene ändert sich nicht. Es handelt sich weiterhin um WireGuard mit derselben Ende-zu-Ende-Verschlüsselung und demselben Relay-Fallback, wenn ein direkter Pfad nicht möglich ist. Sie übernehmen außerdem die Aufgaben, die Tailscale bisher erledigt hat: Überwachung der Verfügbarkeit, Einspielen von Patches, Backups und die physische Sicherheit des Servers. Wenn es sich bei diesem Server um einen gemieteten VPS handelt, liegt Letztere nicht unter Ihrer Kontrolle, sondern beruht auf dem Versprechen eines Dritten. Der Hypervisor kann den Arbeitsspeicher Ihres Gastsystems und damit auch das Schlüsselverzeichnis lesen, sofern die Hardware keine verschlüsselte, attestierbare Speicherausstattung unterstützt. Ein kompromittierter Headscale-Host ermöglicht einem Angreifer genau das, was auch ein kompromittierter Koordinationsserver ermöglichen würde: einen Node zu registrieren und Richtlinien zu verteilen. Tailnet lock steht nicht auf der Headscale-Funktionsliste. Die Ausgleichsmaßnahme für dieses spezifische Risiko ist dort daher nicht verfügbar. Auch die Kosten bewegen manche Tailnets in dieselbe Richtung, weil Tailscale pro Benutzer und nicht pro Gerät abrechnet und sich diese Rechnung ändert, sobald ein kleines Team über den kostenlosen Tarif hinauswächst. Wenn die Frage nach der Kontrolle für Sie entscheidend ist, führt das Self-Hosting der Control Plane mit Headscale durch die Einrichtung.

Wovor Tailscale schützt

• Öffentliche Listening-Ports. Ein Dienst, der an eine Tailnet-Adresse gebunden ist, ist aus dem Internet nicht erreichbar. Scanner, die jeden VPS auf Port 22 prüfen, sehen ihn daher nicht. Die Ausnahme müssen Sie selbst aktivieren. Funnel veröffentlicht einen Tailnet-Dienst absichtlich im offenen Internet. Deshalb sollten Sie wissen, wo Serve endet und Funnel beginnt, bevor Sie einen der beiden Befehle ausführen. Lassen Sie die Host-Firewall trotzdem aktiviert. Ein veröffentlichter Docker-Port erstellt eigene Regeln und umgeht ufw auf der öffentlichen Schnittstelle.
• Passwortversuche gegen exponierte Anmeldedienste. Wenn der Port nur innerhalb des Tunnels antwortet, gibt es kein Ziel für automatisierte Passwortversuche. Das ist sicherer, als einen offenen Port nur durch Rate Limiting zu begrenzen. fail2ban auf Ubuntu 24.04 sollte trotzdem auf jedem System laufen, das öffentlich erreichbar bleiben muss.
• Nicht vertrauenswürdige Netzwerke auf dem Übertragungsweg. Der Netzwerkverkehr zwischen Ihren Rechnern ist über ein Café-Netzwerk oder ein gemeinsam genutztes Provider-LAN Ende zu Ende verschlüsselt. Das gilt auch, wenn der Verkehr über ein Relay weitergeleitet wird.
• Manuelle Verteilung kryptografischer Schlüssel. Jeder Peer, den Sie von Hand in eine WireGuard-Konfiguration eintragen, kann zu einer wiederverwendeten Adresse oder einem falsch eingefügten Schlüssel führen. Das Mesh übernimmt diese Verwaltung für Sie. Darin liegt der wichtigste praktische Unterschied zwischen WireGuard und Tailscale.

Wogegen Tailscale nicht schützt

• Ein kompromittierter Endpunkt. Das Tailnet vertraut den Geräten. Malware auf einem zugelassenen Laptop erhält den Tunnel, die Tailnet-Adressen und alle Zugriffsrechte, die Ihre Richtlinie diesem Benutzer gewährt. Dies ist die größte Lücke. Kein VPN kann sie schließen.
• Ein böswilliger oder nachlässiger Administrator. Jeder, der die Policy-Datei bearbeiten kann, kann sich selbst Zugriff auf beliebige Ressourcen gewähren. Das gilt auch für jeden, der das Identitätskonto eines Owners übernimmt. Prüfen Sie Policy-Änderungen genauso wie Code-Änderungen.
• Verkehrsanalyse. Ihr ISP (Internetdienstanbieter) sieht verschlüsselte UDP-Daten, die zu einem Endpunkt fließen, sowie Zeitpunkte und Datenmengen. Die Flow-Logs von Tailscale zeigen, welche Peers miteinander kommuniziert haben und wann. Die Inhalte sieht keiner von beiden. Die Tatsache einer Verbindung bleibt jedoch sichtbar. Lesen Sie daher wie sich Tor und ein VPN unterscheiden, bevor Sie ein Tool für diese Aufgabe auswählen.
• Ein Gerät, das Sie bereits verloren haben. Der Ablauf eines Schlüssels ist mit dem Standardwert von 180 Tagen nur eine langsame Schutzmaßnahme. Das Entfernen des Geräts in der Admin-Konsole wirkt sofort. Machen Sie sich daher mit dieser Schaltfläche vertraut, bevor Sie sie benötigen.

Prüfen Sie Ihr eigenes Tailnet

1. Führen Sie tailscale status auf einem Gerät aus und lesen Sie die Peer-Liste. Ein Rechner, den Sie nicht zuordnen können, ist genau die Situation, die durch die Gerätefreigabe verhindert werden soll.
2. Führen Sie tailscale lock status aus, um zu prüfen, ob Tailnet Lock aktiviert ist. Entscheiden Sie anschließend, ob sich das Signieren jedes neuen Geräts für Ihr Tailnet lohnt.
3. Öffnen Sie die Administrationskonsole. Notieren Sie jedes Gerät, bei dem der Ablauf der Schlüssel deaktiviert ist, sowie jeden wiederverwendbaren Authentifizierungsschlüssel, der noch vorhanden ist. Beides sind Zugangsdaten ohne zeitliche Begrenzung.
4. Lesen Sie Ihre Richtliniendatei. Wenn sie noch dem Standard entspricht, kann jedes Gerät jedes andere Gerät über jeden Port erreichen. Ein infizierter Laptop erreicht dann alle Geräte.

Tailscale genießt seinen Ruf in der Datenebene. Das Design verhindert dort, dass der Betreiber Ihren Netzwerkverkehr lesen kann. Übernehmen Sie diese Aussage so, wie sie vom Anbieter dokumentiert wird. Prüfen Sie anschließend die Bereiche, für die Sie verantwortlich sind: die Identitätskonten, die Einstellung für Gerätefreigaben, die Liste der Ablaufzeiten und die Richtliniendatei. Auf der Sicherheitsseite von Tailscale werden eine SOC 2 Type II-Zertifizierung und laufende Sicherheitsarbeiten mit Latacora genannt. Das belegt den Sicherheitsprozess des Anbieters, sagt aber nichts über Ihre Konfiguration aus.

FAQ

Kann Tailscale meinen Datenverkehr lesen?

Nein. Der Datenverkehr wird mit WireGuard-Schlüsseln verschlüsselt, die auf Ihren Geräten erzeugt werden. Auf der Tailscale-Sicherheitsseite steht: „Private keys never leave the device. All traffic is end-to-end encrypted, always.“ Das gilt auch für Verbindungen, die auf ein DERP-Relay zurückfallen. Das Relay „blindly forwards already-encrypted traffic from one device to another“ und besitzt keinen Schlüssel, mit dem es den Datenverkehr entschlüsseln könnte. Die Infrastruktur von Tailscale sieht jedoch Metadaten: welche Geräte existieren und welche Geräte wann miteinander verbunden waren.

Was könnte ein kompromittierter Tailscale-Koordinationsserver tatsächlich tun?

Er könnte einen Node registrieren. Die Ankündigung von Tailscales tailnet lock beschreibt das Risiko eines heimlich hinzugefügten Nodes, der „send or receive traffic to your existing nodes“ könnte. Eine Verschlüsselung hilft in diesem Fall nicht, „because the peer itself would be malicious“. Ein kompromittiertes Control Plane könnte außerdem eine Policy verteilen, die ändert, welche Ziele Ihre Geräte erreichen. Das Whitepaper zu tailnet lock weist darauf hin, dass es die Konnektivität auch dadurch unterbrechen könnte, dass neue Node-Schlüssel nicht verteilt werden. Den Datenverkehr zwischen Ihren vorhandenen Geräten könnte es jedoch nicht entschlüsseln, weil es deren private keys nie besessen hat.

Verbirgt ein Exit-Node mein Surfverhalten vor meinem ISP?

Er verbirgt die Ziele vor dem Netzwerk, in dem Sie sich befinden, einschließlich des ISP Ihres Zuhauses oder Cafés. Ihr Gerät sendet den gesamten Datenverkehr als verschlüsselten Datenverkehr an den Exit-Node. Sie bleiben dadurch nicht anonym. Stattdessen sieht der Exit-Node diese Ziele. Das gilt auch für dessen Hosting-Provider und das übergeordnete Netzwerk. Die von Ihnen besuchten Websites sehen die IP-Adresse des Exit-Nodes. Sie wählen damit einen anderen Beobachter. Wählen Sie daher einen, dem Sie tatsächlich vertrauen.

Ist Headscale sicherer als der Koordinationsserver von Tailscale?

Das ist eine andere Vertrauensentscheidung und nicht grundsätzlich eine sicherere Lösung. Mit Headscale verwalten Sie das Schlüsselverzeichnis und die Policy selbst. Dadurch kann keine externe Partei gezwungen werden, ein Gerät in Ihr tailnet aufzunehmen. Sie müssen diesen Server jedoch selbst betreiben. Dazu gehören Patching, Verfügbarkeit, Backups und die Absicherung des Hosts. Ein kompromittierter Headscale-Host bietet einem Angreifer dieselbe Möglichkeit zur Registrierung wie ein kompromittierter Koordinationsserver. tailnet lock gehört außerdem nicht zum Funktionsumfang von Headscale. Schützen Sie diesen Host daher entsprechend.

Benötige ich auf einem VPS in meinem tailnet weiterhin eine Firewall?

Ja. Die öffentliche Netzwerkschnittstelle ist weiterhin vorhanden. Jeder Dienst, der an 0.0.0.0 gebunden ist, bleibt aus dem Internet erreichbar, unabhängig davon, ob Tailscale läuft. Binden Sie Dienste an die tailnet-Adresse. Verwenden Sie auf der öffentlichen Schnittstelle eine standardmäßige Deny-Regel. Prüfen Sie außerdem die veröffentlichten Container-Ports. Docker fügt eigene Regeln ein und kann einen Port nach außen öffnen, den Sie für geschlossen hielten.