Tailscale-Subnetzrouter auf einem VPS einrichten

Was ein Tailscale-Subnetzrouter macht

Ein Tailscale-Subnetzrouter ist ein Rechner, der einen vollständigen Bereich privater IP-Adressen in Ihrem tailnet bekannt gibt, sodass jedes Gerät im tailnet Adressen in diesem Bereich erreichen kann, auch wenn dort kein Gerät Tailscale ausführt. Ihr tailnet ist Ihr privates Tailscale-Netzwerk: die Gesamtheit der Geräte, die bei einem Konto oder einer Organisation angemeldet sind. Ein Exit Node wird häufig damit verwechselt, erfüllt aber die umgekehrte Aufgabe. Er leitet den gesamten Datenverkehr eines Geräts über den VPS nach außen, sodass der VPS zum Weg dieses Geräts ins öffentliche Internet wird.

Jeweils ein Satz. Ein Subnetzrouter macht ein privates Netzwerk aus dem tailnet erreichbar. Ein Exit Node bestimmt, über welchen Anschluss Ihr öffentlicher Datenverkehr das Netzwerk verlässt. Wenn Sie die zweite Funktion benötigen, lesen Sie stattdessen wie Sie einen Tailscale-Exit-Node auf einem VPS betreiben. Dafür gibt es separate Flags, und ein VPS kann beide Funktionen gleichzeitig übernehmen, aber sie lösen unterschiedliche Probleme und fallen auf unterschiedliche Weise aus.

Wenn ein VPS als Subnetzrouter benötigt wird

Der häufigste Fall ist ein privates Netzwerk, das Ihr Provider bereits bereitstellt. Ihr VPS hat eine öffentliche Adresse und eine zweite Schnittstelle in einem privaten Segment. Die anderen Server in diesem Segment haben überhaupt keine öffentliche Adresse: eine Datenbank unter 10.0.0.20 und ein Backup-Ziel unter 10.0.0.30. Installieren Sie Tailscale auf einem VPS und kündigen Sie 10.0.0.0/24 an. Dann kann Ihr Laptop diese privaten Adressen direkt erreichen. Am Segment selbst muss nichts geändert werden. Die Datenbank bleibt weiterhin ohne öffentliche Adresse. Wenn Sie aus diesem Segment nur eine Webanwendung an einem einzigen Port benötigen, ist die Ankündigung des gesamten Bereichs nicht erforderlich. Tailscale Serve stellt stattdessen HTTPS an diesem einzelnen Port bereit. Dasselbe gilt für einen Daemon, der absichtlich nur an localhost gebunden ist, etwa dsh, das ohne Terminal unter systemd läuft. Eine Tailnet-Adresse auf diesem VPS ersetzt den SSH-Tunnel, den Sie sonst für den Zugriff auf die Benutzeroberfläche offen halten müssten.

Der andere Fall ist ein Netzwerk auf der vom VPS aus gesehen entfernten Seite. Das kann ein Heim- oder Büronetzwerk (Local Area Network) hinter einem eigenen Router sein oder ein Rack mit Geräten, auf denen Tailscale nicht ausgeführt werden kann, etwa ein Managed Switch oder ein älteres NAS mit gesperrter Firmware. Ein Linux-System in diesem Netzwerk wird zum Subnetzrouter für alle anderen Geräte darin. Zu Hause ist dieses System häufig eine kleine VM auf einem bereits betriebenen Hypervisor. Vor der Entscheidung, an welchem Ende des Tunnels Ihre Dienste laufen sollen, sollten Sie die Kosten eines Proxmox-Hosts zu Hause mit denen eines gemieteten VPS vergleichen.

Beide Fälle haben dieselbe Voraussetzung. Der Subnetzrouter muss den von ihm angekündigten Bereich bereits erreichen können. Dafür verwendet er seine eigene Routing-Tabelle und seine eigene Firewall. Tailscale stellt diese Verbindung nicht her. Tailscale transportiert den Datenverkehr zum Router und übergibt ihn zur Weiterleitung an den Kernel.

Tailscale installieren und zuerst die lokale Route prüfen

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

Das Skript erkennt die Distribution, fügt das Tailscale-Paket-Repository hinzu, installiert den Befehl tailscale und den Daemon tailscaled und aktiviert anschließend den Dienst. Prüfen Sie dies mit systemctl is-active tailscaled. Der Befehl sollte active ausgeben.

Prüfen Sie vor allem anderen, ob die VPS das Netzwerk erreichen kann, das Sie bekanntgeben möchten.

ip route show
ping -c3 10.0.0.20

ip route show muss den privaten Bereich auf einem echten Interface auflisten, etwa 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Wenn der Ping hier auf dem Router selbst fehlschlägt, kann kein Tailscale-Flag das Problem beheben. Die Ursache liegt in der Netzwerkkonfiguration der VPS oder in einer Firewall auf dem Zielhost. Beheben Sie das zuerst, da jeder spätere Test davon abhängt.

IP-Forwarding aktivieren und einen Reboot überstehen lassen

Ein Linux-System verwirft jedes Paket, das nicht an das System selbst adressiert ist, solange Forwarding nicht aktiviert ist. Das Weiterleiten der Pakete anderer Systeme ist die zentrale Aufgabe eines Subnet-Routers. Dieser Schritt ist daher nicht optional.

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

Prüfen Sie die Einstellung mit sysctl net.ipv4.ip_forward. Der Befehl sollte net.ipv4.ip_forward = 1 ausgeben.

Dieser Schritt wird häufig nur teilweise korrekt umgesetzt. sudo sysctl -w net.ipv4.ip_forward=1 wirkt sofort, ist aber beim nächsten Boot wieder verschwunden. Dadurch läuft der Subnet-Router wochenlang und fällt dann am Morgen nach einem Reboot infolge eines Kernel-Upgrades aus. Verwirrend ist, dass zunächst nichts defekt aussieht. tailscale status zeigt den Node weiterhin als online an, die Administrationskonsole zeigt die Route weiterhin als genehmigt an, und die Clients haben die Route weiterhin installiert. Die Pakete erreichen den VPS, aber der Kernel verwirft sie, ohne etwas zu protokollieren. Erst das Schreiben der Werte in /etc/sysctl.d/99-tailscale.conf stellt sie nach einem Reboot wieder her.

Wenn Sie Routen ankündigen, obwohl Forwarding weiterhin deaktiviert ist, gibt tailscale up zu diesem Zeitpunkt eine Warnung aus. Sie enthält eine Zeile ähnlich wie Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.. Lesen Sie die Ausgabe dieses Befehls, anstatt darüber hinwegzuscrollen.

Routen bekanntgeben

sudo tailscale up --advertise-routes=10.0.0.0/24

Auf einem VPS, der bereits bei Ihrem Tailnet angemeldet ist, ändern Sie die Einstellung stattdessen direkt:

sudo tailscale set --advertise-routes=10.0.0.0/24

Verwenden Sie tailscale set für jede spätere Änderung. Wenn Sie tailscale up mit nur einem Flag erneut ausführen, werden die Flags zurückgesetzt, die Sie nicht erneut angegeben haben. Die CLI bricht mit einer Fehlermeldung ab. Sie weist darauf hin, dass bei dieser Änderungsmethode alle Flags angegeben werden müssen, die nicht den Standardwert haben. tailscale set ändert eine Einstellung und lässt die übrigen unverändert.

Mehrere Bereiche werden als eine durch Kommas getrennte Liste ohne Leerzeichen angegeben: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Jeder Eintrag muss eine Netzwerkadresse in CIDR-Notation (Classless Inter-Domain Routing, das Format 10.0.0.0/24) sein. Wenn Sie versehentlich Ihre eigene Hostadresse angeben, 10.0.0.5/24, wird der Eintrag abgelehnt, weil die Bits nach dem Präfix nicht auf null gesetzt sind. Die Fehlermeldung nennt das Präfix, das Sie wahrscheinlich gemeint haben. Um die Bekanntgabe zu beenden, setzen Sie mit sudo tailscale set --advertise-routes= eine leere Liste.

Route in der Admin-Konsole genehmigen

Das Ankündigen einer Route ist eine Anfrage und keine Änderung. Solange ein Administrator sie nicht genehmigt, erhält kein Client die Route, und kein Ziel im Bereich ist erreichbar. Das ist beabsichtigt, weil ein Rechner, der sich selbst in die Routing-Tabelle aller anderen Rechner eintragen kann, Datenverkehr für jeden beliebigen Bereich abfangen könnte.

Genehmigen Sie die Route auf der Seite „Machines“ der Admin-Konsole. Der VPS wird mit einem Subnetz-Badge angezeigt. Öffnen Sie seine Zeile, suchen Sie den Abschnitt für Subnetze, bearbeiten Sie die Routeneinstellungen, aktivieren Sie die Route und speichern Sie.

Die Genehmigung gilt pro Präfix. Wenn Sie heute 10.0.0.0/24 und im nächsten Monat 192.168.50.0/24 ankündigen, wird das neue Präfix zunächst nicht genehmigt, während das alte weiterhin funktioniert. Eine genehmigte und eine ignorierte Route sehen auf dem VPS identisch aus. Prüfen Sie daher die Konsole, bevor Sie etwas anderes untersuchen.

Sie können den manuellen Schritt mit einem autoApprovers-Block in der Tailnet-Richtliniendatei überspringen:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

Starten Sie den Node anschließend mit diesem Tag, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router. Die Route wird dann in dem Moment genehmigt, in dem sie angekündigt wird. Das Tag muss zuvor im Abschnitt tagOwners derselben Richtliniendatei vorhanden sein. Das lohnt sich, wenn Sie den VPS aus einem Skript neu erstellen, weil ein neu erstellter Node ein neuer Node ist und seine Routen erneut nicht genehmigt sind.

Warum Linux-Clients die Route ohne --accept-routes ignorieren

Die Route wird jetzt angekündigt und ist genehmigt. Ihr Smartphone und Ihr Mac erreichen 10.0.0.20. Ihr Linux-Laptop kann das nicht, und in der Administrationskonsole gibt es keinen Hinweis auf ein Problem.

Das Akzeptieren einer Subnetzroute bedeutet, Einträge in die Routing-Tabelle des Clients zu schreiben. Unter Android, iOS, macOS, tvOS und Windows erledigt der Tailscale-Client das automatisch. Unter Linux geschieht das nicht, weil ein Linux-Rechner häufig als Server oder Router eingesetzt wird und seine Routing-Tabelle absichtlich konfiguriert wurde. Eine stillschweigend aus dem Netzwerk gelernte /24 könnte den Datenverkehr beeinträchtigen, den der Rechner bereits verarbeitet. Unter Linux müssen Sie die Funktion daher auf jedem Client ausdrücklich aktivieren:

sudo tailscale set --accept-routes

Prüfen Sie anschließend, wo die Route eingetragen wurde:

ip route show table 52
ip route get 10.0.0.20

Tailscale legt akzeptierte Routen unter Linux nicht in der Haupt-Routing-Tabelle ab. Sie werden in die Routing-Tabelle 52 eingetragen. Zusätzlich installiert Tailscale Policy-Regeln, die mit ip rule show im Prioritätsbereich 5210 bis 5270 sichtbar sind und nicht anderweitig zugeordnete Pakete an diese Tabelle weiterleiten. Daher listet ip route show allein 10.0.0.0/24 niemals auf. Wer nur diesen Befehl prüft, kommt zu dem Schluss, dass --accept-routes nichts bewirkt hat. ip route show table 52 zeigt den tatsächlichen Zustand an und sollte den angekündigten Bereich auf tailscale0 auflisten.

Eine Ausnahme sollten Sie kennen. Wenn dieser Linux-Knoten selbst ein zweiter Subnetzrouter für sein eigenes lokales Netzwerk ist, sorgt --accept-routes dafür, dass Datenverkehr für sein eigenes direkt verbundenes Subnetz über den anderen Router statt über die eigene Schnittstelle gesendet wird. Deaktivieren Sie --accept-routes auf einem Standby-Router in einem Hochverfügbarkeitsverbund und kündigen Sie dort ausschließlich Routen an.

Fehlerbild: Zwei Router veröffentlichen sich überschneidende Netze

Zwei Subnetzrouter dürfen keine identischen Bereiche veröffentlichen. Sich überschneidende Bereiche mit unterschiedlichen Präfixlängen sind zulässig, und Tailscale verwendet die spezifischste Übereinstimmung. Wenn Router A 10.0.0.0/24 und Router B 10.0.0.0/16 veröffentlicht, wird der Datenverkehr zu 10.0.0.20 über A geleitet.

Überraschend ist das Verhalten, wenn A offline geht. Tailscale weicht nicht auf die weniger spezifische Route aus. Der Datenverkehr zu 10.0.0.20 wird unterbrochen, während der Datenverkehr zu 10.1.0.20 weiterhin über B funktioniert. Das Fehlerbild sieht so aus, als wäre die Hälfte des privaten Netzwerks nicht erreichbar. Die Ursache ist jedoch, dass ein offline gegangener Knoten das spezifischere Präfix hält. Wenn Sie Failover benötigen, muss der Router mit dem größeren Bereich zusätzlich die kleineren Präfixe veröffentlichen. Dann decken beide dieselben Adressen ab.

Die andere Überschneidung liegt näher beim Client. Wenn Sie sich in einem Hotelnetzwerk unter 192.168.1.0/24 befinden, während Ihr Subnetzrouter 192.168.1.0/24 veröffentlicht, konkurrieren beide um dieselben Ziele. Welche Route gewinnt, hängt von der Plattform ab. Installieren Sie unter Linux eine Regel vor der von Tailscale selbst verwendeten Regel, damit lokale Adressen die Haupttabelle verwenden:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

Diese Regel ist nicht persistent und nach dem nächsten Boot nicht mehr vorhanden. Die eigentliche Lösung ist die Wahl eines privaten Bereichs, auf den Sie unterwegs nicht treffen werden. 192.168.0.0/24 und 192.168.1.0/24 sind auf den meisten Heimroutern die Standardwerte. Wählen Sie daher einen Bereich innerhalb von 10.0.0.0/8, den Sie bewusst festgelegt haben. Dieselbe Kollision führt aus demselben Grund auch bei einem manuell konfigurierten einfachen WireGuard-VPN zu Problemen: Die spezifischere lokale Route gewinnt, sodass der Datenverkehr nie in den Tunnel gelangt.

Fehlerfall: DNS wird zu einer Adresse aufgelöst, für die keine Route gilt

Dieser Fehlerfall ist schwer zu diagnostizieren, weil nichts einen Fehler meldet. Der Name wird aufgelöst. Die Verbindung läuft in einen Timeout.

Angenommen, db.internal.example.com wird über Ihren privaten Nameserver zu 10.0.5.20 aufgelöst und Sie haben 10.0.0.0/24 angekündigt. Die Abfrage ist erfolgreich, weil die DNS-Auflösung (Domain Name System) und das IP-Routing getrennte Schritte sind und keiner den anderen prüft. Für das Paket zu 10.0.5.20 gibt es im Tailnet dann keine passende Route. Es verlässt das Netzwerk über das Standard-Gateway des Clients und geht verloren.

Mit zwei Befehlen lassen sich die beiden Teile getrennt prüfen:

nslookup db.internal.example.com
ip route get 10.0.5.20

Wenn die Abfrage eine Adresse zurückgibt, ip route get aber nicht mit dev tailscale0 antwortet, ist der Name korrekt. Die Route fehlt. Kündigen Sie einen Bereich an, der die Adresse abdeckt, entweder 10.0.0.0/16 oder ein zweites explizites Präfix. Genehmigen Sie das neue Präfix anschließend in der Konsole.

Auf dem Nameserver selbst gibt es eine entsprechende Fehlerquelle. Wenn Sie in der Administratorkonsole einen globalen Nameserver unter einer privaten Adresse wie 10.0.0.53 festlegen, muss diese Adresse innerhalb einer genehmigten Route liegen. Andernfalls können Ihre Geräte den Resolver überhaupt nicht erreichen. Wenn Sie die Option zum Überschreiben lokaler DNS-Server aktivieren und dabei auf einen nicht erreichbaren Resolver verweisen, verlieren alle Geräte im Tailnet gleichzeitig die Namensauflösung, auch die Geräte, bei denen sie eine Sekunde zuvor noch funktioniert hat. Kündigen Sie zuerst die Route zum Resolver an und genehmigen Sie sie. Ändern Sie anschließend die DNS-Einstellung. Wenn DNS innerhalb eines Tunnels immer wieder Probleme verursacht, beschreibt wie DNS über einen WireGuard-Tunnel ausfällt denselben Mechanismus ohne die zusätzliche Koordinationsebene.

Source NAT und Standort-zu-Standort-Verbindungen

Standardmäßig schreibt der Subnetzrouter die Quelladresse jedes weitergeleiteten Pakets in seine eigene private Adresse um. Das ist SNAT (Source Network Address Translation). Dadurch funktionieren Antworten, ohne dass Änderungen im privaten Netzwerk erforderlich sind: Die Datenbank unter 10.0.0.20 antwortet dem VPS, den sie bereits erreichen kann. Der Nachteil ist, dass die Datenbank jede Verbindung aus dem Tailnet so sieht, als käme sie vom VPS. Regeln der Firewall nach Quelladresse und Zugriffsprotokolle liefern dadurch keine verwertbaren Informationen.

Deaktivieren Sie SNAT unter Linux, wenn die tatsächliche Tailnet-Adresse des Clients erhalten bleiben soll:

sudo tailscale set --snat-subnet-routes=false

Die Hosts im privaten Netzwerk benötigen dann eine Rückroute zu 100.64.0.0/10, dem Bereich, den Tailscale Geräten zuweist. Diese Route muss auf den Subnetzrouter zeigen. Ohne diese Rückroute senden die Hosts ihre Antworten an das Standardgateway. Dort kommen sie nicht am Ziel an, und die Verbindungen bleiben nach dem ersten Paket hängen. Fügen Sie die statische Route auf dem Gateway des privaten Netzwerks hinzu, oder lassen Sie SNAT aktiviert.

Bei einer Standort-zu-Standort-Verbindung übernehmen zwei Subnetzrouter diese Aufgabe gleichzeitig. Jeder Router kündigt sein eigenes Netzwerk an und akzeptiert das Netzwerk des anderen:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

Führen Sie auf dem anderen Router den entsprechenden Befehl mit dessen eigenem Bereich aus. Die beiden Bereiche müssen unterschiedlich sein. Wenn große Übertragungen ins Stocken geraten, während ssh und ping funktionieren, liegt die Ursache bei MSS (Maximum Segment Size), also der maximalen Datenmenge, die ein TCP-Paket transportiert. Der Overhead des Tunnels macht weitergeleitete Pakete für einen Abschnitt der Verbindung zu groß. MSS-Clamping behebt dieses Problem:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Speichern Sie diese Regel mit iptables-persistent. Andernfalls verschwindet sie beim nächsten Boot.

Wartungsarbeiten für einen zuverlässigen Betrieb

Node-Schlüssel laufen standardmäßig nach 180 days ab, seit August 2026. Läuft der Schlüssel auf einem Subnet Router ab, meldet sich der Node ab. Der gesamte angekündigte Bereich ist dann nicht mehr erreichbar. Es gibt dabei keine Konfigurationsänderung, die den Ausfall erklärt. Deaktivieren Sie den Schlüsselablauf für diese Maschine auf der Seite Machines in der Administrationskonsole. Dokumentieren Sie anschließend, dass Sie dies getan haben.

Tailscale bevorzugt eine direkte Verbindung zwischen Peers. Wenn keine direkte Verbindung möglich ist, verwendet Tailscale seine Relay-Server. Diese funktionieren, erhöhen aber die Latenz. Bei einem VPS mit öffentlicher Adresse ist die Einrichtung einfach: Erlauben Sie eingehenden UDP-Verkehr auf Port 41641. Die meisten Peers verbinden sich dann direkt. Wenn ufw die Firewall verwaltet, beschreibt der Abschnitt zu den tatsächlich benötigten ufw-Regeln für einen VPS die erforderliche Syntax.

Zugriffsregeln bilden die zweite Hälfte. In einem standardmäßigen Tailnet kann jedes Ihrer Geräte jedes andere Gerät erreichen. Eine genehmigte Route funktioniert daher direkt. Sobald Sie eine ACL-Richtlinie erstellen, muss die Zielseite einer Regel den privaten Bereich angeben. 10.0.0.20 ist keine Tailnet-Adresse und wird von Regeln gegen Tailnet-IP-Adressen oder Tags nicht erfasst.

Entscheiden Sie schließlich, ob Sie einen Koordinationsserver verwenden möchten, den Sie nicht selbst betreiben. Tailscales Control Plane ist ein gehosteter Dienst. Ihre Schlüssel bleiben auf Ihren Maschinen. Das Konto und die Richtliniendatei liegen jedoch dort. Welche Aktionen mit einer kompromittierten Control Plane oder einem gestohlenen Identitäts-Login tatsächlich möglich wären, sollten Sie klären, bevor Sie diesem Dienst Zugriff auf Ihr privates Netzwerk geben. Tailscales Vertrauensmodell zeigt, wo diese Grenze liegt. Die Kosten sind selten der Grund für einen Wechsel. Der kostenlose Tarif umfasst bis zu sechs Benutzer mit unbegrenzt vielen eigenen Geräten. Ein Subnet Router, den Sie unter einem Tag starten, wird jedoch anders gezählt als ein Subnet Router, bei dem Sie sich als Benutzer anmelden. Danach richtet sich die Rechnung nach Personen und nicht nach Maschinen. Daher sollten Sie vor dem Hinzufügen eines weiteren Kontos prüfen, was ein Haushalt oder ein fünfköpfiges Team nach dem Ende des kostenlosen Tarifs tatsächlich bezahlt. Mit Headscale, dem selbst gehosteten Tailscale-Control-Server, betreiben Sie diese Komponente auf Ihrem eigenen VPS. Dafür müssen Sie sie selbst warten. Eine weitere Lösung für dasselbe Problem besteht darin, auch Tailscales Clients nicht zu verwenden. Das Self-Hosting des NetBird-VPN-Servers legt die Koordinationsschicht und die zugehörigen Mesh-Clients auf einer von Ihnen kontrollierten Maschine ab. Wenn Sie noch zwischen diesem Modell und einer manuell geschriebenen Konfiguration wählen, erklärt der Vergleich von WireGuard und Tailscale, welchen Nutzen die Koordinationsschicht bietet und welche Kosten damit verbunden sind.

FAQ

Was ist der Unterschied zwischen einem Subnet-Router und einem Exit-Node?

Ein Subnet-Router kündigt einen Bereich privater Adressen an. Dadurch können Geräte im Tailnet Maschinen erreichen, auf denen Tailscale nicht ausgeführt wird. Ein Exit-Node kündigt sich als Route für das gesamte Internet an. Dadurch sendet ein Gerät seinen gesamten Datenverkehr über die öffentliche Adresse dieses Nodes. Ein VPS kann beides sein. Dafür gibt es die separaten Flags --advertise-routes und --advertise-exit-node. Beide benötigen eine eigene Freigabe in der Admin-Konsole.

Warum ignoriert mein Linux-Client die angekündigte Subnet-Route?

Linux-Clients akzeptieren Subnet-Routen nicht automatisch. Sie müssen sie auf dem Client aktivieren. Führen Sie sudo tailscale set --accept-routes aus. Prüfen Sie anschließend mit ip route show table 52 und nicht mit ip route show. Tailscale installiert akzeptierte Routen in Routing-Tabelle 52 und erreicht sie über Policy Rules. Deshalb werden sie in der Haupttabelle nicht aufgeführt, und eine funktionierende Route scheint zu fehlen.

Mein Subnet hat nach einem Reboot nicht mehr funktioniert. Was ist passiert?

Wahrscheinlich ist IP-Forwarding deaktiviert. Ein mit sysctl -w gesetzter Wert bleibt nach einem Reboot nicht erhalten. Schreiben Sie ihn daher in /etc/sysctl.d/99-tailscale.conf und bestätigen Sie ihn mit sysctl net.ipv4.ip_forward. Wenn Forwarding aktiviert ist und der Bereich weiterhin nicht erreichbar ist, prüfen Sie den Node in der Admin-Konsole. Node-Keys laufen standardmäßig nach 180 days ab. Ein abgelaufener Subnet-Router sieht daher wie ein Netzwerkfehler und nicht wie ein Konto-Problem aus.

Können zwei Subnet-Router denselben Bereich ankündigen?

Nicht identische Bereiche. Überlappende Bereiche mit unterschiedlichen Präfixlängen sind möglich. Dabei wird das spezifischste Präfix verwendet. Ein Failover erfordert besondere Sorgfalt: Wenn der Router mit dem spezifischeren Präfix offline geht, verwendet Tailscale nicht automatisch die weiter gefasste Route. Der Datenverkehr wird daher unterbrochen. Für ein echtes Standby-Paar sollten beide Router dieselben spezifischen Präfixe ankündigen.

Der Hostname wird aufgelöst, aber die Verbindung läuft in einen Timeout. Warum?

DNS-Auflösung und Routing sind getrennte Schritte. Ein Name kann zu einer Adresse aufgelöst werden, für die keine genehmigte Route vorhanden ist. Das Paket verlässt den Client dann über dessen Standard-Gateway. Führen Sie ip route get <address> auf dem Client aus. Wenn die Antwort dev tailscale0 nicht enthält, kündigen Sie einen Bereich an, der diese Adresse abdeckt, und genehmigen Sie das neue Präfix in der Admin-Konsole.