Warum eine genehmigte Tailscale-Subnetzroute trotzdem in einen Timeout läuft

Die Genehmigung in der Administrationskonsole wirkt wie der letzte Schritt, und sie ist es nicht. Zuerst läuft die Anwendung in einen Timeout, und erst danach stellen Sie fest, dass der Router online und die Route genehmigt ist. Die Genehmigung ist ein Verteilungsschritt, keine Berechtigung und keine Garantie für die Weiterleitung. Vier Stufen müssen zusammenpassen, bevor ein Paket einen Host hinter einem Subnetzrouter erreicht, und jede kann gelingen, während die nächste scheitert. Arbeiten Sie sie der Reihe nach ab und halten Sie bei der ersten Stufe an, die nicht trägt.

Vier Stufen, ein Fehler

Der Router kündigt das Präfix an, das Tailnet genehmigt diese Ankündigung, der Client akzeptiert die empfangene Route, und die Zugriffsrichtlinie erlaubt die konkrete Verbindung. Das sind vier getrennte Entscheidungen von drei verschiedenen Komponenten. Eine genehmigte Route besagt daher nur, dass das Netzwerk jetzt Teil der Routing-Tabelle des Tailnets ist.

Die vierte Stufe wird am häufigsten übersprungen, weil die ersten drei einen sichtbaren Zustand erzeugen. Eine Freigabe, die die eigene Tailnet-Adresse des Routers abdeckt, deckt nicht automatisch ein privates Subnetz dahinter ab. Das sind verschiedene Ziele, und die Richtlinie wird pro Ziel bewertet.

Unter Linux hat die dritte Stufe außerdem eine Voreinstellung, die Leute überrascht: das Akzeptieren von Subnetzrouten ist optional. Mehrere GUI-Clients akzeptieren angekündigte Routen standardmäßig, sodass eine gemischte Flotte eine fehlerhafte Maschine zeigen kann, während der Rest funktioniert.

Bestätigen Sie die Einstellung auf der fehlerhaften Maschine, statt eine Plattform anzunehmen. Die Route war auf den funktionierenden Maschinen nie das fehlende Teil, also lassen Sie diese beweisen, dass die Tailnet-Seite gesund ist. Die Dokumentation von Tailscale zu Subnetzroutern deckt Genehmigung, Routenannahme im Client und die Richtlinienstufe ab.

Prüfen Sie die Route dort, wo der Client läuft

Beginnen Sie beim Client, der scheitert, nicht beim Router. Bestätigen Sie, dass die Route vorhanden ist und dass die Client-Einstellung das Akzeptieren von Routen überhaupt erlaubt.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Der erste Befehl zeigt die Peer-Liste und ob der Subnetzrouter erreichbar ist, der zweite gibt die Einstellungen des Clients aus, einschließlich des Flags für die Routenannahme, und der dritte fragt den Kernel, welche Schnittstelle er für einen echten Host im Subnetz verwenden würde. Wenn der letzte Befehl die physische Schnittstelle statt der Tailscale-Schnittstelle nennt, ist die Route nie in die Tabelle gelangt. Eine fehlende Route ist ein Client-Problem, kein Genehmigungsproblem. Beheben Sie es, bevor Sie die Richtlinie betrachten.

Um unter Linux Routen zu akzeptieren, verbinden Sie sich mit dem Flag neu, statt anzunehmen, dass es gesetzt ist: tailscale up --accept-routes. Ein Client, der mit anderen Flags beigetreten ist, behält sie, bis sie geändert werden, prüfen Sie also die aktuelle Einstellung, bevor Sie eine weitere hinzufügen. Ein erneuter Aufruf des ersten Befehls nach der Änderung sollte die Route in der Tabelle zeigen.

Beweisen Sie Weiterleitung und Rückweg

Die Genehmigung konfiguriert den Router nicht zum Weiterleiten von Paketen und organisiert nicht die Antwort. Beides sind Belange auf Host-Ebene auf der LAN-Seite des Routers. Testen Sie sie auf dem Router, nicht auf dem Client.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Der erste Befehl muss 1 melden, sonst verwirft der Kernel das weitergeleitete Paket. Der zweite zeigt, ob die Maskierung der Subnetzroute die Quelle umschreibt, was das Standardverhalten und meist das ist, was Sie wollen. Der dritte zeigt, ob die Anfrage am Ziel ankommt und ob etwas zurückkommt; eine Anfrage ohne Antwort ist ein Rückwegproblem, kein Genehmigungsproblem. Lesen Sie die drei Ergebnisse zusammen, bevor Sie eines davon ändern.

Wenn die Maskierung deaktiviert wurde, braucht das Zielnetz eine Route zurück zu den Tailnet-Adressen, und jeder Hop dazwischen muss sie kennen. Die Maskierung wieder einzuschalten ist die schnellere Lösung für einen einzelnen Dienst, auf Kosten des Verbergens der ursprünglichen Client-Adresse vor dem Ziel. Dieser Kompromiss zählt, wenn das Ziel Quelladressen für Prüfzwecke protokolliert, entscheiden Sie ihn also bewusst, statt das Flag während eines Vorfalls umzulegen. Dokumentieren Sie, welche Wahl Sie getroffen haben, denn die nächste Person wird nur eines der beiden Verhalten sehen.

Lesen Sie die Zugriffsregel für die Ressource

Mit vorhandener Route und bewiesener Weiterleitung ist die verbleibende Verdächtige die Richtlinie. Lesen Sie die Freigabe, die die Verbindung erlauben soll, und prüfen Sie ihr Ziel, nicht nur ihre Quelle. Auch die Identität des Clients muss zum Selektor der Richtlinie passen, erfassen Sie sie also auf derselben Maschine, die scheitert.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Die Statusausgabe identifiziert die eigenen Adressen des Clients und die Peers, die er sieht, und damit muss der Quellselektor der Richtlinie übereinstimmen. tailscale ping belegt den Tailnet-Pfad bis zum Subnetzrouter selbst; es löst Peer-Namen und Tailnet-Adressen auf, nicht Hosts innerhalb eines angekündigten Subnetzes. Der dritte Befehl sendet ein normales ICMP-Echo über die Subnetzroute, sein Ergebnis beschreibt also das Ziel statt den Router. Eine Ablehnung auf Tailnet-Ebene kommt meist als Verweigerung zurück, während ein Paket, das hinausgeht und nie zurückkehrt, in einen Timeout läuft.

Ein fehlschlagender Name ist eine andere Frage als eine fehlschlagende Adresse; lösen Sie den Host direkt auf, bevor Sie die Route beschuldigen. Schreiben Sie die Freigabe auf den tatsächlichen Ressourcenbedarf statt auf das ganze Subnetz. Ein ganzes /24 zu öffnen, damit eine Anwendung funktioniert, ist der Weg, auf dem aus einer engen Anfrage eine breite Berechtigung wird, die später niemand zu entfernen wagt.

Wenn das Ziel ein Internet-Ausgang und kein privates Subnetz war, ist die richtige Komponente ein Exit-Node, kein Subnetzrouter, und Richtlinie und Routing unterscheiden sich entsprechend. Prüfen Sie diese Entscheidung, bevor Sie eine Freigabe erweitern. Ein Exit-Node ändert die Standardroute; ein Subnetzrouter kündigt nur ein Präfix an.