Sie sitzen an einem Linux-Laptop, tailscale status listet die anderen Maschinen auf, und das NAS unter 10.80.0.25 läuft weiterhin in einen Timeout. Das Tailnet ist gesund, der Subnetzrouter ist online, und nichts in der Ausgabe des Clients sagt, warum das LAN dahinter nicht erreichbar ist. Der folgende Rundgang bewegt sich von diesem Symptom nach außen: das Flag auf diesem Client, dann die Ankündigung auf dem Router, dann die Freigabe, dann die Richtlinie und erst dann das Ziel selbst. Jedes Tor scheitert mit demselben Timeout, deshalb zählt die Reihenfolge mehr als die Befehle.

Was der Linux-Client nicht installieren will

Tailscale-Clients unter Linux akzeptieren beworbene Subnetzrouten nicht, solange Sie sie nicht darum bitten. Ohne diese Einstellung tritt der Client dem Tailnet bei und erreicht Peer-Adressen, während jedes vom Router beworbene Präfix ungenutzt bleibt. Die Voreinstellung ist Absicht, und deshalb sieht das Symptom wie ein defekter Router aus und nicht wie eine lokale Entscheidung.

Zwei verschiedene Dinge heißen hier Routing, und nur eines davon gehört Ihnen. Der Router kündigt ein Präfix im Tailnet an; Ihre Maschine entscheidet, ob sie es installiert. Ein Fehler auf einer der beiden Seiten erzeugt denselben Timeout, weshalb Raten einen Nachmittag kostet. Finden Sie heraus, welche Seite sich weigert, bevor Sie etwas bearbeiten.

Routenannahme für diese Maschine einschalten

Setzen Sie die Voreinstellung am Client und schauen Sie dann, was sich geändert hat, statt anzunehmen, der Befehl habe gewirkt. Die aktuelle Form wendet die Einstellung an, ohne den Anmeldeablauf zu wiederholen, was zählt, wenn Sie mitten in einer Sitzung sind.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale installiert akzeptierte Routen unter Linux in einer eigenen Tabelle, ein Präfix in Tabelle 52 ist also ein direkter Beleg dafür, dass dieser Client die Ankündigung installiert hat. Fehlt Ihr Bereich in dieser Tabelle, hören Sie auf: Das Problem ist lokal, und keine Arbeit am Router wird es ändern.

Ältere Clients bieten dieselbe Voreinstellung als Flag des Anmeldebefehls an, also ist sudo tailscale up --accept-routes der Rückfall, wenn tailscale set fehlt. Nutzen Sie ihn, statt Routen von Hand zu bearbeiten, denn der Daemon schreibt seine eigene Tabelle neu, und Ihre Änderung verschwindet beim nächsten Verbindungsaufbau. Prüfen Sie die Version, bevor Sie einen Befehl aus einem älteren Beitrag kopieren.

Ankündigung und Freigabe getrennt prüfen

Auf dem Subnetzrouter muss das Präfix angekündigt werden, und der Kernel muss Pakete zwischen Schnittstellen weiterleiten. Ankündigung ohne Weiterleitung liefert eine freigegebene Route, die Verkehr still verwirft, und das ist das häufigste halbfertige Setup.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Vergleichen Sie das angekündigte Präfix Zeichen für Zeichen mit der Adresse, die Sie tatsächlich erreichen wollen. Ein Router, der 10.70.0.0/24 ankündigt, sagt nichts über ein NAS unter 10.80.0.25, und die Abweichung ist in jeder Statusausgabe unsichtbar, weil beide Zahlen gleich plausibel aussehen. Die meisten Berichte über eine kaputte Route enden hier. Korrigieren Sie die Ankündigung, bevor Sie etwas Weiteres anfassen.

Die Freigabe ist das nächste Tor, und sie wird leicht übersprungen, wenn der Router aus einer Shell konfiguriert wurde. Die Ankündigung muss für dieses Gerät in der Administrationskonsole aktiviert sein, bevor andere Maschinen sie nutzen dürfen. Routen am Client zu akzeptieren, genehmigt nichts und hebelt keine Zugriffsregel aus.

Die private Adresse vor dem Hostnamen prüfen

Eine erfolgreiche Verbindung zur eigenen Tailnet-Adresse des Routers beweist, dass das Tailnet funktioniert, was Sie schon wussten. Der nützliche Test ist der Dienst, den Sie wirklich brauchen, zuerst gegen die private Adresse, damit ein DNS-Fehler nicht als Routingfehler auftreten kann.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

Antwortet die Adresse und der Hostname nicht, haben Sie ein Namensauflösungsproblem und sollten aufhören, es als Routenproblem zu behandeln. Antwortet keines von beiden, gehen Sie einen Abschnitt zurück und bestätigen Sie, dass die Ankündigung die Adresse abdeckt. Die beiden Fehler sehen aus Sicht der Anwendung identisch aus und werden an verschiedenen Stellen behoben.

Eine lokale Prüfung lohnt sich, bevor Sie das Tailnet beschuldigen. Wenn Ihr aktuelles LAN dasselbe Präfix wie das entfernte Subnetz verwendet, bevorzugt der Kernel die direkt verbundene Route, und der Verkehr verlässt die Maschine nie; genau das passiert, wenn ein Zuhause und ein Büro beide 192.168.1.0/24 gewählt haben.

Warum ein Client-Flag keine Router-Einstellung ist

Das sind verschiedene Rollen mit verschiedenen Anforderungen, und ein Client-Flag auf einen Router zu kopieren ist der Weg, auf dem ein funktionierendes Tailnet eine Schleife bekommt. Eine Maschine, die Routen ankündigt, braucht Weiterleitung, Firewall-Regeln, die den weitergeleiteten Verkehr erlauben, und eine Entscheidung, welche Präfixe sie ankündigt. Nichts davon ist durch --accept-routes impliziert.

Die Dokumentation zu Subnetzroutern warnt davor, die Routenannahme auf redundanten Routern zu aktivieren, die ein Präfix ankündigen, da ein Standby-Knoten bereits lokalen Verkehr durch den aktiven Knoten nach außen drücken kann. Betreiben Sie ein HA-Paar, behandeln Sie das als Designvorgabe und nicht als Fußnote, und entscheiden Sie, welcher Knoten das Präfix besitzt, bevor Sie es auf beiden freigeben. Auf einem einzelnen Router liest sich dieselbe Warnung als Erinnerung, dass die Annahme zu den Clients gehört und nicht zu der Maschine, die ankündigt. Notieren Sie, welches Tor geschlossen war.

Für einen gewöhnlichen Client endet die Reihenfolge mit dem Anwendungstest, der am Anfang scheiterte. Für den Router prüfen Sie Weiterleitung, Ankündigung, Freigabe und Firewall in dieser Reihenfolge, denn das erste fehlende erzeugt genau den Timeout, mit dem Sie begonnen haben.

Ähnliche Artikel