Ist Tailscale sicher? Das Vertrauensmodell erklärt

Ist Tailscale sicher? Die kurze Antwort

Ist Tailscale sicher? Für den Aspekt, über den sich die meisten Gedanken machen, lautet die Antwort: ja. Der Koordinationsserver, der Ihr Tailnet verwaltet, besitzt niemals die privaten Schlüssel, mit denen Ihr Datenverkehr verschlüsselt wird. Er kann daher nicht lesen, was Ihre Geräte untereinander senden. Auf der Sicherheitsseite von Tailscale steht es direkt: „Private Schlüssel verlassen niemals das Gerät. Der gesamte Datenverkehr ist immer Ende-zu-Ende-verschlüsselt.“ Die entscheidende Frage ist eine andere. Ein kompromittierter Koordinationsserver oder ein Server, zu dessen Herausgabe er durch eine gerichtliche Anordnung verpflichtet wird, muss Ihre Pakete nicht lesen können. Er entscheidet, welchen öffentlichen Schlüsseln Ihre Geräte vertrauen. Dadurch könnte er ein Gerät in Ihr Tailnet aufnehmen, 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. In jedem folgenden Abschnitt wird eine Partei genannt, der Sie vertrauen müssen. Außerdem wird beschrieben, was diese Partei tatsächlich tun kann, und welche Kontrolle ihre Möglichkeiten begrenzt. Falls das Produkt für Sie neu ist, beginnen Sie mit einer Erklärung zu Tailscale und zur Funktionsweise seines Mesh-Netzwerks.

Die Control Plane und die Data Plane sind getrennt

Tailscale ist ein auf WireGuard basierendes Mesh-VPN (Virtual Private Network), also auf demselben Protokoll, das Sie auch manuell auf einem selbst gehosteten WireGuard-VPS konfigurieren würden. Jedes Gerät erzeugt sein eigenes WireGuard-Schlüsselpaar lokal. Im Beitrag how it works bezeichnet Tailscale den Koordinationsserver als „a shared drop box for public keys“ und erklärt: „The private key never, ever leaves its node.“

Die Data Plane besteht aus dem verschlüsselten Netzwerkverkehr zwischen Ihren Geräten. Dieser läuft von Gerät zu Gerät und, sofern das Netzwerk dies zulässt, direkt. Die Control Plane umfasst alles andere: die Geräte, die zum Tailnet gehören, die Zuordnung öffentlicher Schlüssel zu Geräten, die Zugriffsrichtlinie, die DNS-Einstellungen und die Relay-Liste. Tailscale betreibt die Control Plane als gehosteten Dienst. Sie betreiben die Data Plane 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 Data Plane. Die Mitgliedschaft wird von der Control Plane festgelegt. Keine noch so starke Verschlüsselung legt fest, 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 niemals hochgeladen. Es gibt daher nichts, was ein Angreifer übernehmen oder abgreifen könnte, um den Tunnel zu öffnen. Das gilt auch für weitergeleiteten Datenverkehr, auf den weiter unten noch 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 „use a secretly-added node to send or receive traffic to your existing nodes“ und dann „it wouldn't matter that the traffic is encrypted because the peer itself would be malicious“. 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 liegt in der Control Plane und wird an die Knoten verteilt. Das Whitepaper zu tailnet lock von Tailscale besagt, dass tailnet lock „does not prevent a compromised control plane from breaking connectivity in your network, such as by failing to distribute new node keys, or distributing an access control policy which denies access to all nodes.“

Er sieht in jedem Fall Verbindungsmetadaten. Die Netzwerkflussprotokolle von Tailscale erfassen für jede Verbindung zwischen Maschinen die Ereignisse zum Öffnen und Schließen. In der Dokumentation steht, dass diese Protokolle „strictly do not contain any information about client operations or contents of network traffic“. Die Control Plane kann also erkennen, welche Ihrer Geräte miteinander kommuniziert haben und wann. Sie weiß nicht, was diese Geräte ausgetauscht haben.

Nur ein Punkt dieser Liste betrifft die Verschlüsselung. Bei den anderen Punkten 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.

Ihr Identity Provider ist die Vertrauensbasis für das Tailnet

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 Identity Provider (IdP) delegiert: Apple, Google, GitHub, Microsoft, Okta, OneLogin oder einen benutzerdefinierten OpenID-Connect-Provider.

Das ist als Sicherheitshinweis zu verstehen. 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 per Phishing übernommenes IdP-Konto ist auch ein Tailnet-Konto. Der Angreifer muss WireGuard nicht angreifen. Er fügt ein Gerät hinzu und erhält dadurch 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ätefreigabe und Schlüsselablauf. Tailnet lock ist eine dritte Kontrolle. Sie schützt die Steuerungsebene und nicht das Konto.

Gerätefreigabe: Nichts wird verbunden, bevor eine Person zustimmt

In der Tailscale-Dokumentation wird die Gerätefreigabe als Funktion beschrieben, mit der „Tailscale-Netzwerkadministratoren neue Geräte prüfen und freigeben können, bevor sie dem Tailscale-Netzwerk beitreten“. Ein Owner, Admin oder IT admin kann die Freigabe erteilen. Bis jemand tätig wird, zeigt ein neues Gerät auf der Seite Machines das Kennzeichen „Needs approval“.

Aktivieren Sie diese Funktion, verändert sich das Szenario eines gestohlenen Kontos. Der Angreifer meldet sich an, das Gerät wird registriert und wartet anschließend, ohne auf irgendetwas zugreifen zu können. Gleichzeitig weist ein Kennzeichen in der Administrationskonsole darauf hin, dass ein unbekanntes Gerät beitreten möchte. Automatisierung funktioniert weiterhin, weil Sie einen auth key beim Erstellen als vorab freigegeben markieren können. Geräte lassen sich außerdem über die API freigeben.

Auth keys sind der andere Zugangsweg und müssen daher wie Zugangsdaten behandelt werden. Tailscale weist in der Dokumentation ausdrücklich auf die riskante Variante hin: „Seien Sie bei wiederverwendbaren Schlüsseln sehr vorsichtig. Sie können bei einem Diebstahl sehr gefährlich sein. Bewahren Sie sie am besten in einem speziell dafür entwickelten Key-Vault-Produkt auf.“ Im August 2026 reicht die dokumentierte Gültigkeitsdauer eines Schlüssels von 1 bis 90 Tagen. Ohne angegebene Gültigkeitsdauer gilt standardmäßig das Maximum von 90 Tagen. Bevorzugen Sie einmalig verwendbare Schlüssel. Markieren Sie Schlüssel für Geräte, die nur vorübergehend vorhanden sind, als ephemeral. Verschlüsseln Sie wiederverwendbare Schlüssel mit Ansible Vault oder speichern Sie sie in einem Secrets Manager, statt sie in einem Shell-Skript abzulegen.

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 heißt es: „By default, new domains are set with an expiry period of 180 days“. Außerdem heißt es: „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 Vorgang mit geöffneter Konsolensitzung oder über einen zweiten Zugangsweg zum Rechner aus. Sie unterbrechen gleich das Netzwerk, das 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 den Vorgang überwacht. Deshalb deaktivieren Administratoren den Schlüsselablauf auf solchen Rechnern. Damit entfernen sie den Timer, der einen gestohlenen Schlüssel schließlich ungültig machen würde. Für einen Server ist ein getaggtes Gerät die bessere Lösung. Ein Tag ordnet den Rechner einer Maschine statt einer Person zu. Dadurch bleibt der Rechner erhalten, wenn diese Person das Unternehmen verlässt. Unabhängig von Ihrer Entscheidung sollten Sie dokumentieren, auf welchen Rechnern der Ablauf 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 erklärt den Mechanismus: „Wenn ein neuer Knoten dem Tailnet beitritt, benötigt sein öffentlicher Knotenschlüssel eine Signatur von einem Tailnet-Lock-Schlüssel. 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 Control Plane 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 Ihre signierenden Knoten fest. Tailscale erfordert 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 erheblichen betrieblichen Aufwand: Um ein Telefon hinzuzufügen, müssen Sie einen Befehl auf einem Laptop ausführen.

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

• Wenn Sie das Deaktivierungsgeheimnis verlieren, gibt es keine Wiederherstellung. In der Dokumentation heißt es: „Wenn Sie Ihre Deaktivierungsgeheimnisse verlieren und keines davon an den Tailscale-Support übermittelt haben, kann das Tailnet nicht wiederhergestellt werden.“
• Der Signaturschlüssel befindet sich auf einem Gerät in Ihrem Besitz und übernimmt daher dessen Sicherheitsniveau. Die Dokumentation formuliert es ausdrücklich: „Wenn das Gerät kompromittiert wird, kann der Schlüssel erlangt werden.“
• Sie können nicht beide Kontrollen gleichzeitig verwenden. Tailscale erklärt, dass Tailnet Lock und die Gerätegenehmigung sich gegenseitig ausschließen. Wenn Sie die eine Funktion aktivieren, verzichten Sie auf die andere.
• Es handelt sich um Trust on First Use (TOFU). Die Ersteinrichtung läuft weiterhin über die Control Plane. 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 weitergeleitete Verbindung meinen Netzwerkverkehr offen?

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

Eine Weiterleitung kostet Sie dennoch Geschwindigkeit, und der DERP-Server sieht Metadaten: zwei verschlüsselte Endpunkte sowie den Zeitpunkt und das Volumen der zwischen ihnen übertragenen Daten. Ermitteln Sie, welche Verbindungsart tatsächlich verwendet wird:

tailscale status
tailscale netcheck

tailscale status kennzeichnet jeden Peer entweder als direkt, dargestellt durch direct 203.0.113.10:41641, oder als weitergeleitet, dargestellt durch relay gefolgt vom Namen des Relays und den Byte-Zählern. Wenn ein Peer dauerhaft ein Relay verwendet, konnten die beiden Enden keinen direkten Pfad aufbauen. Ursache ist normalerweise, dass UDP an einer Stelle blockiert wird oder dass sich beide Seiten hinter einem strikten 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 Relays besteht. Damit können Sie feststellen, welche dieser beiden Ursachen vorliegt.

Ein Exit Node verlagert Ihren ausgehenden Datenverkehr, entfernt ihn aber nicht

Ein Exit Node leitet den gesamten öffentlichen Internetverkehr eines Geräts über ein anderes Gerät im Tailnet weiter. Dazu verwendet er die Standardrouten 0.0.0.0/0 und ::/0. Unter Linux kündigt die Maschine, die diesen Dienst anbietet, den Exit Node an. Jeder Client muss ihn 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 erlauben, bevor ein Client ihn verwenden kann. Beide Schritte sind bewusst erforderlich: Eine nicht genehmigte Maschine kann nicht unbemerkt zum Ausgang für Ihr gesamtes Tailnet werden.

Damit stellt sich die Vertrauensfrage. Der Datenverkehr wird von Ihrem Laptop bis zum Exit Node verschlüsselt. Danach verlässt er diese Maschine als normaler Internetverkehr und verwendet dabei deren IP-Adresse. Der Betreiber des Exit Nodes sieht daher Ihre Zieladressen. Dasselbe gilt für den Hosting-Provider dieser Maschine und dessen übergeordnetes Netzwerk. Sie haben den Beobachtungspunkt verlagert, nicht entfernt. Das ist ein sinnvoller Kompromiss, wenn Sie das entfernte Ende kontrollieren. Genau das ist das Argument für einen eigenen Exit Node auf einem VPS betreiben. Wenn Sie das entfernte Ende nicht kontrollieren, ist es ein schlechter Kompromiss.

Die Standardrichtlinie verwendet ein flaches Netzwerk

Ein neues Tailnet wird mit einer permissiven Konfiguration ausgeliefert. In der Dokumentation zur Zugriffskontrolle von Tailscale steht, dass die Standardrichtliniendatei „die Kommunikation zwischen allen Geräten innerhalb des Tailnets aktiviert“. 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 akzeptiert Access Control Lists (ACLs) oder die neueren Grants. Beide verwenden eine JSON-Dialekt, der Kommentare erlaubt:

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

Diese Richtlinie erlaubt einer Gruppe den Zugriff auf SSH auf Produktionsserver und ermöglicht Mitgliedern die Verwendung eines Exit-Nodes. Alles andere wird durch das Weglassen entsprechender Regeln verweigert. Tailscale führt auf, welche Regelziele in welchem Tarif verfügbar sind. Prüfen Sie das, bevor Sie Ihre Konfiguration auf Tags oder Autogroups auslegen. Lesen Sie außerdem nach, was der kostenlose Tarif tatsächlich umfasst. Für ein Gerät, das niemals eingehende Verbindungen akzeptieren soll, beispielsweise ein persönliches Smartphone, blockiert tailscale set --shields-up diese am Client.

Was sich ändert, wenn Sie die Control Plane mit Headscale selbst hosten

Headscale ist „eine Open-Source-, selbst gehostete Implementierung des Tailscale-Control-Servers“. Die README grenzt den Umfang sachlich ein: „Die Implementierung deckt einen begrenzten Umfang ab: ein einzelnes Tailscale-Netzwerk (Tailnet), geeignet für die private Nutzung oder eine kleine Open-Source-Organisation.“ Die Funktionsliste umfasst ACLs und Grants, Subnet-Router, Exit-Nodes, einen integrierten DERP-Server, Tailscale SSH und Taildrop. Wenn dieser begrenzte Umfang das entscheidende Problem ist, ist NetBird das andere Mesh mit einer selbst hostbaren Control Plane. Wenn Sie den NetBird-Server auf Ihrem eigenen VPS betreiben, verlagern Sie dieselbe Entscheidung zur Geräteaufnahme auf Hardware, die Ihnen gehört.

Geändert wird die Identität der Partei, die einen nicht autorisierten Node aufnehmen könnte. Bei Headscale liegen das Schlüsselverzeichnis und die Richtlinie 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.

Nicht geändert wird die Data Plane. Sie verwendet weiterhin WireGuard mit derselben Ende-zu-Ende-Verschlüsselung sowie denselben Relay-Fallback, wenn kein direkter Pfad möglich ist. Außerdem übernehmen Sie die Aufgaben, die Tailscale bisher erledigt hat: Verfügbarkeitsüberwachung, Patchen, Backups und die physische Sicherheit des Servers. Ein kompromittierter Headscale-Host gibt einem Angreifer genau die Möglichkeiten, die auch ein kompromittierter Coordination Server bieten würde. Der Angreifer kann einen Node aufnehmen und Richtlinien verteilen. Tailnet Lock steht nicht auf der Headscale-Funktionsliste. Die ausgleichende Maßnahme für dieses konkrete Risiko ist dort daher nicht verfügbar. Wenn die Frage nach dem Eigentum für Sie entscheidend ist, erklärt die Selbstverwaltung der Control Plane mit Headscale die Einrichtung.

Wovor Tailscale schützt

• Öffentlich erreichbare 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.
• Passwort-Raten 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 per Rate-Limiting zu begrenzen. fail2ban auf Ubuntu 24.04 sollten Sie trotzdem auf allen Systemen einsetzen, die öffentlich erreichbar bleiben müssen.
• Nicht vertrauenswürdige Netzwerke auf dem Übertragungsweg. Der Datenverkehr zwischen Ihren Rechnern ist über ein Café-Netzwerk oder das gemeinsam genutzte LAN eines Providers Ende-zu-Ende verschlüsselt. Auch bei einer Weiterleitung bleibt er verschlüsselt.
• Manuelle Verteilung von Schlüsseln. Jeder Peer, den Sie manuell 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 bei WireGuard und Tailscale.

Was 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 Berechtigungen, 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 Richtliniendatei bearbeiten kann, kann sich selbst Zugriff auf beliebige Ressourcen gewähren. Dasselbe gilt für jeden, der das Identitätskonto eines Owners übernimmt. Prüfen Sie Richtlinienänderungen so sorgfältig wie Code.
• Verkehrsanalyse. Ihr ISP (Internetdienstanbieter) sieht verschlüsselten UDP-Verkehr zu einem Endpunkt sowie Zeitpunkte und Datenvolumen. Die Tailscale-Flow-Logs zeigen, welche Peers miteinander kommuniziert haben und wann. Die Inhalte bleiben in beiden Fällen verborgen. Die Tatsache einer Verbindung wird jedoch nicht verborgen. Lesen Sie daher wie sich Tor und ein VPN unterscheiden, bevor Sie für diese Aufgabe ein Werkzeug auswählen.
• Ein Gerät, das Sie bereits verloren haben. Der Schlüsselablauf ist bei einem Standardwert von 180 Tagen nur eine langsame Rückfallebene. Das Entfernen des Geräts in der Administrationskonsole ist die schnelle Maßnahme. Sie sollten daher wissen, wo sich diese Schaltfläche befindet, 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. Eine Maschine, die Sie nicht zuordnen können, ist genau die Situation, die durch die Gerätegenehmigung 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 der Aufwand lohnt, jedes neue Gerät für Ihr tailnet zu signieren.
3. Öffnen Sie die Administrationskonsole. Notieren Sie jedes Gerät, für das der Ablauf des Schlüssels deaktiviert ist, sowie jeden noch vorhandenen wiederverwendbaren Authentifizierungsschlüssel. Beides sind Zugangsdaten ohne zeitliche Begrenzung.
4. Lesen Sie Ihre Policy-Datei. Wenn sie noch den Standardwert enthält, 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, dass der Betreiber Ihren Datenverkehr lesen kann. Übernehmen Sie diese Aussage so, wie sie der Anbieter dokumentiert. Prüfen Sie anschließend die Bereiche, für die Sie verantwortlich sind: die Identitätskonten, die Genehmigungseinstellung, die Liste der Ablaufdaten und die Policy-Datei. Auf der Sicherheitsseite von Tailscale werden eine SOC 2 Type II-Zertifizierung und die laufende Sicherheitsarbeit 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 ist 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 ausweichen. 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 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 Tailscale zu tailnet lock beschreibt das Risiko eines heimlich hinzugefügten Nodes, der „send or receive traffic to your existing nodes“ könnte. Die Verschlüsselung hilft in diesem Fall nicht, „because the peer itself would be malicious“. Eine kompromittierte Control Plane könnte außerdem eine Policy verteilen, die ändert, welche Ziele Ihre Geräte erreichen. Im Whitepaper zu tailnet lock wird außerdem erwähnt, dass sie die Konnektivität unterbrechen könnte, indem sie neue Node-Schlüssel nicht verteilt. Den Datenverkehr zwischen Ihren vorhandenen Geräten könnte sie jedoch nicht entschlüsseln, weil sie deren privaten Schlüssel 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 ISPs Ihres Heimanschlusses oder Cafés. Ihr Gerät sendet den gesamten Datenverkehr als verschlüsselten Datenverkehr an den Exit Node. Sie bleiben dadurch nicht anonym. Der Exit Node sieht stattdessen 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 Tailscale-Koordinationsserver?

Das ist eine andere Vertrauensentscheidung, nicht automatisch eine sicherere Lösung. Mit Headscale verwalten Sie das Schlüsselverzeichnis und die Policy selbst. Dadurch kann keine externe Partei dazu 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 gibt einem Angreifer dieselbe Möglichkeit zur Registrierung von Geräten wie ein kompromittierter Koordinationsserver. Außerdem gehört tailnet lock nicht zum Funktionsumfang von Headscale. Schützen Sie den Host 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-Policy. 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.