Was ist Tailscale und wie funktioniert es?

Was ist Tailscale?

Tailscale ist ein VPN, das Ihre Computer direkt miteinander verbindet, anstatt den gesamten Datenverkehr über ein von Ihnen betriebenes Gateway zu leiten. Auf jedem Knoten läuft WireGuard. Dadurch werden die Pakete verschlüsselt von einem Server zum anderen übertragen, und niemand auf dem Übertragungsweg kann sie lesen. Ein gehosteter Koordinationsserver stellt die Verbindungen zwischen den Knoten her. Er speichert und verteilt öffentliche Schlüssel und teilt jedem Knoten mit, wo sich die anderen befinden. Außerdem verteilt er die von Ihnen festgelegten Zugriffsregeln.

Diese Trennung bildet das gesamte Design. Die Datenebene ist Peer-to-Peer und zwischen den Knoten verschlüsselt. Die Steuerungsebene ist ein Dienst, den Tailscale für Sie betreibt. Jede wichtige Frage zu Tailscale, auch die unangenehmen Fragen zum Vertrauen, ergibt sich aus diesen beiden Tatsachen. Wenn Sie bereits ein WireGuard-VPN manuell auf einem VPS eingerichtet haben, ist Tailscale derselbe Tunnel, wobei die Schlüsselverteilung und die Firewall-Durchquerung für Sie übernommen werden.

Wie funktioniert Tailscale?

Ihr privates Netzwerk aus Knoten wird als Tailnet bezeichnet. Ob Sie eine weitere Person in Ihr Tailnet einladen oder nur ein einzelnes Gerät mit ihr teilen sollten, erklärt der Überblick darüber, was ein Tailnet umfasst. Wenn sich ein Rechner einem Tailnet anschließt, geschehen vier Dinge.

1. Der tailscaled-Daemon startet, erzeugt ein WireGuard-Schlüsselpaar und speichert seinen Zustand in /var/lib/tailscale/tailscaled.state. Der private Schlüssel bleibt auf diesem Rechner. Tailscale formuliert es eindeutig: „Der private Schlüssel verlässt seinen Knoten niemals.“
2. Der Knoten meldet sich beim Koordinationsserver an und lädt seinen öffentlichen Schlüssel sowie die Adressen hoch, unter denen er vermutlich erreichbar ist. Tailscale beschreibt diesen Server als „gemeinsames Ablagefach für öffentliche Schlüssel“.
3. Der Koordinationsserver sendet eine Netzwerkübersicht (Network Map) zurück: den öffentlichen Schlüssel, die Tailnet-Adresse, den Rechnernamen und die möglichen Endpunkte jedes Knotens, den dieser Knoten erreichen darf.
4. Jedes Knotenpaar versucht anschließend, direkt einen WireGuard-Tunnel zwischen sich aufzubauen. Wenn das fehlschlägt, leiten die Knoten die Pakete stattdessen über ein Relay weiter.

Jeder Knoten erhält eine stabile Adresse aus 100.64.0.0/10, dem Carrier-Grade-NAT-Bereich von 100.64.0.0 bis 100.127.255.255. Tailscale verwendet diesen Bereich, weil er für Provider-Infrastruktur reserviert ist und daher nur selten mit den privaten Adressen kollidiert, die Ihre Server bereits verwenden. Unter Linux erscheint der Tunnel als Schnittstelle mit dem Namen tailscale0.

Die WireGuard-Implementierung befindet sich in tailscaled im Userspace und nicht im Kernelmodul. Deshalb startet Tailscale auch in Container-Virtualisierungen, bei denen sudo modprobe wireguard mit Operation not supported fehlschlägt. Das bedeutet außerdem, dass der maximale Durchsatz auf einem bestimmten Rechner niedriger ist als bei WireGuard im Kernel. Das ist einer der Nachteile, auf die Tailscale gegenüber einfachem WireGuard näher eingeht.

Mit zwei Befehlen sehen Sie, wie der aktuelle Zustand ist.

tailscale ip -4
tailscale status

tailscale status gibt für jeden Knoten eine Zeile aus. Die letzte Spalte ist dabei entscheidend.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct gefolgt von einer Adresse und einem Port bedeutet, dass die beiden Rechner einen Pfad zueinander gefunden haben und der Netzwerkverkehr direkt zwischen den Peers läuft. relay "fra" bedeutet, dass der Netzwerkverkehr über ein Tailscale-Relay in Frankfurt läuft. Ein - bedeutet, dass derzeit keine aktive Sitzung mit diesem Knoten besteht. Das ist normal.

Was der Koordinationsserver sehen kann und was nicht

Der Koordinationsserver speichert öffentliche Schlüssel und Metadaten. Er kennt die Namen Ihrer Rechner, den Benutzer oder Tag, dem jeder Node zugeordnet ist, die Tailnet-Adresse jedes Nodes, die öffentlichen Adressen, unter denen Ihre Nodes erreichbar sind, den Zeitpunkt, an dem jeder Node zuletzt online war, und die von Ihnen erstellte Policy-Datei. Damit verfügt er über eine vollständige Übersicht Ihrer Flotte.

Er besitzt keinen privaten Schlüssel und kann daher den Datenverkehr zwischen zwei Nodes nicht entschlüsseln. Die Verschlüsselung erfolgt Ende-zu-Ende zwischen den WireGuard-Peers. Der Koordinationsserver ist kein Peer.

Er kann jedoch Schlüssel verteilen. Jedem Koordinationsserver, unabhängig davon, ob er gehostet oder selbst betrieben wird, müssen Sie vertrauen, dass er Ihren Nodes mitteilt, welche öffentlichen Schlüssel zum Tailnet gehören. Das ist der entscheidende Punkt im weiter unten beschriebenen Bedrohungsmodell und der Grund, warum Headscale, ein von Ihnen selbst gehosteter Open-Source-Koordinationsserver existiert.

Wie zwei Server hinter unterschiedlichen Firewalls direkt miteinander kommunizieren

NAT (Network Address Translation) ermöglicht es vielen Rechnern, eine öffentliche Adresse gemeinsam zu verwenden. Ihr VPS hat normalerweise eine eigene öffentliche Adresse. Die anderen Rechner, die Sie in das Tailnet aufnehmen möchten, haben jedoch häufig keine eigene öffentliche Adresse. Dazu gehören beispielsweise ein Heimserver, ein Build-Runner in einem Büronetzwerk oder ein Rechner hinter einer Provider-Firewall, die Sie nicht konfigurieren können.

Tailscale ermittelt einen Pfad mithilfe von Verfahren, die auf den Standards STUN (Session Traversal Utilities for NAT) und ICE basieren. Jeder Node sendet ein kleines UDP-Paket an einen STUN-Server und ermittelt dadurch die öffentliche Adresse und den Port, die der Router diesem Socket zugewiesen hat. Beide Nodes melden diese Kandidaten an den Koordinationsserver, der sie an die jeweils andere Seite weitergibt. Anschließend beginnen beide Nodes gleichzeitig, Pakete aneinander zu senden. Jeder Router sieht zuerst ein ausgehendes Paket. Dadurch erstellt er ein Mapping und akzeptiert die Antwort, die von derselben Adresse eintrifft. Keine der beiden Seiten benötigt dafür eine eingehende Firewall-Regel.

Die Ports sind festgelegt. Direkte WireGuard-Tunnel verwenden UDP mit einem Quellport, der standardmäßig auf 41641 gesetzt ist. STUN verwendet UDP über Port 3478 zu den Relay-Servern von Tailscale. Die Steuerungsverbindung und alle weitergeleiteten Daten verwenden HTTPS über TCP 443. In den meisten Fällen müssen Sie keine eingehenden Ports öffnen. In einem Netzwerk mit problematischem NAT erhöht das Zulassen von eingehendem UDP auf Port 41641 jedoch die Wahrscheinlichkeit einer direkten Verbindung.

tailscale netcheck

Lesen Sie zwei Zeilen dieses Berichts. UDP: true bedeutet, dass UDP den Rechner überhaupt verlässt. UDP: false bedeutet, dass jede Verbindung von diesem Node weitergeleitet wird. MappingVariesByDestIP: true bedeutet, dass der Router für jedes Ziel einen anderen öffentlichen Port zuweist. Die oben beschriebene Adressvorhersage funktioniert dadurch nicht, und diese Nodes bleiben normalerweise auf Weiterleitungen angewiesen.

Wenn Tailscale stattdessen ein DERP-Relay verwendet

DERP (designated encrypted relay for packets) ist der Fallback. Tailscale betreibt Relays in vielen Regionen, die über TCP 443 erreichbar sind. Ein Node, der keinen direkten Pfad herstellen kann, sendet seine WireGuard-Pakete über ein Relay.

Die Pakete bleiben verschlüsselt. Tailscale formuliert es eindeutig: "there is never a way for a DERP server to decrypt your traffic. It just blindly forwards already-encrypted traffic from one node to another." Ein Relay sieht den Chiffretext und erkennt, welcher Node mit welchem anderen Node kommuniziert.

Relays übertragen außerdem die ersten Pakete der meisten Verbindungen. Das Ermitteln eines direkten Pfads dauert einen Moment. Daher startet eine Sitzung häufig über ein Relay und wechselt anschließend im laufenden Betrieb, sobald die beiden Nodes einander direkt erreichen können. Sie können diesen Vorgang beobachten.

tailscale ping db-1

Die ersten Antworten kommen über via DERP(fra) zurück. Eine spätere Zeile meldet dann beispielsweise via 198.51.100.24:41641. Diese Änderung zeigt den Wechsel zu einem direkten Tunnel. Wenn sich der Wert nie ändert, führen Sie tailscale netcheck auf beiden Seiten aus. Ein Relay-Pfad funktioniert weiterhin. Er erhöht jedoch die Latenz, weil jedes Paket einen Umweg über einen dritten Rechner nimmt. Wenn Sie keine unterbrochene Verbindung, sondern langsame Übertragungen beobachten, misst warum eine per Relay hergestellte Tailscale-Verbindung deutlich langsamer als eine direkte Verbindung ist den Unterschied und zeigt, wie Sie einen VPS auf einen direkten Pfad bringen.

Einen VPS mit Ihrem Tailnet verbinden

Das Installationsskript unterstützt Ubuntu und Debian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up gibt eine URL aus. Öffnen Sie sie und authentifizieren Sie sich. Danach erscheint der Node in Ihrer Administrationskonsole. Prüfen Sie anschließend, ob der Daemon nach einem Reboot wieder gestartet wird. Dieser Schritt wird häufig übersprungen.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled sollte enabled ausgeben. tailscale status sollte den neuen Node mit seiner 100.x-Adresse auflisten. Bei einem Server, der mit einem Skript eingerichtet wird, ist eine interaktive URL nicht geeignet. Erstellen Sie in der Administrationskonsole einen Auth-Key. Übergeben Sie ihn zusammen mit einem Tag, das den Maschinentyp festhält.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

Ein getaggter Node gehört dem Tag und nicht der Person, die den Befehl ausgeführt hat. Er bleibt daher auch dann funktionsfähig, wenn das Konto dieser Person gelöscht wurde. Das Tag muss zuvor in Ihrer Policy-Datei unter tagOwners deklariert werden. Andernfalls wird der Befehl abgelehnt. Das Tagging ändert außerdem, wie die Maschine auf Ihren Tarif angerechnet wird. Eine getaggte Ressource wird separat von den eigenen Geräten einer Person berechnet. Welche Leistungen der kostenlose Tarif tatsächlich umfasst beschreibt die entsprechenden Grenzen.

Für eine Flotte sind zwei Einstellungen wichtig. Node-Keys laufen standardmäßig nach 180 Tagen ab (Stand August 2026). Nach Ablauf eines Keys "connections to/from the given endpoint will stop working", bis sich jemand erneut anmeldet. Öffnen Sie daher bei unbeaufsichtigten Servern die Zeile der Maschine in der Administrationskonsole und wählen Sie Disable Key Expiry. MagicDNS ist für Tailnets, die am oder nach dem 20 October 2022 erstellt wurden, standardmäßig aktiviert. Es gibt jedem Node einen Namen wie db-1.yak-bebop.ts.net. Dieser wird von einem Stub-Resolver unter 100.100.100.100 aufgelöst. Verwenden Sie die Namen statt der Adressen. Ein neu erstellter Node erhält eine neue Adresse, behält aber seinen Namen.

Wenn die Installation mit apt oder dem Repository fehlschlägt, beschreibt Die häufigsten Tailscale-Installationsfehler unter Ubuntu die entsprechenden Lösungen.

Einen an localhost gebundenen Dienst erreichen

Hier wird ein Tailnet nützlich, und hier bleiben viele stecken. Der Beitritt zum Tailnet macht einen Loopback-Dienst nicht erreichbar.

ss -tlnp | grep 3000

Wenn die Ausgabe 127.0.0.1:3000 enthält, akzeptiert der Socket nur Pakete, deren Zieladresse 127.0.0.1 ist. Eine Anfrage von einem anderen Knoten trifft mit der 100.x-Adresse dieses Knotens als Ziel ein. Der Kernel findet daher keinen Listener und antwortet mit einem TCP-Reset. Der Client meldet Connection refused. Der Tunnel funktioniert. Das Problem liegt beim Listener.

Es gibt zwei saubere Lösungen. Binden Sie den Dienst an die Tailnet-Adresse des Knotens. Dadurch bleibt er ohne vorgeschalteten Proxy von der öffentlichen Schnittstelle getrennt. Übergeben Sie --bind 100.101.102.104 oder die entsprechende Option in Ihrer Konfiguration. Bei einem Container veröffentlichen Sie den Port als -p 100.101.102.104:3000:3000. Alternativ lassen Sie den Dienst an localhost gebunden und schalten Tailscale davor.

tailscale serve 3000

Damit werden Anfragen an http://127.0.0.1:3000 weitergeleitet und innerhalb Ihres Tailnets unter einem ts.net-Namen über HTTPS bereitgestellt, sobald HTTPS-Zertifikate für das Tailnet aktiviert sind. Der Dienst bleibt auf Ihre Knoten beschränkt. Die öffentliche Variante dieses Konzepts heißt Funnel. Tailscale Serve mit Funnel erläutert, welche Variante Sie benötigen.

Zwei verwandte Aufgaben werden auf eigenen Seiten behandelt. Um ein vollständiges privates Netzwerk zu erreichen, auf dem Tailscale nicht installiert ist, benötigen Sie einen Subnet-Router auf einem VPS. Um den ausgehenden Internetverkehr eines Knotens über einen anderen Knoten zu leiten, benötigen Sie einen Exit-Node.

Ports schließen, die Sie nicht mehr benötigen

Sobald jeder Administrator über das Tailnet auf den Server zugreift, hat der öffentliche Port 22 keine Aufgabe mehr. Das ist der praktische Vorteil: Ein geschlossener Port kann nicht per Brute-Force angegriffen werden, und Ihre Logs werden nicht mehr mit solchen Versuchen gefüllt.

Die Reihenfolge ist wichtig. Richten Sie zuerst den Zugriff über das Tailnet ein, prüfen Sie in einer zweiten Sitzung, dass Sie sich darüber anmelden können, und entfernen Sie erst danach die öffentliche Regel.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Löschen Sie anschließend die öffentliche SSH-Regel und stellen Sie die Verbindung über den MagicDNS-Namen wieder her. Beachten Sie, was ufw allow in on tailscale0 tatsächlich bewirkt: Es vertraut allen Daten, die über den Tunnel eintreffen. Dadurch übernimmt Ihre Tailscale-Richtliniendatei die Zugriffskontrolle anstelle von ufw. Erstellen Sie die Richtlinie entsprechend.

Ein Hinweis für den Betrieb von Containern: Ein veröffentlichter Docker-Port installiert eigene NAT-Regeln und umgeht ufw. Ein ufw deny schließt ihn daher nicht. Veröffentlichte Docker-Ports umgehen ufw erklärt den Mechanismus. Wenn Sie den Port an die Tailnet-Adresse binden, wie oben beschrieben, umgehen Sie dieses Problem. Läuft die Anwendung unter Docker Compose, geht ein Tailscale-Sidecar im Compose-Stack noch einen Schritt weiter und entfernt den veröffentlichten Port vollständig. Der Container ist dann nur noch über seinen Tailnet-Namen erreichbar.

Was Tailscale schützt und was nicht

Das sollte klar benannt werden, weil die Marketingdarstellung die Grenze verwischt. Dieser Abschnitt behandelt nur die Sicherheit; welche praktischen Grenzen Tailscale darüber hinaus hat, etwa beim kostenlosen Tarif oder als Ersatz für ein Anonymitäts-VPN, fasst die Übersicht der Nachteile von Tailscale zusammen.

Geschützt: Der Datenverkehr zwischen zwei Knoten wird mit WireGuard Ende zu Ende verschlüsselt. Kein Relay dazwischen kann ihn lesen. Private Schlüssel verlassen niemals das System, auf dem sie erzeugt wurden. Knoten benötigen keinen öffentlichen eingehenden Port. Im Internet gibt es daher auf 22 oder 5432 nichts zu scannen. Der Zugriff zwischen Knoten wird durch eine Policy-Datei festgelegt und nicht durch die Person, die eine Adresse kennt.

Nicht geschützt: Der Koordinationsserver sieht Ihren Gerätegraphen. Diese Metadaten sind bereits für sich genommen sensibel, weil Rechnernamen, Besitzer, Adressen und Online-Zeiten Ihre Infrastruktur beschreiben. Der Server verteilt außerdem Schlüssel. Das ist das größere Risiko. Tailscale formuliert es direkt: „Wenn Tailscale bösartig wäre und unbemerkt neue Knoten in Ihr Netzwerk einfügen würde, könnte Tailscale Datenverkehr zu Ihren vorhandenen Knoten im Klartext senden oder von ihnen empfangen.“ Auch Ihr Single-Sign-On-Anbieter befindet sich in derselben Vertrauenskette. Wer dort eine Identität ausstellen kann, kann einen Knoten hinzufügen. Ein kompromittierter Knoten ist außerdem ein Peer im Tailnet. Was er als Nächstes erreicht, hängt daher von Ihrer Policy ab. Ob dieses Risiko akzeptabel ist, hängt davon ab, gegen wen Sie sich schützen. Das vollständige Vertrauensmodell geht jeden dieser Fälle durch, einschließlich dessen, was ein gestohlenes Identitätskonto tatsächlich tun kann.

Für das Risiko bei der Schlüsselverteilung gibt es zwei Antworten. Die erste ist Tailnet Lock. Dabei müssen bereits vertrauenswürdige Knoten einen neuen Knoten kryptografisch signieren, bevor die anderen Knoten ihn akzeptieren. Eine Steuerungsebene, die einen Knoten ohne gültige Signatur hinzufügt, wird ignoriert. Die Administrationskonsole erzeugt die genaue tailscale lock init-Zeile für Ihre Signaturknoten. Jeder Knoten kann prüfen, was er empfängt.

tailscale lock status

Alle Knoten sollten dieselbe Menge vertrauenswürdiger Signaturschlüssel melden. Die zweite Antwort besteht darin, die Steuerungsebene selbst zu betreiben. Ein selbst gehosteter Headscale-Koordinationsserver verwendet dasselbe Protokoll mit denselben Clients. Dadurch liegen der Gerätegraph und die Schlüsselverteilung auf Hardware, die Sie selbst kontrollieren. Auch die Verfügbarkeit dieses Servers liegt dann in Ihrer Verantwortung. Wenn Sie noch selbst gehostete Steuerungsebenen vergleichen, statt sich für diese Lösung zu entscheiden, ist NetBird ein separates Mesh-VPN, dessen Server Sie durchgehend auf einem einzelnen VPS betreiben.

Eine Voreinstellung sollten Sie am ersten Tag ändern. Ein neues Tailnet wird mit einer großzügigen Policy ausgeliefert: „Die Standard-Policy-Datei des Tailnets ermöglicht die Kommunikation zwischen allen Geräten innerhalb des Tailnets.“ Sobald Sie einen acls-Abschnitt hinzufügen, wechselt das Modell zu „standardmäßig verweigern“. Nur Ihre Regeln lassen dann Datenverkehr zu.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Diese Policy erlaubt Mitgliedern des Tailnets, SSH auf markierten Servern zu erreichen, und sonst nichts. Fügen Sie für jeden Dienst eine eigene Regel hinzu, statt den Platzhalter beizubehalten. Der Platzhalter bedeutet, dass der Schlüssel eines einzigen gestohlenen Laptops Ihre Datenbank erreicht.

Fehlerbilder und die angezeigten Meldungen

tailscale status meldet immer relay. Die beiden Knoten konnten keinen direkten Pfad aufbauen. Führen Sie tailscale netcheck auf beiden Seiten aus. UDP: false bedeutet, dass ausgehender UDP-Verkehr blockiert wird und daher nur ein Relay funktionieren kann. MappingVariesByDestIP: true bedeutet, dass sich ein striktes NAT dazwischen befindet. Wenn Sie die entsprechende Seite kontrollieren, lässt sich das Problem häufig beheben, indem Sie eingehenden UDP-Verkehr auf Port 41641 zulassen.

Ein Knoten, der monatelang funktioniert hat, ist verschwunden. Sein Node-Key ist nach dem Standardzeitraum von 180 Tagen abgelaufen. Der Computer wird in der Administratorkonsole als abgelaufen angezeigt. sudo tailscale up auf dem Computer aktiviert ihn wieder. Deaktivieren Sie den Ablauf von Schlüsseln auf Servern, damit das Problem nicht erneut auftritt.

Peers werden aufgelistet, aber Verbindungen laufen in einen Timeout. Die Konnektivität funktioniert, aber die Richtlinie verweigert den Netzwerkverkehr. Prüfen Sie im Abschnitt acls, ob eine Regel diese Quelle, dieses Ziel und diesen Port abdeckt. Ein abgewiesenes Paket wird verworfen und nicht beantwortet. Deshalb erhalten Sie einen Timeout statt Connection refused.

MagicDNS-Namen werden nicht aufgelöst. ping db-1 schlägt fehl, während ping 100.101.102.104 funktioniert. Etwas hat /etc/resolv.conf ersetzt, sodass Abfragen den Stub-Resolver unter 100.100.100.100 nie erreichen. Prüfen Sie cat /etc/resolv.conf auf 100.100.100.100. Prüfen Sie außerdem, welche andere Software auf dem Computer in diese Datei schreibt. Es handelt sich um dieselbe Problemklasse wie bei DNS-Ausfällen innerhalb eines WireGuard-Tunnels.

tailscale up akzeptiert Ihr Tag nicht. Das Tag ist in der Richtliniendatei nicht unter tagOwners deklariert. Fügen Sie es dort hinzu und führen Sie den Befehl erneut aus.

FAQ

Ist Tailscale ein VPN oder ein Mesh-Netzwerk?

Beide Begriffe sind korrekt, aber sie beschreiben unterschiedliche Ebenen. Die Tunnel verwenden WireGuard, daher ist Tailscale ein VPN. Die Topologie ist ein Mesh, weil jeder Knoten direkt zu jedem Knoten, mit dem er kommuniziert, einen Tunnel aufbaut, anstatt jedes Paket über einen zentralen Server zu senden. Der Koordinationsserver befindet sich in der Steuerungsebene, nicht in der Datenebene. Wenn er nicht erreichbar ist, übertragen Ihre bestehenden Tunnel den Netzwerkverkehr weiterhin. Während eines Ausfalls können sich jedoch keine neuen Knoten anmelden, und Änderungen an Schlüsseln oder Richtlinien werden nicht übernommen.

Kann Tailscale meinen Netzwerkverkehr lesen?

Nicht dessen Inhalte. Der Netzwerkverkehr wird zwischen den Knoten mit WireGuard Ende zu Ende verschlüsselt, private Schlüssel verlassen die Knoten nie, und ein DERP-Relay leitet Pakete weiter, die es nicht entschlüsseln kann. Tailscale sieht jedoch Metadaten: Rechnernamen, Besitzer, öffentliche Schlüssel, Endpoint-Adressen und den Online-Status der einzelnen Knoten. Tailscale verteilt außerdem Schlüssel. Ein kompromittierter Koordinationsserver könnte daher versuchen, einen Knoten einzuschleusen, dem Ihre gesamte Umgebung anschließend vertraut. Tailnet lock verhindert dies, indem es Signaturen Ihrer eigenen vertrauenswürdigen Knoten verlangt. Headscale entfernt die gehostete Steuerungsebene aus dieser Struktur.

Muss ich Firewall-Ports für Tailscale öffnen?

Eingehend fast nie. Laut eigener Dokumentation von Tailscale gilt: "most of the time, you don't need to open any firewall ports." Ausgehend benötigt ein Knoten TCP 443 zum Koordinationsserver und zu den Relays sowie UDP 3478 für STUN. Direkte Tunnel verwenden UDP mit einem Quellport, der standardmäßig 41641 ist. Eingehende Verbindungen auf UDP 41641 zuzulassen, ist optional. Dies hilft nur dabei, direkte Verbindungen in problematischen Netzwerken herzustellen.

Warum können andere Knoten meinen Dienst auf Port 3000 nicht erreichen?

Prüfen Sie zuerst mit ss -tlnp, an welche Adresse der Dienst gebunden ist. Ein Listener auf 127.0.0.1:3000 weist Verbindungen zurück, die an die 100.x-Tailnet-Adresse des Knotens gerichtet sind, weil dieser Socket nur das Loopback-Ziel akzeptiert. Der Client sieht dann Connection refused. Binden Sie den Dienst an die Tailnet-Adresse, oder führen Sie tailscale serve 3000 aus, um die Verbindung weiterzuleiten. Wenn der Listener bereits auf 0.0.0.0 lauscht und die Verbindung statt einer Ablehnung in einen Timeout läuft, liegt die Ursache in einer Richtlinienregel oder einer Host-Firewall und nicht an der Bind-Adresse.

Sollte ich Headscale statt des Tailscale-Koordinationsservers betreiben?

Betreiben Sie Headscale, wenn der Gerätegraph oder die Schlüsselverteilung auf einer von Ihnen kontrollierten Infrastruktur bleiben muss oder wenn das Tailnet ohne Abhängigkeit von einem externen Dienst funktionieren soll. Die Clients und das Protokoll sind identisch. Dafür müssen Sie den Koordinationsserver selbst betreiben. Fällt er aus, können sich keine neuen Knoten anmelden, und Richtlinienänderungen werden nicht angewendet. Für eine kleine Umgebung ist die gehostete Steuerungsebene mit aktiviertem tailnet lock meist der bessere Kompromiss.