Tailscale-Subnet-Router auf einem VPS einrichten

Was ein Tailscale-Subnet-Router macht

Ein Tailscale-Subnet-Router ist ein Rechner, der einen gesamten Bereich privater IP-Adressen für Ihr 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, also die Menge der Geräte, die bei einem Konto oder einer Organisation angemeldet sind. Ein Exit Node ist die Funktion, mit der dies häufig verwechselt wird, und er erfüllt die umgekehrte Aufgabe. Er leitet den gesamten Datenverkehr eines Geräts über den VPS ins Internet, sodass der VPS für dieses Gerät zum Weg ins öffentliche Internet wird.

Jeweils ein Satz. Ein Subnet-Router macht ein privates Netzwerk aus dem tailnet erreichbar. Ein Exit Node ändert, von welchem Standort Ihr öffentlicher Datenverkehr ins Internet gelangt. 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 Subnet Router 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 restlichen Segment muss nichts geändert werden. Die Datenbank hat weiterhin keine öffentliche Adresse.

Der andere Fall ist ein Netzwerk auf der von Ihrem VPS aus gesehen entfernten Seite. Das kann ein Heim- oder Büronetzwerk (local area network) hinter einem eigenen Router sein. Es kann auch ein Rack mit Geräten sein, auf denen Tailscale überhaupt nicht ausgeführt werden kann, beispielsweise ein verwalteter Switch oder ein älteres NAS mit gesperrter Firmware. Ein Linux-System in diesem Netzwerk fungiert dann für alle anderen Geräte darin als Subnet Router.

Beide Fälle haben dieselbe Voraussetzung. Der Subnet Router muss den 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 Paket-Repository von Tailscale 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 zuerst, 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 einer echten Schnittstelle auflisten, beispielsweise 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, weil jeder spätere Test davon abhängt.

IP-Weiterleitung aktivieren und über einen Neustart hinweg beibehalten

Eine Linux-Maschine verwirft jedes Paket, das nicht an sie selbst adressiert ist, solange die Weiterleitung nicht aktiviert ist. Die Weiterleitung von Paketen anderer Maschinen ist die zentrale Aufgabe eines Subnetzrouters. Dieser Schritt ist daher erforderlich.

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 dies 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 Bootvorgang verschwunden. Dadurch läuft der Subnetzrouter wochenlang und fällt dann am Morgen nach einem Neustart wegen eines Kernel-Upgrades aus. Verwirrend ist, dass nichts offensichtlich fehlerhaft aussieht. tailscale status zeigt den Knoten 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 sorgt dafür, dass sie nach einem Neustart wiederhergestellt werden.

Wenn Sie Routen mit weiterhin deaktivierter Weiterleitung bekanntgeben, warnt tailscale up bereits zu diesem Zeitpunkt mit einer Zeile ähnlich wie Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.. Lesen Sie die Ausgabe dieses Befehls, statt darüber hinwegzuscrollen.

Routen bekanntgeben

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

Ändern Sie die Einstellung stattdessen direkt auf einem VPS, der bereits bei Ihrem tailnet angemeldet ist:

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

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

Mehrere Bereiche werden als eine kommagetrennte Liste ohne Leerzeichen angegeben: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Jeder Eintrag muss eine Netzwerkadresse in CIDR-Notation sein (Classless Inter-Domain Routing, die Form 10.0.0.0/24). Wenn Sie versehentlich Ihre eigene Hostadresse angeben, 10.0.0.5/24, wird dies abgelehnt, weil die Bits nach dem Präfix nicht 0 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, keine Änderung. Bis ein Administrator sie 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 Teilnehmer eintragen kann, Datenverkehr für jeden gewünschten Bereich abfangen könnte.

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

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 deshalb die Konsole, bevor Sie andere Fehlerquellen untersuchen.

Den manuellen Schritt können Sie 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. Der Tag muss zuvor im Abschnitt tagOwners derselben Richtliniendatei vorhanden sein. Das lohnt sich, wenn Sie den VPS per Skript neu erstellen, weil ein neu erstellter Node als neuer Node gilt und seine Routen erneut nicht genehmigt sind.

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

Die Route wird jetzt angekündigt und ist freigegeben. Ihr Telefon und Ihr Mac können 10.0.0.20 erreichen. Ihr Linux-Laptop kann das nicht, und in der Administrationskonsole ist kein Problem erkennbar.

Das Akzeptieren einer Subnetzroute bedeutet, Einträge in die Routing-Tabelle des Clients zu schreiben. Unter Android, iOS, macOS, tvOS und Windows übernimmt der Tailscale-Client das für Sie. 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 dieser Rechner bereits verarbeitet. Unter Linux müssen Sie die Funktion deshalb 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. Stattdessen verwendet es die Routing-Tabelle 52 und installiert Policy-Regeln. Diese sind mit ip rule show im Prioritätsbereich 5210 bis 5270 sichtbar und leiten nicht anderweitig zugeordnete Pakete an diese Tabelle weiter. 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 keine Wirkung hatte. 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 zu seinem eigenen direkt verbundenen Subnetz über den anderen Router und nicht über die eigene Schnittstelle gesendet wird. Deaktivieren Sie --accept-routes auf einem Standby-Router in einem Hochverfügbarkeitsverbund und kündigen Sie nur Routen an.

Fehlerfall: Zwei Router kündigen sich überschneidende Bereiche an

Zwei Subnetzrouter dürfen keine identischen Bereiche ankündigen. Überschneidende Bereiche mit unterschiedlichen Präfixlängen sind zulässig, und Tailscale verwendet den spezifischsten Treffer. Wenn Router A 10.0.0.0/24 und Router B 10.0.0.0/16 ankündigt, 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 sieht so aus, als wäre die Hälfte des privaten Netzwerks ausgefallen. Die Ursache ist jedoch, dass ein Offline-Knoten das spezifischere Präfix hält. Wenn Sie Failover benötigen, lassen Sie den Router mit dem größeren Bereich zusätzlich die kleineren Präfixe ankündigen. Dann decken beide Router dieselben Adressen ab.

Die andere Überschneidung tritt näher am Client auf. Wenn Sie sich in einem Hotelnetzwerk unter 192.168.1.0/24 befinden, während Ihr Subnetzrouter 192.168.1.0/24 ankündigt, konkurrieren beide um dieselben Ziele. Welcher Eintrag gewinnt, hängt von der Plattform ab. Installieren Sie unter Linux eine Regel vor der von Tailscale verwendeten Regel, damit lokale Adressen die Haupttabelle verwenden:

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

Diese Regel bleibt nicht dauerhaft bestehen und ist beim nächsten Bootvorgang nicht mehr vorhanden. Die eigentliche Lösung besteht darin, einen privaten Bereich auszuwählen, der Ihnen in fremden Netzwerken nicht begegnet. 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 bei einem manuell konfigurierten WireGuard-VPN zum gleichen Problem: Die spezifischere lokale Route gewinnt, sodass der Datenverkehr nie in den Tunnel gelangt.

Fehlerbild: DNS wird zu einer Adresse aufgelöst, die von keiner Route abgedeckt wird

Dieses Fehlerbild 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. Das Paket an 10.0.5.20 findet dann im Tailnet keine passende Route. Es wird daher über das Standard-Gateway des Clients gesendet und geht verloren.

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

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

Wenn die Abfrage eine Adresse zurückgibt, aber ip route get nicht mit dev tailscale0 antwortet, ist der Name korrekt aufgelöst, und 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 anschließend das neue Präfix 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 Resolver verweisen, den kein Gerät erreichen kann, verliert jedes Gerät im Tailnet sofort die Namensauflösung. Das gilt auch für Geräte, die eine Sekunde zuvor noch funktioniert haben. 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 weiterhin Probleme verursacht, erklärt wie DNS über einen WireGuard-Tunnel ausfällt denselben Mechanismus ohne die zusätzliche Koordinierungsebene.

Source-NAT und Standortverbindungen

Standardmäßig ersetzt der Subnet-Router die Quelladresse jedes weitergeleiteten Pakets durch seine eigene private Adresse. 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. Firewall-Regeln nach Quelladresse und Zugriffsprotokolle liefern dadurch keine aussagekräftigen 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 den Geräten zuweist. Diese Route muss auf den Subnet-Router zeigen. Ohne diese Rückroute senden die Hosts ihre Antworten an das Standard-Gateway. Die Antworten erreichen ihr Ziel nicht, 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 Standortverbindung übernehmen zwei Subnet-Router 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 hängen bleiben, während ssh und ping funktionieren, liegt die Ursache bei der MSS (Maximum Segment Size), also der maximalen Datenmenge, die ein TCP-Paket übertragen kann. Der zusätzliche Overhead des Tunnels macht weitergeleitete Pakete für eine Verbindung dazwischen zu groß. Durch Begrenzung der MSS lässt sich das beheben:

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.

Wartungsaufgaben für einen dauerhaft laufenden Betrieb

Node-Schlüssel laufen standardmäßig nach 180 Tagen ab, seit August 2026. Wenn der Schlüssel auf einem Subnet-Router abläuft, wird der Node abgemeldet, und der gesamte angekündigte Bereich wird nicht mehr erreichbar. Eine Konfigurationsänderung gibt es dafür möglicherweise nirgends. Deaktivieren Sie den Schlüsselablauf für diese Maschine auf der Seite „Machines“ der Administrationskonsole. Dokumentieren Sie anschließend, dass Sie dies getan haben.

Tailscale bevorzugt eine direkte Verbindung zwischen Peers und wechselt auf seine Relay-Server, wenn keine direkte Verbindung hergestellt werden kann. Die Relay-Server funktionieren, erhöhen jedoch die Latenz. Bei einem VPS mit öffentlicher Adresse ist die Einrichtung einfach: Erlauben Sie eingehenden UDP-Verkehr auf Port 41641. Dann verbinden sich die meisten Peers direkt. Wenn ufw die Firewall verwaltet, beschreibt die tatsächlich erforderlichen ufw-Regeln für einen VPS die benötigte Syntax.

Zugriffsregeln bilden die andere Hälfte. In einem standardmäßigen Tailnet kann jedes Ihrer Geräte jedes andere Gerät erreichen. Eine genehmigte Route funktioniert daher unmittelbar. 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 abgedeckt.

Entscheiden Sie zuletzt, ob Sie einen Koordinationsserver verwenden möchten, den Sie nicht selbst betreiben. Die Control Plane von Tailscale ist ein gehosteter Dienst. Ihre Schlüssel bleiben auf Ihren Maschinen, das Konto und die Richtliniendatei liegen jedoch dort. Mit Headscale, dem selbst gehosteten Tailscale-Control-Server betreiben Sie diese Komponenten auf Ihrem eigenen VPS. Dafür müssen Sie den Dienst selbst warten. Wenn Sie noch zwischen diesem Modell und einer manuell geschriebenen Konfiguration abwägen, erklärt der Vergleich von WireGuard und Tailscale, welche Funktionen 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 Rechner 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 Knotens. Ein VPS kann beides sein. Dafür gibt es die separaten Flags --advertise-routes und --advertise-exit-node. Für jedes Flag ist eine eigene Genehmigung in der Admin-Konsole erforderlich.

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

Linux-Clients akzeptieren Subnet-Routen nicht automatisch. Führen Sie auf dem Client 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 der Routing-Tabelle 52 und erreicht sie über Policy-Regeln. 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 Knoten in der Admin-Konsole. Node-Keys laufen standardmäßig nach 180 Tagen ab. Ein abgelaufener Subnet-Router sieht dann wie ein Netzwerkproblem und nicht wie ein Konto-Problem aus.

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

Identische Bereiche nicht. Überlappende Bereiche mit unterschiedlichen Präfixlängen sind zulässig. Dabei wird das spezifischste Präfix verwendet. Ein Failover erfordert besondere Beachtung: Wenn der Router mit dem spezifischeren Präfix offline geht, wechselt Tailscale nicht auf die breitere Route. Der Datenverkehr wird dann beendet. 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 wird dann über das Standard-Gateway des Clients gesendet. Führen Sie auf dem Client ip route get <address> 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.