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 entfernten Seite des VPS. Dabei kann es sich um ein Heim- oder Büro-LAN (Local Area Network) hinter einem eigenen Router handeln oder um eine Gruppe von Geräten, auf denen Tailscale überhaupt nicht ausgeführt werden kann, etwa einen Managed Switch oder ein älteres NAS mit gesperrter Firmware. Ein Linux-System in diesem Netzwerk wird zum Subnet Router für alle anderen Geräte darin. Der vorgeschaltete Heimrouter benötigt dafür keine Portweiterleitung. Wie Tailscale NAT ohne das Öffnen eines Router-Ports durchquert erklärt, warum das funktioniert und wann Tailscale auf einen Relay ausweicht. Zu Hause ist dieses System häufig eine kleine VM auf einem Hypervisor, den Sie bereits betreiben. Die Kosten eines Proxmox-Hosts zu Hause im Vergleich zu einem gemieteten VPS sollten Sie klären, bevor Sie entscheiden, auf welcher Seite des Tunnels Ihre Dienste laufen sollen.

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-Weiterleitung aktivieren und über einen Reboot hinweg beibehalten

Ein Linux-System verwirft jedes Paket, das nicht an das System selbst adressiert ist, solange die Weiterleitung nicht aktiviert ist. Das Weiterleiten von Paketen anderer Systeme ist die zentrale Aufgabe eines Subnetzrouters. 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 funktioniert sofort, ist aber nach dem nächsten Boot nicht mehr aktiv. Dadurch läuft der Subnetzrouter wochenlang und fällt dann am Morgen nach einem Reboot infolge eines Kernel-Upgrades aus. Verwirrend ist, dass äußerlich nichts fehlerhaft wirkt. 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 nach /etc/sysctl.d/99-tailscale.conf stellt die Weiterleitung nach einem Reboot wieder her.

Wenn Sie Routen ankündigen, obwohl die Weiterleitung weiterhin deaktiviert ist, warnt tailscale up Sie bereits zu diesem Zeitpunkt. Unter Linux ähnelt die Meldung Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.. Lesen Sie die Ausgabe dieses Befehls, statt 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 kündigen sich überschneidende Bereiche an

Zwei Subnetzrouter können identische Bereiche ankündigen. So funktioniert ein Hochverfügbarkeitspaar: Jeder Router kündigt exakt dieselben Präfixe an, und Clients können bei einem Ausfall auf den jeweils anderen Router wechseln. Sich überschneidende Bereiche mit unterschiedlichen Präfixlängen sind ebenfalls zulässig. Tailscale verwendet dabei die spezifischste Übereinstimmung. 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 wechselt nicht auf die weniger spezifische Route, weil ein offline befindlicher Router seine Ankündigung nicht zurückziehen kann und Clients weiterhin das spezifischere Präfix bevorzugen. Der Datenverkehr zu 10.0.0.20 wird unterbrochen. Der Datenverkehr zu 10.0.1.20, das nur durch B's /16 abgedeckt wird, funktioniert dagegen weiterhin über B. Das Fehlerbild sieht so aus, als sei ein Teil des privaten Netzwerks nicht erreichbar. Die Ursache ist ein offline befindlicher Knoten, der weiterhin das spezifischere Präfix hält. Wenn Sie Failover benötigen, lassen Sie den Router mit dem größeren Bereich zusätzlich die engeren Präfixe ankündigen. Dann decken beide Router dieselben Adressen ab.

Die andere Überschneidung liegt näher am Client. Wenn Sie sich in einem Hotelnetzwerk unter 192.168.1.0/24 befinden und 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 selbst, 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 besteht darin, einen privaten Bereich auszuwählen, dem Sie außerhalb Ihrer eigenen Umgebung nicht begegnen. 192.168.0.0/24 und 192.168.1.0/24 sind auf den meisten Heimroutern voreingestellt. Wählen Sie daher einen Bereich innerhalb von 10.0.0.0/8, den Sie bewusst festgelegt haben. Dieselbe Kollision führt auch bei einem einfachen WireGuard-VPN, das Sie manuell konfigurieren, zu Problemen. Aus demselben Grund gewinnt die spezifischere lokale Route, sodass der Datenverkehr den Tunnel nicht erreicht.

Fehlerbild: DNS wird in eine Adresse aufgelöst, für die keine Route gilt

Dieses Fehlerbild ist schwer zu debuggen, 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 in 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 und das IP-Routing getrennte Schritte sind und keiner dieser Schritte den anderen prüft. Das Paket an 10.0.5.20 findet anschließend im Tailnet keine passende Route. Es verlässt das Netzwerk daher ü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, aber ip route get nicht mit dev tailscale0 antwortet, ist der Name korrekt aufgelöst und die Route fehlt auf diesem Client. Prüfen Sie auf einem Linux-Client zuerst, ob --accept-routes aktiviert ist. Ohne diese Option wird keine Subnetzroute installiert, selbst wenn ein genehmigtes Präfix die Adresse bereits abdeckt. Wenn die Option aktiviert ist und kein genehmigtes Präfix die Adresse abdeckt, kündigen Sie entweder 10.0.0.0/16 oder ein zweites explizites Präfix an, das die Adresse abdeckt. Genehmigen Sie anschließend das neue Präfix in der Konsole.

Auf dem Nameserver selbst gibt es eine entsprechende Fehlerquelle. Wenn Sie in der Administrationskonsole einen globalen Nameserver unter einer privaten Adresse wie 10.0.0.53 festlegen, muss diese Adresse innerhalb einer genehmigten Route liegen. Andernfalls können Geräte, die sich nicht in diesem privaten Netzwerk befinden, den Resolver überhaupt nicht erreichen. Wenn Sie die Option zum Überschreiben lokaler DNS-Server aktivieren und dabei auf einen Resolver verweisen, den niemand erreichen kann, verlieren alle Geräte im Tailnet gleichzeitig die Namensauflösung, auch die Geräte, die noch einen Moment zuvor 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, 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.

Wartung für einen stabilen Betrieb

Ob der Schlüssel dieses Rechners abläuft, hängt davon ab, wie Sie ihn angemeldet haben. Ein Knoten, der wie im obigen Beispiel autoApprovers unter einem Tag eingerichtet wurde, hat ab dem ersten Tag und der ersten Authentifizierung standardmäßig eine deaktivierte Schlüsselablaufzeit. Für diese Konfiguration ist hier nichts weiter erforderlich. Ein Knoten, bei dem Sie sich als Benutzer anmelden, verwendet die Schlüsselablaufzeit des Tailnets. Bei einem neuen Tailnet beträgt sie standardmäßig 180 days und kann seit October 2026 auf einen Wert zwischen 1 und 180 days gesetzt werden. Wenn der Schlüssel eines solchen Subnet Routers abläuft, werden die Verbindungen zu ihm und von ihm beendet. Der gesamte angekündigte Adressbereich wird unerreichbar, ohne dass eine Konfigurationsänderung die Ursache erkennen lässt. Deaktivieren Sie bei einem als Benutzer angemeldeten Router den Schlüsselablauf im Menü am Ende seiner Zeile auf der Seite Machines der Administrationskonsole. Dokumentieren Sie anschließend, dass Sie dies getan haben.

Tailscale bevorzugt eine direkte Verbindung zwischen Peers und verwendet Relay-Server, wenn keine direkte Verbindung möglich ist. Die Relays funktionieren, erhöhen aber die Latenz. Bei einem VPS mit öffentlicher Adresse ist die Konfiguration einfach: Erlauben Sie eingehenden UDP-Verkehr auf Port 41641. Dann verbinden sich die meisten Peers direkt. Wenn der Verkehr zum privaten Bereich langsamer ist, als es die Verbindung zum VPS erwarten lässt, sollten Sie zuerst prüfen, ob Ihr Client den Subnet Router direkt oder über ein Relay erreicht. Wenn ufw die Firewall verwaltet, beschreibt die tatsächlich erforderlichen ufw-Regeln für einen VPS die Syntax.

Zugriffsregeln bilden die andere Hälfte. In einem Standard-Tailnet kann jedes Ihrer Geräte jedes andere erreichen. Eine genehmigte Route funktioniert daher sofort. Sobald Sie eine ACL-Richtlinie erstellen, muss die Zielseite einer Regel den privaten Bereich abdecken. Sie können ihn entweder ausdrücklich angeben oder den Platzhalter * verwenden. Dieser schließt genehmigte Subnet-Routen ein, weil 10.0.0.20 keine Tailnet-Adresse ist und nicht von Regeln abgedeckt wird, die sich auf Tailnet-IP-Adressen oder Tags beziehen.

Entscheiden Sie schließlich, ob Sie einen Koordinationsserver nutzen möchten, den Sie nicht selbst betreiben. Die Control Plane von Tailscale ist ein gehosteter Dienst. Ihre Schlüssel bleiben auf Ihren Rechnern, aber das Konto und die Policy-Datei liegen dort. Entscheidend ist, was jemand mit einer kompromittierten Control Plane oder einem gestohlenen Identitäts-Login tatsächlich tun könnte. Das sollten Sie klären, bevor Sie diesem Dienst eine Route in Ihr privates Netzwerk geben. Das Vertrauensmodell von Tailscale zeigt, wo diese Grenze verläuft. Die Kosten sind selten der Grund für einen Wechsel, da der kostenlose Tarif bis zu sechs Benutzer mit einer unbegrenzten Anzahl eigener Geräte abdeckt. Ein Subnet Router, den Sie unter einem Tag starten, wird jedoch anders gezählt als ein Router, der mit Ihrem Benutzerkonto angemeldet ist. Danach richtet sich die Rechnung nach Personen und nicht nach Geräten. Deshalb sollten Sie vor dem Hinzufügen des Kontos, das die kostenlose Grenze überschreitet, prüfen, was ein Haushalt oder ein Team mit fünf Personen nach Ablauf des kostenlosen Tarifs tatsächlich bezahlt. Der Betrieb von Headscale, dem selbst gehosteten Tailscale-Control-Server, hält diese Komponente auf Ihrem eigenen VPS. Dafür müssen Sie sie selbst warten. Eine andere Lösung für dasselbe Problem besteht darin, auch die Tailscale-Clients nicht zu verwenden. Wenn Sie den NetBird-VPN-Server selbst hosten, liegen die Koordinationsschicht und die zugehörigen Mesh-Clients auf einem von Ihnen kontrollierten Rechner. Beide verwenden darunter WireGuard. Bei einem Wechsel ändern sich daher vor allem die Punkte, die der Vergleich von NetBird und Tailscale bewertet: Wer die Control Plane betreibt, wie Sie die Zugriffsregel für Ihren privaten Netzwerkbereich formulieren und wie der Datenverkehr weitergeleitet wird, wenn Peers keine direkte Verbindung herstellen können. Wenn Sie noch zwischen diesem Modell und einer manuell erstellten Konfiguration wählen, erklärt der Vergleich von WireGuard und Tailscale, welchen Nutzen die Koordinationsschicht bietet und welche Kosten sie verursacht.

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 Tailnet-Geräte Maschinen erreichen, auf denen Tailscale nicht ausgeführt wird. Ein Exit Node kündigt sich als Route zum gesamten Internet an. Ein Gerät sendet dann seinen gesamten Datenverkehr über die öffentliche Adresse dieses Knotens. Ein VPS kann beides sein. Dafür gibt es die getrennten Flags --advertise-routes und --advertise-exit-node. Für jedes Flag ist eine eigene Genehmigung in der Administrationskonsole erforderlich.

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

Linux-Clients übernehmen 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 genehmigte Routen in Routing-Tabelle 52 und verwendet Policy Rules, um sie zu erreichen. Die Haupttabelle enthält sie daher nicht. Eine funktionierende Route kann dadurch so aussehen, als würde sie fehlen.

Mein Subnet funktioniert nach einem Reboot nicht mehr. 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 prüfen 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 Administrationskonsole. Bei einem als Benutzer angemeldeten Router läuft der Schlüssel standardmäßig nach 180 days ab. Ein abgelaufener Subnet Router sieht daher wie ein Netzwerkfehler und nicht wie ein Kontoproblem aus. Bei einem unter einem Tag eingerichteten Router ist der Schlüsselablauf standardmäßig deaktiviert. Prüfen Sie bei diesem Router daher andere Ursachen.

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

Ja. Identische Bereiche sind die Grundlage eines Hochverfügbarkeits-Paars. Beide Router kündigen exakt dieselben Präfixe an. Überlappende Bereiche mit unterschiedlichen Präfixlängen sind ebenfalls möglich. Dabei hat das spezifischste Präfix Vorrang. Beim Failover ist Vorsicht erforderlich: Wenn der Router mit dem spezifischeren Präfix ausfällt, 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, die von keiner genehmigten Route abgedeckt 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 auf einem Linux-Client dev tailscale0 nicht enthält, prüfen Sie zuerst, ob --accept-routes aktiviert ist. Ist dies der Fall, kündigen Sie einen Bereich an, der diese Adresse abdeckt, und genehmigen Sie das neue Präfix in der Administrationskonsole.