Tailscale langsam: Relay oder direkte Verbindung prüfen

Warum Tailscale langsam ist: Relay statt direkter Verbindung

Tailscale ist langsam, wenn die Verbindung über ein Relay läuft, und erreicht bei einer direkten Verbindung nahezu die Leitungsrate. Bei einer direkten Verbindung werden verschlüsselte WireGuard-Pakete unmittelbar von einem Rechner zum anderen übertragen. Die Geschwindigkeit entspricht daher der Kapazität der beiden Internetverbindungen. Bei einer Relay-Verbindung wird jedes Paket zunächst über einen dritten Rechner geleitet. Dadurch gelten dessen Latenz und der Bandbreitenanteil, der Ihnen zur Verfügung steht. Auf der eigenen Tailscale-Performance-Seite wird es in einem Satz zusammengefasst: „Direkte Verbindungen führen fast immer zu einer geringeren Latenz und einem höheren Durchsatz.“

In Ihrer Anwendung ist kein Unterschied erkennbar. Der Dateikopiervorgang ist einfach langsam, und die SSH-Sitzung reagiert verzögert. Daher müssen Sie zunächst feststellen, welche Verbindungsart bereits verwendet wird. Zwei Befehle liefern diese Information in weniger als einer Minute. Danach geht es darum, die Ursache zu beheben. Die Grundlagen sollten Sie kennen, bevor Sie beginnen, denn der Koordinationsserver und die WireGuard-Datenebene sind getrennte Systeme und nur die Datenebene überträgt Ihre Daten.

Die beiden Befehle, die direkte von weitergeleiteten Verbindungen unterscheiden

Senden Sie Datenverkehr an den Peer, bevor Sie etwas messen. Tailscale baut einen Pfad bei Bedarf auf. Ein Peer, mit dem Sie heute noch nicht kommuniziert haben, hat möglicherweise noch keinen Pfad ausgehandelt. Dann würden Sie einen veralteten Status auswerten. Ein ping oder ein curl an die Tailnet-Adresse des Peers genügt.

tailscale status

Die Antwort steht am Ende der Zeile des jeweiligen Peers.

100.113.160.82 device-a  tagged-devices linux   active; offers exit node; direct 203.0.113.9:41641
100.104.93.78  device-b  you@           android active; relay "tor"

direct gefolgt von einer Adresse und einem Port bedeutet, dass die Pakete direkt an diese Adresse gesendet werden. relay "tor" bezeichnet einen DERP-Server (designated encrypted relay for packets). Das ist eine der Relay-Maschinen von Tailscale. Jedes Paket an diesen Peer wird über diesen Server übertragen. Ein dritter Wert, peer-relay, wird im nächsten Abschnitt behandelt.

tailscale ping device-b

Eine funktionierende Verbindung beginnt als Relay-Verbindung und wechselt anschließend den Pfad. Die ersten Pakete laufen über den nächstgelegenen DERP-Server, während die beiden Maschinen den Pfad aushandeln. Danach ändert sich der Pfad:

pong from device-b (100.113.160.82) via DERP(tor) in 51ms
pong from device-b (100.113.160.82) via DERP(tor) in 48ms
pong from device-b (100.113.160.82) via 203.0.113.9:41641 in 35ms

Der Lauf endet an dieser Stelle, weil --until-direct standardmäßig auf true gesetzt ist. Eine Verbindung, die nicht direkt hergestellt werden kann, sieht stattdessen so aus. Sie endet mit einem Satz und nicht mit einem Pong:

pong from device-b (100.104.93.78) via DERP(tor) in 53ms
pong from device-b (100.104.93.78) via DERP(tor) in 60ms
direct connection not established

Die letzte Zeile enthält das Ergebnis. Tailscale hat alle vorgesehenen Prüfungen gesendet und keinen direkten Pfad gefunden. Um einen weitergeleiteten Pfad weiter zu überwachen, statt beim ersten direkten Pfad zu stoppen, führen Sie tailscale ping --until-direct=false -c 20 device-b aus und prüfen Sie die Streuung der Latenzwerte. Ein weitergeleiteter Pfad weist normalerweise sowohl höhere Werte als auch größere Schwankungen auf, weil dabei zwei Internetpfade über eine von Ihnen nicht kontrollierte Maschine verbunden werden.

Was bedeutet peer-relay in tailscale status?

Ein Peer-Relay ist eine Maschine in Ihrem eigenen tailnet, die den Datenverkehr anderer Mitglieder weiterleitet, wenn keine direkte Verbindung möglich ist. Sie lauscht an einem von Ihnen festgelegten UDP-Port, und der Daemon verwendet sie bevorzugt vor DERP. tailscale status kennzeichnet eine solche Verbindung peer-relay, und tailscale ping gibt den Endpunkt des Relays aus:

pong from device-b (100.97.143.93) via peer-relay(203.0.113.42:40000:vni:1) in 4ms
direct connection not established

Lesen Sie die Ausgabe genau. Es handelt sich weiterhin nicht um eine direkte Verbindung, daher endet der Lauf weiterhin mit direct connection not established. Geändert hat sich nur, wer den Datenverkehr weiterleitet. Ein VPS mit öffentlicher IP-Adresse und großzügigem Bandbreitenlimit ist für Ihren eigenen Datenverkehr ein wesentlich besseres Relay als ein gemeinsam genutzter DERP-Knoten. Deshalb ist diese Funktion für alle relevant, die einen Server mieten. Aktivieren Sie sie auf der Maschine mit dem öffentlich erreichbaren Endpunkt:

sudo tailscale set --relay-server-port=40000

Mit dem Port 0 wird ein zufällig ausgewählter, nicht belegter Port verwendet. Eine leere Zeichenfolge deaktiviert den Relay-Server. Erteilen Sie den Clientgeräten anschließend in der tailnet-Richtliniendatei die Berechtigung, ihn mit der Fähigkeit tailscale.com/cap/relay zu verwenden:

{
  "grants": [
    {
      "src": ["tag:us-east-vpc"],
      "dst": ["tag:us-east-relays"],
      "app": {
        "tailscale.com/cap/relay": []
      }
    }
  ]
}

Sowohl das Relaygerät als auch die Clientgeräte benötigen Tailscale 1.86 oder höher. Prüfen Sie daher auf jedem Gerät mit tailscale version die Version, bevor Sie eine Stunde mit der Richtliniendatei verbringen. Die Reihenfolge, in der der Daemon Verbindungen versucht, sollten Sie sich merken. Zuerst versucht er eine direkte Verbindung. Wenn das fehlschlägt, sucht er nach einem Peer-Relay, das er verwenden darf. Wenn kein solches Relay vorhanden ist, verwendet er DERP. DERP ist nie vollständig aus dem Ablauf entfernt, weil es auch der Kanal ist, über den die beiden Maschinen zunächst die Verbindung aushandeln.

Ursache 1: Eine ausgehende Firewall blockiert UDP

Tailscale nennt zwei Gründe dafür, dass eine Verbindung über ein Relay läuft. Der erste ist blockiertes UDP. Fragen Sie den Rechner direkt ab:

tailscale netcheck

Die Ausgabe ist hier gekürzt. Das oberste Feld ist entscheidend:

Report:
  * UDP: true
  * IPv4: yes, 203.0.113.9:41641
  * IPv6: no
  * MappingVariesByDestIP: false
  * PortMapping:
  * Nearest DERP: Dallas

UDP: false ist die vollständige Antwort, wenn dieser Wert angezeigt wird. Der Rechner kann kein UDP-Paket an die Probe-Server von Tailscale senden. Deshalb kann kein direkter Pfad aufgebaut werden, und der Daemon wechselt auf DERP über TCP-Port 443. Dieser Fallback lässt den Rechner weiterhin völlig unauffällig erscheinen: Er ist verbunden, erreichbar, und jedes Byte wird weitergeleitet.

Es sind zwei Regeln für ausgehenden Datenverkehr dokumentiert. „Erlauben Sie Ihren internen Geräten, UDP von :41641 zu *:* zu starten.“ Das ist der eigentliche WireGuard-Datenverkehr. Die zweite Regel lautet: „Erlauben Sie Ihren internen Geräten, UDP zu *:3478 zu starten.“ Dabei handelt es sich um STUN (Session Traversal Utilities for NAT), das Protokoll, mit dem der Rechner seine eigene öffentliche Adresse und seinen Port ermittelt. Verwenden Sie Platzhalter für die Ziele. Tailscale fügt im Laufe der Zeit Relay-Server hinzu. Eine manuell gepflegte Adressliste ist daher innerhalb eines Jahres veraltet.

Bei einem gemieteten Server ist meist eine strenge Richtlinie für ausgehenden Datenverkehr die Ursache. Sie stammt entweder aus einem gehärteten Image oder wird von Ihrem Provider vorgeschaltet. Prüfen Sie zuerst die Standardrichtlinie für ausgehenden Datenverkehr:

sudo ufw status verbose
sudo nft list ruleset

Default: deny (incoming), allow (outgoing) ist in Ordnung und nicht die Ursache. Ein ausgehender Standardwert von deny mit einer kurzen Allowlist für TCP 443 und DNS sorgt genau dafür, dass ein Server dauerhaft über ein Relay verbunden bleibt. Der Grund ist, dass der DERP-Pfad über TCP 443 durch diese Lücke passt, der direkte Pfad jedoch nicht. Wo diese Regeln tatsächlich liegen, hängt davon ab, ob der Rechner im Hintergrund iptables oder nftables verwendet. Die falsche Firewall zu bearbeiten, ist eine häufige Ursache dafür, dass sich nichts ändert.

Auch die eingehende Seite ist relevant, weil eine VPS eine öffentliche IP-Adresse hat und damit die einfachere Hälfte der Verbindung sein kann. Wenn die Firewall eingehendes UDP auf dem Port akzeptiert, auf dem tailscaled lauscht, können Peers hinter problematischen Heimroutern den Server ohne zusätzliche Maßnahmen erreichen. Ermitteln Sie den tatsächlich verwendeten Port:

sudo ss -lunp | grep tailscaled
sudo ufw allow 41641/udp

41641 ist der standardmäßige statische Port. Bei einem Tailnet mit aktivierter Einstellung randomizeClientPort wählen die Clients stattdessen einen zufälligen Port. Verwenden Sie in diesem Fall die tatsächliche Portnummer aus der Ausgabe von ss und nicht den Wert aus dieser Seite. Prüfen Sie anschließend das Control Panel Ihres Providers. Die meisten Hoster betreiben eine Netzwerk-Firewall, die von der Firewall innerhalb des Servers getrennt ist. Eine Regel, die Sie mit ufw hinzugefügt haben, hat auf diese Firewall keinen Einfluss.

Ursache 2: Hartes NAT an einem oder beiden Enden

Die zweite dokumentierte Ursache ist hartes NAT. NAT (Network Address Translation) bezeichnet die Übersetzung einer privaten Adresse in eine öffentliche Adresse durch einen Router. Ein freundlicher Router verwendet für einen bestimmten internen Socket unabhängig vom Kommunikationspartner denselben öffentlichen Port. Dies wird als endpoint-unabhängige Zuordnung bezeichnet. Bei hartem NAT wird für jedes Ziel ein anderer öffentlicher Port vergeben. Daher entspricht die Adresse, die der Rechner von einem STUN-Server gelernt hat, nicht der Adresse, die ein Peer verwenden kann. Tailscale meldet dies in netcheck als MappingVariesByDestIP: true.

Ein hartes NAT ist überwindbar. Wenn die andere Seite über einen stabilen öffentlichen Endpunkt verfügt, kann der Rechner hinter dem harten NAT weiterhin eine Verbindung zu ihr herstellen, und der Pfad wird aufgebaut. Zwei gleichzeitig vorhandene harte NATs führen zum Fehlschlag, weil keine der beiden Seiten den Port vorhersagen kann, unter dem die jeweils andere Seite erreichbar sein wird.

Auf einem VPS mit einer öffentlichen IPv4-Adresse sollte dieses Feld false anzeigen, da diese Adresse nirgendwo übersetzt wird. Wenn auf einem gemieteten Server true angezeigt wird, wird die Adresse irgendwo im Netzwerk des Providers übersetzt. Keine Firewall-Regel auf dem Rechner kann das ändern. Ihre Möglichkeiten bestehen darin, einen Peer-Relay auf einem Rechner mit einem uneingeschränkt erreichbaren öffentlichen Endpunkt zu betreiben oder die Workload zu verlagern. Dies ist auch der Fall, in dem sich das Bekanntgeben Ihrer privaten Bereiche über einen Subnet Router lohnt. Sie benötigen dann nur einen funktionierenden Pfad in das Netzwerk und nicht zu jedem einzelnen Gerät darin.

Warum ein Exit Node langsamer wirkt, als Tailscale tatsächlich ist

Ein Exit Node ist ein zusätzlicher Hop, und viele machen dafür den Tunnel verantwortlich. Wenn ein Exit Node ausgewählt ist, verlässt eine Anfrage Ihren Laptop, durchquert den Tunnel zum VPS, verlässt den VPS in Richtung öffentliches Internet, und die Antwort kommt auf demselben Weg zurück. Selbst eine perfekt direkte Verbindung zu diesem VPS kann die gesamte Übertragung nicht schneller machen als die eigene Anbindung des VPS. Die zusätzliche Entfernung macht sich bei jedem Seitenaufruf bemerkbar.

Messen Sie die beiden Teilstrecken getrennt. Deaktivieren Sie den Exit Node und testen Sie anschließend nur den Tunnel zur Tailscale-Adresse des VPS:

sudo tailscale set --exit-node=
sudo apt install -y iperf3
iperf3 -s

Führen Sie auf dem Client iperf3 -c 100.113.160.82 mit dieser Tailscale-Adresse als Ziel aus. Dieser Wert beschreibt Ihren Tunnel. Aktivieren Sie den Exit Node anschließend wieder mit sudo tailscale set --exit-node=100.113.160.82 und führen Sie einen normalen Geschwindigkeitstest ins öffentliche Internet aus. Dieser Wert umfasst den Tunnel und die Anbindung des VPS. Wenn der erste Wert gut und der zweite schlecht ist, liegt das Problem nicht bei Tailscale. Prüfen Sie dann das Netzwerk und die Dimensionierung des Exit Nodes. Mit tailscale exit-node list sehen Sie, welche Optionen verfügbar sind, wenn Sie nicht sicher sind, welchen Node Sie ausgewählt haben.

Die CPU ist der zweite begrenzende Faktor eines Exit Nodes. Tailscale empfiehlt, eine neuere CPU-Generation mit höherem Takt gegenüber einer größeren Anzahl von Kernen zu bevorzugen. Ein Plan mit mehr vCPUs ist daher nicht automatisch schneller. Auf einem ausgelasteten Shared Host entspricht die CPU-Leistung, die Ihnen zugesagt wurde, nicht unbedingt der tatsächlich verfügbaren Leistung. Steal Time durch einen stark ausgelasteten Nachbarn zeigt sich als Durchsatz, der sich im Laufe des Tages ändert, obwohl Sie auf Ihrer Seite nichts geändert haben.

Die zentrale Optimierung: rx-udp-gro-forwarding

Tailscale dokumentiert eine einzelne Linux-Einstellung. Sie gilt für Systeme, die Datenverkehr weiterleiten, also Exit Nodes und Subnet Routers. Ein gewöhnlicher Client profitiert davon nicht. Dafür benötigen Sie Tailscale 1.54 oder höher und den Linux-Kernel 6.2 oder höher. Prüfen Sie daher beides, bevor Sie Änderungen vornehmen:

tailscale version
uname -r

Aktivieren Sie anschließend die UDP-GRO-Weiterleitung (Generic Receive Offload) auf der Schnittstelle, die mit dem Internet verbunden ist:

NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

Prüfen Sie, ob die Einstellung übernommen wurde:

ethtool -k $NETDEV | grep -E 'rx-udp-gro-forwarding|rx-gro-list'

Sie sollten rx-udp-gro-forwarding: on und rx-gro-list: off sehen. Das hilft, weil Tailscale UDP verwendet. Wenn der Kernel kleine UDP-Pakete auf dem Weiterleitungspfad zusammengefasst lässt, verarbeitet der Daemon bei gleicher Datenmenge weniger, dafür größere Segmente. ethtool -K bleibt nach einem Reboot nicht erhalten. Machen Sie die Einstellung daher dauerhaft. Auf einem System mit networkd-dispatcher:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Führen Sie das Skript einmal manuell aus und prüfen Sie, ob sein Exit-Status 0 ist. Ein System, das Datenverkehr weiterleitet, benötigt außerdem grundsätzlich aktiviertes IP-Forwarding. Dabei handelt es sich um eine separate Einstellung und einen separaten Fehlerfall:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Welche MTU verwendet Ihre tailscale0-Schnittstelle?

Raten Sie diesen Wert nicht, sondern lesen Sie ihn direkt auf dem System aus:

ip link show tailscale0

Der Wert mtu in dieser Ausgabe wird tatsächlich für Ihren Tunnel verwendet. Er ist niedriger als der Wert 1500, den Ihre Ethernet-Schnittstelle meldet. Das ist beabsichtigt und kein Fehler. Jedes Paket, das Sie innerhalb des Tunnels senden, wird gekapselt: mit einem äußeren IP-Header von 20 Byte bei IPv4 oder 40 Byte bei IPv6, einem UDP-Header von 8 Byte sowie dem WireGuard-Framing und einem Authentifizierungs-Tag von 32 Byte. All das muss in die maximale Paketgröße passen, die der tatsächliche Netzwerkpfad übertragen kann. Tailscale wählt deshalb einen Wert, der auch bei Verbindungen funktioniert, die kein vollständiges Paket mit 1500 Byte übertragen können. Dazu gehören PPPoE-Verbindungen, einige Mobilfunknetze und IPv6-Tunnel.

Das Symptom eines MTU-Problems ist eindeutig. Diagnostizieren Sie es daher nicht allein anhand einer langsamen Verbindung. SSH reagiert, ping funktioniert, und große Übertragungen oder umfangreiche HTTPS-Seiten bleiben anschließend vollständig hängen, statt nur langsam zu laufen. Dieses Muster bedeutet, dass übergroße Pakete irgendwo verworfen werden und keine ICMP-Nachricht den Absender darüber informiert. Wenn Sie die tailscale0-MTU in Richtung 1500 erhöhen, verschlimmert sich das Problem, weil die Pakete, die bereits nicht in den Pfad passen, dadurch noch größer werden. Die korrekte Lösung besteht darin, die funktionierende Pfad-MTU per Halbierungssuche zu ermitteln und die TCP-MSS auf dem Router zu begrenzen, der den Datenverkehr weiterleitet. Der Verbindungstyp ändert daran nichts: Ein Relay-Pfad und ein direkter Pfad verwenden dieselbe Schnittstellen-MTU.

FAQ

Woher weiß ich, ob meine Tailscale-Verbindung direkt oder über einen Relay läuft?

Führen Sie tailscale status aus und lesen Sie das Ende der Peer-Zeile. direct 203.0.113.9:41641 steht für eine direkte Verbindung, relay "tor" bedeutet, dass jedes Paket über diesen DERP-Server läuft, und peer-relay bedeutet, dass die Pakete über eine Maschine in Ihrem eigenen Tailnet laufen. Für eine zweite Prüfung führen Sie tailscale ping <peer> aus: Ein funktionierender Pfad beginnt mit DERP und gibt anschließend einen Pong mit einer normalen Adresse und einem Port aus, während ein weitergeleiteter Pfad bis zum Ende des Laufs DERP-Pongs ausgibt und mit direct connection not established endet. Senden Sie zuerst etwas Traffic an den Peer, da Tailscale einen Pfad erst bei Bedarf aufbaut.

Warum stellt mein VPS nie eine direkte Verbindung her?

Führen Sie tailscale netcheck auf dem VPS aus. Wenn UDP: false ausgegeben wird, verwirft eine Egress-Firewall ausgehende UDP-Pakete und der Daemon ist auf DERP über TCP 443 zurückgefallen. Deshalb wirkt die Maschine weiterhin als verbunden. Erlauben Sie ausgehendes UDP von Port 41641 zu jedem Ziel sowie ausgehendes UDP zu jedem Ziel auf Port 3478. Prüfen Sie sowohl die Netzwerk-Firewall Ihres Providers als auch die Firewall auf dem Server, da es sich um getrennte Kontrollen handelt und eine ufw-Regel die Firewall des Providers nicht betrifft.

Ist eine weitergeleitete Tailscale-Verbindung weniger sicher als eine direkte?

Nein. Ein DERP-Server leitet WireGuard-Pakete weiter, die er nicht entschlüsseln kann, weil die Verschlüsselungsschlüssel auf Ihren Geräten erzeugt werden und diese niemals verlassen. Der Nachteil eines Relays besteht in Latenz und Durchsatz, nicht in einer geringeren Vertraulichkeit. Der Koordinationsserver steuert jedoch, welche Geräte voneinander erfahren. Die Trennung von Schlüsselmaterial und Verbindungsmetadaten sollten Sie verstehen, bevor Sie entscheiden, wie viel davon Sie selbst hosten möchten.

Hilft die Einstellung rx-udp-gro-forwarding auf jeder Maschine?

Nein. Sie ist für Linux-Maschinen dokumentiert, die Traffic für andere weiterleiten. Dazu gehören Exit Nodes und Subnet Routers. Ein Laptop oder ein Server, der nur mit seinen eigenen Peers kommuniziert, profitiert nicht davon. Außerdem sind Tailscale 1.54 oder höher und Linux kernel 6.2 oder höher erforderlich. Prüfen Sie daher zuerst tailscale version und uname -r. Beachten Sie außerdem, dass ethtool -K nach einem Reboot zurückgesetzt wird, sofern Sie die Einstellung nicht dauerhaft speichern.

Ist Tailscale langsamer als reines WireGuard?

Beide verwenden WireGuard zur Verschlüsselung Ihres Traffics. Tailscale ergänzt den Verbindungsaufbau, den Sie bei reinem WireGuard manuell einrichten müssen. Dieser Aufbau führt manchmal dazu, dass eine Verbindung über einen Relay läuft. Reines WireGuard hat keinen Relay, auf den es zurückfallen kann: Es verbindet sich direkt oder die Verbindung schlägt vollständig fehl. Vergleichen Sie daher gleichartige Konfigurationen. Führen Sie Benchmarks mit Tailscale nur aus, wenn tailscale status direct meldet. Wenn Sie zum Vergleich die manuell konfigurierte Variante verwenden möchten, umfasst ein WireGuard-Server, den Sie selbst einrichten etwa vierzig Konfigurationszeilen. Der damit verbundene Kompromiss wird in dem Vergleich der beiden Ansätze erläutert.