Was ist Tailscale und wie funktioniert es?

Was ist Tailscale?

Tailscale ist ein VPN, das Ihre Rechner direkt miteinander verbindet, statt den gesamten Datenverkehr über ein von Ihnen betriebenes Gateway zu leiten. Auf jedem Knoten läuft WireGuard. Dadurch werden die Pakete auf dem Weg von einem Server zum anderen verschlüsselt, und kein System dazwischen 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 die gesamte Architektur. Die Datenebene arbeitet Peer-to-Peer und verschlüsselt den Datenverkehr zwischen den Knoten. 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 Fakten. Wenn Sie bereits ein WireGuard-VPN manuell auf einem VPS eingerichtet haben, ist Tailscale derselbe Tunnel, ergänzt um eine automatische Schlüsselverteilung und die Umgehung von Firewalls.

Wie funktioniert Tailscale?

Ihr privates Netzwerk aus Nodes wird als Tailnet bezeichnet. Wenn eine Maschine einem Tailnet beitritt, passieren vier Dinge.

1. Der tailscaled-Daemon startet, erzeugt ein WireGuard-Schlüsselpaar und speichert seinen Status in /var/lib/tailscale/tailscaled.state. Der private Schlüssel bleibt auf dieser Maschine. Tailscale formuliert es ausdrücklich: „Der private Schlüssel verlässt seinen Node niemals.“
2. Der Node meldet sich beim Coordination Server 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 Coordination Server sendet eine Network Map zurück: den öffentlichen Schlüssel, die Tailnet-Adresse, den Maschinennamen und die möglichen Endpunkte jedes Nodes, den dieser Node erreichen darf.
4. Anschließend versucht jedes Node-Paar, einen direkten WireGuard-Tunnel zwischen sich aufzubauen. Wenn das fehlschlägt, leiten die Nodes die Pakete stattdessen über ein Relay weiter.

Jeder Node erhält eine stabile Adresse aus 100.64.0.0/10, dem Carrier-Grade-NAT-Adressbereich von 100.64.0.0 bis 100.127.255.255. Tailscale verwendet diesen Bereich, weil er für Provider-Infrastruktur reserviert ist. Dadurch kommt es nur selten zu Konflikten mit den privaten Adressen, die Ihre Server bereits verwenden. Unter Linux wird der Tunnel als Interface mit dem Namen tailscale0 angezeigt.

Die WireGuard-Implementierung läuft im Userspace innerhalb von tailscaled, nicht im Kernelmodul. Deshalb startet Tailscale auch in Container-Virtualisierungen, bei denen sudo modprobe wireguard mit Operation not supported fehlschlägt. Dadurch liegt die maximal erreichbare Übertragungsrate auf einem bestimmten System jedoch unter der von WireGuard im Kernel. Das ist einer der Nachteile, auf die Tailscale im Vergleich zu plain WireGuard näher eingeht.

Zwei Befehle zeigen Ihnen den aktuellen Status.

tailscale ip -4
tailscale status

tailscale status gibt eine Zeile pro Node 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 Maschinen 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 Node 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, sowie 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. Jeder Koordinationsserver, ob gehostet oder selbst betrieben, muss als vertrauenswürdig gelten, wenn er Ihren Nodes mitteilt, welche öffentlichen Schlüssel zum Tailnet gehören. Das ist der zentrale Punkt des weiter unten beschriebenen Bedrohungsmodells und der Grund, warum Headscale, ein von Ihnen selbst gehosteter Open-Source-Koordinationsserver existiert.

Wie zwei Server hinter verschiedenen Firewalls direkt miteinander kommunizieren

NAT (Network Address Translation) ermöglicht es vielen Geräten, eine öffentliche Adresse gemeinsam zu verwenden. Ihr VPS verfügt normalerweise über eine eigene öffentliche Adresse. Die anderen Geräte, 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 im Büronetzwerk oder ein Gerät 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 erfährt dadurch die öffentliche Adresse und den Port, die der Router diesem Socket zugewiesen hat. Beide Nodes melden diese Kandidaten an den Coordination Server, 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 Seite 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 läuft über UDP 3478 zu den Relay-Servern von Tailscale. Die Control-Verbindung und alle weitergeleiteten Daten verwenden HTTPS über TCP 443. In den meisten Fällen müssen Sie keine eingehenden Verbindungen zulassen. In einem Netzwerk mit schwieriger NAT kann eine eingehende Freigabe für UDP 41641 jedoch eine direkte Verbindung wahrscheinlicher machen.

tailscale netcheck

Lesen Sie zwei Zeilen dieses Berichts. UDP: true bedeutet, dass UDP das Gerät ü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. Dadurch funktioniert die oben beschriebene Adressvorhersage nicht, und diese Nodes bleiben normalerweise im Relay-Modus.

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 solches Relay.

Die Pakete bleiben verschlüsselt. Tailscale formuliert es eindeutig: „Ein DERP-Server kann Ihren Datenverkehr niemals entschlüsseln. Er leitet bereits verschlüsselten Datenverkehr lediglich blind von einem Node zu einem anderen weiter.“ Ein Relay sieht den Ciphertext 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 ohne Unterbrechung, sobald die beiden Nodes einander 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 an. Wenn sie ausbleibt, führen Sie tailscale netcheck auf beiden Seiten aus. Ein Relay-Pfad funktioniert weiterhin. Er erhöht jedoch die Latenz, weil jedes Paket über einen dritten Rechner umgeleitet wird.

Einen VPS in Ihr Tailnet aufnehmen

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, authentifizieren Sie sich, und der Node erscheint in Ihrer Administrationskonsole. Prüfen Sie anschließend, ob der Daemon nach einem Reboot wieder startet, da dieser Schritt häufig übersprungen wird.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled sollte enabled ausgeben, und tailscale status sollte den neuen Node mit seiner 100.x-Adresse auflisten. Für einen Server, der per Skript erstellt wird, ist eine interaktive URL nicht geeignet. Erzeugen Sie in der Administrationskonsole einen Auth Key und ü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 funktionsfähig, wenn das Konto dieser Person gelöscht wird. Das Tag muss zuvor in Ihrer Policy-Datei unter tagOwners deklariert werden. Andernfalls wird der Befehl abgelehnt. Das Tagging wirkt sich außerdem darauf aus, wie die Maschine auf Ihren Tarif angerechnet wird, da eine getaggte Ressource separat von den eigenen Geräten einer Person berechnet wird. Welche Leistungen der kostenlose Tarif tatsächlich abdeckt beschreibt, wo diese Grenzen liegen.

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

Wenn die Installation selbst bei apt oder beim 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 Nutzer stecken. Die Mitgliedschaft im Tailnet macht einen Loopback-Dienst nicht erreichbar.

ss -tlnp | grep 3000

Wenn dieser Befehl 127.0.0.1:3000 ausgibt, akzeptiert der Socket nur Pakete, deren Ziel 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 dafür keinen Listener und antwortet mit einem TCP-Reset. Der Client meldet Connection refused. Der Tunnel funktioniert. Das Problem liegt beim Listener.

Es gibt zwei praktikable 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. Oder lassen Sie den Dienst an localhost gebunden und schalten Sie Tailscale davor.

tailscale serve 3000

Dabei 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 desselben Konzepts ist Funnel. Tailscale serve mit Funnel beschreibt, welche Variante Sie benötigen.

Zwei verwandte Aufgaben haben eigene Seiten. Um ein gesamtes 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.

Nicht mehr benötigte Ports schließen

Sobald jeder Administrator den Server über das Tailnet erreicht, hat der öffentliche Port 22 keine Aufgabe mehr. Das ist der praktische Nutzen: 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. Fügen Sie zuerst den Tailnet-Zugriff hinzu. Stellen Sie in einer zweiten Sitzung sicher, dass Sie sich darüber anmelden können. 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 erneut her. Beachten Sie, was ufw allow in on tailscale0 tatsächlich bewirkt: Alles, was über den Tunnel eingeht, wird zugelassen. Damit übernimmt Ihre Tailscale-Policy-Datei die Zugriffskontrolle anstelle von ufw. Erstellen Sie die Policy entsprechend.

Ein Hinweis für Systeme mit Containern: Ein veröffentlichter Docker-Port installiert eigene NAT-Regeln und umgeht ufw. Daher schließt ein ufw deny diesen Port nicht. Von Docker veröffentlichte Ports umgehen ufw erklärt den Mechanismus. Wenn Sie den Port wie oben an die Tailnet-Adresse binden, umgehen Sie dieses Problem.

Was Tailscale schützt und was nicht

Das sollte klar benannt werden, weil die Marketingdarstellung die Grenze verwischt.

Geschützt: Der Datenverkehr zwischen zwei Knoten ist mit WireGuard Ende-zu-Ende-verschlüsselt. Kein Relay in der Mitte kann ihn lesen. Private Schlüssel verlassen niemals das Gerät, auf dem sie erzeugt wurden. Knoten benötigen keinen öffentlichen eingehenden Port. Dadurch gibt es für das Internet nichts, das auf 22 oder 5432 gescannt werden kann. Der Zugriff zwischen Knoten wird durch eine Policy-Datei bestimmt 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 Maschinennamen, Besitzer, Adressen und Online-Zeiten Ihre Infrastruktur beschreiben. Außerdem verteilt der Server Schlüssel. Das ist das größere Risiko. Tailscale sagt es direkt: „Wenn Tailscale bösartig wäre und unbemerkt neue Knoten in Ihr Netzwerk einfügen würde, könnte Tailscale Datenverkehr an Ihre vorhandenen Knoten im Klartext senden oder von ihnen empfangen.“ Ihr Single-Sign-on-Anbieter befindet sich im selben Vertrauenspfad. Wer dort eine Identität ausstellen kann, kann einen Knoten hinzufügen. Ein kompromittierter Knoten ist außerdem ein Peer im Tailnet. Er kann daher alles erreichen, was Ihre Policy erlaubt. Ob daraus ein akzeptables Risiko entsteht, hängt davon ab, gegen wen Sie sich schützen. Das vollständige Vertrauensmodell geht jeden dieser Fälle durch. Dazu gehört auch, was ein Angreifer mit einem gestohlenen 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 Ihre anderen Knoten ihn akzeptieren. Eine Control Plane, 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 sieht.

tailscale lock status

Alle Knoten sollten dieselbe Menge vertrauenswürdiger Signaturschlüssel melden. Die zweite Antwort besteht darin, die Control Plane selbst zu betreiben. Ein selbst gehosteter Headscale-Koordinationsserver verwendet gegenüber denselben Clients dasselbe Protokoll. Dadurch liegen der Gerätegraph und die Schlüsselverteilung auf Hardware, die Sie besitzen. Damit sind Sie auch für die Verfügbarkeit dieses Servers verantwortlich. Wenn Sie noch Control Planes für den Selbstbetrieb vergleichen, statt sich auf diese Lösung festzulegen, ist NetBird ein separates Mesh-VPN, dessen Server Sie vollständig auf einem einzelnen VPS betreiben.

Eine Standardeinstellung sollten Sie am ersten Tag ändern. Ein neues Tailnet wird mit einer permissiven Policy ausgeliefert: „Die Standard-Tailnet-Policy-Datei ermöglicht die Kommunikation zwischen allen Geräten innerhalb des Tailnets.“ Sobald Sie einen acls-Abschnitt hinzufügen, gilt standardmäßig deny. Nur Ihre Regeln lassen dann Datenverkehr passieren.

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

Diese Policy erlaubt Tailnet-Mitgliedern, SSH auf getaggten Servern zu erreichen, und nichts anderes. Fügen Sie für jeden Dienst eine eigene Regel hinzu, statt den Wildcard-Eintrag beizubehalten. Der Wildcard-Eintrag bedeutet, dass ein gestohlener Laptop-Schlüssel den Zugriff auf Ihre Datenbank ermöglicht.

Fehlerbilder und die angezeigten Meldungen

tailscale status meldet immer relay. Die beiden Knoten konnten keinen direkten Pfad aufbauen. Führen Sie tailscale netcheck an beiden Enden aus. UDP: false bedeutet, dass ausgehender UDP-Verkehr blockiert wird und daher nur ein Relay funktionieren kann. MappingVariesByDestIP: true bedeutet, dass ein restriktives NAT dazwischengeschaltet ist. Wenn Sie die betreffende 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 Rechner wird in der Administrationskonsole als abgelaufen angezeigt. sudo tailscale up auf dem Rechner stellt ihn wieder her. Deaktivieren Sie den Ablauf von Keys auf Servern, damit das Problem nicht erneut auftritt.

Peers werden aufgelistet, aber Verbindungen laufen in einen Timeout. Die Konnektivität funktioniert, aber die Policy verweigert den Verkehr. Prüfen Sie den Abschnitt acls auf eine Regel, die diese Quelle, dieses Ziel und diesen Port abdeckt. Ein abgelehntes Paket wird verworfen, statt beantwortet zu werden. Deshalb erhalten Sie einen Timeout anstelle von 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 nicht erreichen. Prüfen Sie cat /etc/resolv.conf auf 100.100.100.100 und sehen Sie nach, welche anderen Komponenten auf dem Rechner in diese Datei schreiben. Es handelt sich um dieselbe Fehlerklasse wie bei ausfallender DNS-Auflösung innerhalb eines WireGuard-Tunnels.

tailscale up akzeptiert Ihr Tag nicht. Das Tag ist im Abschnitt tagOwners der Policy-Datei nicht 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 im Control Path, nicht im Data Path. Wenn er nicht erreichbar ist, übertragen Ihre bestehenden Tunnel weiterhin Netzwerkverkehr. Während eines Ausfalls können sich jedoch keine neuen Knoten verbinden, und Änderungen an Schlüsseln oder Richtlinien werden nicht übernommen.

Kann Tailscale meinen Netzwerkverkehr lesen?

Nicht dessen Inhalte. Der Netzwerkverkehr ist 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 jedes Knotens. Tailscale verteilt außerdem Schlüssel. Ein kompromittierter Koordinationsserver könnte daher versuchen, einen Knoten einzuschleusen, dem Ihre gesamte Tailnet vertrauen würde. Tailnet lock verhindert dies, indem es Signaturen Ihrer eigenen vertrauenswürdigen Knoten verlangt. Headscale entfernt die gehostete Control Plane 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 auf 41641 gesetzt ist. Eingehende Verbindungen auf UDP 41641 zu erlauben ist optional. Das hilft nur dabei, direkte Verbindungen in problematischen Netzwerken aufzubauen.

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

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

Sollte ich Headscale statt des Koordinationsservers von Tailscale verwenden?

Verwenden Sie Headscale, wenn der Gerätegraph oder die Schlüsselverteilung auf einer von Ihnen kontrollierten Infrastruktur bleiben muss oder wenn die Tailnet ohne Abhängigkeit von einem externen Dienst funktionieren soll. Die Clients und das Protokoll sind identisch. Der Nachteil ist, dass Sie den Koordinationsserver selbst betreiben müssen. Bei einem Ausfall können sich keine neuen Knoten verbinden, und Richtlinienänderungen werden nicht übernommen. Für eine kleine Geräteflotte ist die gehostete Control Plane mit aktiviertem Tailnet lock normalerweise der bessere Kompromiss.