Tailscale –accept-routes macht dein LAN kaputt? So fixt du es mit einer ip rule

Du schaltest auf einem Linux-Server --accept-routes ein, damit er die Subnetze an deinem zweiten Standort erreicht. Kurz danach hängen SSH-Sessions zu Geräten im eigenen LAN, das NAS antwortet zäh oder gar nicht mehr, und der Drucker im Flur ist verschwunden. Ich bin in meinem Setup mit zwei Standorten über genau dieses Verhalten gestolpert. In diesem Guide zeige ich dir, wie du die Ursache findest und wie du sie mit einer einzigen Routing-Regel dauerhaft fixt.

Kurz erklärt

• Der Fix schickt Traffic in dein lokales LAN wieder direkt über die Netzwerkkarte des Hosts.
• Er ist für dich, wenn ein Linux-Host im LAN Subnet-Routen von Tailscale annimmt und eine dieser Routen dein eigenes LAN abdeckt.
• Du brauchst Root-Zugriff auf den Host, systemd und ein paar Minuten Zeit.
• Am Ende hast du eine Regel, die einen Reboot und Neustarts von Tailscale übersteht.

Was dabei im Hintergrund passiert

Ein Subnet Router ist ein Tailscale-Gerät, das ein ganzes lokales Netz (zum Beispiel 192.168.1.0/24) ins Tailnet weiterreicht. Andere Geräte im Tailnet können dieses Netz dann erreichen, ohne dass dort überall Tailscale läuft. Wie ich meine zwei Standorte so verbunden habe, beschreibe ich in Mein Homelab an zwei Standorten.

Linux-Geräte nehmen solche Routen standardmäßig nicht an. Erst mit --accept-routes übernimmt der Host sie. Tailscale schreibt sie dann in eine eigene Routing-Tabelle mit der Nummer 52. Die normalen Routen deines Systems stehen in der Tabelle main, deshalb siehst du die Tailscale-Routen mit einem einfachen ip route auch nicht. Welche Tabelle der Kernel benutzt, entscheiden Policy-Routing-Regeln, kurz ip rule. Jede Regel hat eine Priorität, und die kleinere Zahl wird zuerst geprüft. Tailscale setzt seine Regeln laut eigener Doku in den Bereich 5200 bis 5500, aktuell auf 5210, 5230, 5250 und 5270. Die Regel bei 5270 schickt alles in Tabelle 52.

Die Regel für die Tabelle main kommt erst bei Priorität 32766. Steht in Tabelle 52 also eine Route, die dein eigenes LAN enthält, gewinnt sie, egal wie gut die direkte Route in main passt. Das passiert zum Beispiel, wenn der andere Standort dasselbe /24 benutzt wie du, wenn dort ein größeres Netz wie 192.168.0.0/16 beworben wird oder wenn ein zweiter Subnet Router im eigenen LAN dein Netz ankündigt. Dein Host schickt dann Pakete an den Nachbarn im selben Raum durch den Tunnel.

Voraussetzungen

• Ein Linux-Host mit Tailscale, auf dem --accept-routes aktiv ist (Debian, Ubuntu, ein Proxmox-Host oder ein LXC)
• Root-Rechte oder sudo
• Das Paket iproute2 (liefert den Befehl ip, ist auf fast jedem System schon drauf)
• Du kennst dein lokales Subnetz. In diesem Guide ist das 192.168.1.0/24, ersetze es überall durch deins.
• Am besten eine zweite Zugriffsmöglichkeit auf den Host (Konsole in Proxmox oder Monitor), falls du dich beim Testen aussperrst

Schritt 1: Prüfen, ob Tailscale den LAN-Traffic übernimmt

Schau dir zuerst die Regeln an:

ip rule show

Mit aktivem Tailscale sieht die Ausgabe ungefähr so aus:

0:      from all lookup local
5210:   from all fwmark 0x80000/0xff0000 lookup main
5230:   from all fwmark 0x80000/0xff0000 lookup default
5250:   from all fwmark 0x80000/0xff0000 unreachable
5270:   from all lookup 52
32766:  from all lookup main
32767:  from all lookup default

Danach schaust du, was in Tabelle 52 steht:

ip route show table 52

Achte auf Einträge mit dev tailscale0, die dein LAN enthalten. Das kann 192.168.1.0/24 selbst sein oder ein größeres Netz, in dem es liegt. Der eindeutigste Test ist ip route get mit der IP eines Geräts aus deinem LAN:

ip route get 192.168.1.20

Steht in der Antwort dev tailscale0 table 52, hast du das Problem gefunden. Richtig wäre deine LAN-Schnittstelle, zum Beispiel dev eth0 oder auf einem Proxmox-Host dev vmbr0.

Schritt 2: Die Regel einmal von Hand setzen

Der Fix ist eine eigene Regel mit einer kleineren Prioritätszahl als die von Tailscale. Sie sagt: Alles, was in mein LAN geht, schaut zuerst in die Tabelle main. Genau diesen Weg beschreibt auch Tailscale selbst in seinen Troubleshooting-Docs zu überlappenden Subnetzen.

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

Teste direkt danach noch einmal mit ip route get 192.168.1.20. Jetzt sollte die LAN-Schnittstelle auftauchen und kein table 52 mehr. Die Regel ist allerdings nach dem nächsten Reboot wieder weg. Darum kümmerst du dich im nächsten Schritt.

Schritt 3: Die Regel mit einem systemd-Service dauerhaft machen

Ein Oneshot-Service ist eine systemd-Unit, die beim Start einmal einen Befehl ausführt und danach nicht weiterläuft. Mit RemainAfterExit=yes gilt sie trotzdem als aktiv, und beim Stoppen räumt ExecStop die Regel wieder auf. Prüf zuerst, wo ip bei dir liegt:

command -v ip

Auf aktuellem Debian und Ubuntu ist das /usr/sbin/ip. Lege dann die Unit an:

sudo nano /etc/systemd/system/lan-route-fix.service

[Unit]
Description=Lokales LAN vor Tailscale-Routen bevorzugen
Wants=network-online.target
After=network-online.target tailscaled.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/usr/sbin/ip rule del to 192.168.1.0/24 lookup main priority 2500
ExecStart=/usr/sbin/ip rule add to 192.168.1.0/24 lookup main priority 2500
ExecStop=/usr/sbin/ip rule del to 192.168.1.0/24 lookup main priority 2500

[Install]
WantedBy=multi-user.target

Die Zeile mit ExecStartPre löscht eine eventuell schon vorhandene Regel, damit du sie nicht doppelt anlegst. Das Minus vor dem Pfad sagt systemd, dass ein Fehler an dieser Stelle egal ist, zum Beispiel wenn die Regel noch gar nicht existiert. Jetzt aktivierst und startest du den Service:

sudo systemctl daemon-reload
sudo systemctl enable --now lan-route-fix.service

Hast du mehrere lokale Subnetze am Host, zum Beispiel ein eigenes VLAN für IoT, ergänzt du pro Netz eine eigene ExecStart– und ExecStop-Zeile (systemd erlaubt mehrere davon bei Type=oneshot). Nutzt dein Host systemd-networkd, geht das auch über einen Abschnitt [RoutingPolicyRule] in der .network-Datei deiner LAN-Schnittstelle. Auf diesen Weg verweist auch die Tailscale-Doku.

So prüfst du, ob es läuft

• systemctl status lan-route-fix.service zeigt active (exited). Das ist bei einem Oneshot-Service richtig so.
• ip rule show enthält eine Zeile 2500: from all to 192.168.1.0/24 lookup main, und zwar über den Tailscale-Regeln.
• ip route get 192.168.1.20 zeigt deine LAN-Schnittstelle.
• ip route get mit einer IP aus dem Subnetz des anderen Standorts zeigt weiterhin dev tailscale0 table 52. So weißt du, dass die Routen über Tailscale noch funktionieren.
• Nach einem sudo reboot sind die Regel und beide Tests unverändert.

Typische Probleme

Der Service startet nicht

Meldet systemctl status etwas wie No such file or directory, stimmt der Pfad zu ip nicht. Trag den Pfad ein, den command -v ip ausgibt.

Der andere Standort ist nicht mehr erreichbar

Ist die Regel da, aber das entfernte Subnetz antwortet nicht mehr, hast du vermutlich ein zu großes Netz in die Regel geschrieben, etwa ein /16, das auch das Subnetz am anderen Standort enthält. Die Regel darf nur dein lokales Netz abdecken. Benutzen beide Standorte exakt dasselbe /24, kann dieser Host das entfernte Netz grundsätzlich nicht sauber erreichen. Dann hilft nur ein Umnummerieren.

Laptops und wechselnde WLANs

Auf einem Laptop, der ständig das Netz wechselt, solltest du die Regel nicht einsetzen. Tailscale weist selbst darauf hin, dass dieser Workaround nur bei festen Netzen und festen Schnittstellen sinnvoll ist. In einem fremden WLAN mit derselben Adressierung würde dein Traffic sonst ins falsche Netz gehen.

Die Regel ist plötzlich weg

Ist der LAN-Zugriff wieder langsam, prüf mit ip rule show, ob deine Regel noch da ist. Ein manuelles ip rule flush oder ein anderes Netzwerk-Tool kann sie entfernen. Ein sudo systemctl restart lan-route-fix.service setzt sie neu.

Alternativen zur ip rule

Die Regel ist ein Workaround. Sauberer ist es, das Problem gar nicht erst entstehen zu lassen:

• Routen nur dort annehmen, wo du sie brauchst. Braucht der Host den anderen Standort gar nicht, schaltest du es mit sudo tailscale set --accept-routes=false wieder ab.
• Keine überlappenden Subnetze bewerben. Ein Subnet Router sollte nur die Netze ankündigen, die wirklich an seinem Standort liegen, und kein großzügiges /16.
• Pro Standort ein eigenes Subnetz verwenden, zum Beispiel 192.168.1.0/24 am einen und 192.168.2.0/24 am anderen Standort. Dann kann sich nichts überschneiden.
• Bei zwei Subnet Routern im selben LAN für Hochverfügbarkeit empfiehlt Tailscale in der Doku zu High Availability, dort nur --advertise-routes zu setzen und --accept-routes wegzulassen.

Ein Hinweis noch zu tailscale up: Wenn du damit Optionen änderst, musst du alle bisher gesetzten Flags erneut angeben. tailscale set ändert nur die eine Option, die du angibst, und ist deshalb für solche Änderungen bequemer.

Fazit

Wenn ein Linux-Host nach --accept-routes sein eigenes LAN nicht mehr richtig erreicht, zeigt dir ip route get in Sekunden, ob Tabelle 52 schuld ist. Die Regel mit Priorität 2500 schickt dein lokales Netz zurück in die Tabelle main, und der Oneshot-Service setzt sie bei jedem Boot neu. Planst du dein Netz gerade erst, gib jedem Standort ein eigenes Subnetz, dann brauchst du den Fix gar nicht. Wenn du wissen willst, wann ein Host im LAN plötzlich nicht mehr erreichbar ist, hilft dir Uptime Kuma mit ntfy-Push.

Hat dir der Guide geholfen? Dann spendier mir gern einen Kaffee auf Ko-fi. Damit bleibt MappleBox werbefrei.

Weitere Guides

• Mini-PC fürs Homelab: Welcher Minisforum zu deinem Setup passt
• Plex auf LG TV: kein Ton bei DTS und wie du es mit Apple TV löst
• Mein Homelab an zwei Standorten: Berlin und Frankreich im Überblick