Einbahnverkehr nach Deaktivieren von Tailscale-Subnet-SNAT

Schalten Sie Quell-NAT auf einem Tailscale-Subnetzrouter ab, und der Tunnel arbeitet weiter, während die Verbindungen durch ihn hindurch zum Erliegen kommen. Anfragen erreichen das Ziel mit der eigenen Overlay-Adresse des entfernten Clients, was genau der Sinn der Änderung ist, und die Antworten brauchen jetzt einen Weg, den das LAN nie kennen musste. Ohne diesen Weg kommen die Pakete an, die Antworten verlassen das Netz über das gewöhnliche Gateway, und der Fehler zeigt sich als Firewall-Problem, das keine Firewall-Regel erklärt. Der Tunnel ist gesund; das Rückweg-Stück fehlt.

Was SNAT verdeckte

Bei aktiviertem SNAT schreibt der Router die Quelladresse vor dem Weiterleiten in das Subnetz in seine eigene LAN-Adresse um, sodass das Ziel einem Host antwortet, zu dem es bereits einen Weg kennt, und nichts weiter konfiguriert werden muss. Das Abschalten bewahrt die ursprüngliche Quelle, und das Ziel sieht dann eine Adresse innerhalb des Overlay-Bereichs statt eines Nachbarn an seinem eigenen Kabel. Diese Adresse ist real und über das Tailnet routbar, und sie ist vom LAN aus über das Standard-Gateway nicht erreichbar. Der dokumentierte Schalter ist --snat-subnet-routes=false, angewendet auf den Linux-Subnetzrouter selbst.

Es ist eine dauerhafte Einstellung und kein Schalter pro Paket, daher muss der Rückweg für jedes Zielnetz vorhanden sein, das dieser Router bedient. Das macht die Änderung zu einer Bereitstellungsentscheidung statt zu einem Häkchen. Alles, was dieser Router bedient, erbt die Anforderung im selben Moment.

Wo der Rückweg liegen kann

Drei Platzierungen sind üblich, und sie unterscheiden sich in der Reichweite, nicht in der Richtigkeit. Eine statische Route auf dem Zielhost ist die direkteste und am wenigsten skalierbare, da jedes Gerät seine eigene Kopie braucht. Eine Routentabelle in der VPC oder im Standortrouter deckt ein ganzes Netz auf einmal ab, und eine DHCP-Option mit klassenlosen statischen Routen erreicht Clients automatisch, scheitert aber still auf Geräten, die sie ignorieren.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Welche Platzierung Sie auch wählen, der nächste Hop ist die LAN-Adresse des Routers und niemals seine Tailnet-Adresse. Ein LAN-Host erreicht das Overlay erst, wenn er diese Route besitzt, also ist ein nächster Hop innerhalb des Overlays zirkulär und schickt das Paket nirgendwohin. Dieser eine Fehler erklärt die meisten Konfigurationen, die richtig aussehen und trotzdem scheitern, und er übersteht jede Prüfung, die nur die eigene Tabelle des Routers liest. Notieren Sie, welche Platzierung Sie verwendet haben, sonst testet die nächste Person die falsche.

Den Fehler als Einbahnverkehr lesen

Das Symptom ist leichter zu erkennen als die Ursache: Der Dienst antwortet auf dem Router selbst und bleibt von einem entfernten Client aus stumm. Eine Aufzeichnung am Ziel zeigt ankommende Anfragen und abgehende Antworten, was wie ein Erfolg aussieht, bis man bemerkt, wohin diese Antworten gehen. Sie gehen zum Standard-Gateway, was bedeutet, dass der eingehende Teil funktionierte und der Rückweg nicht.

Zeichnen Sie stattdessen am Router auf, denn er sieht beide Richtungen eines Austauschs und zeigt, ob eine Antwort je ankam. Erscheint die Antwort am Ziel, aber nie am Router, fehlt die Route auf der Zielseite oder ist falsch. Erscheint sie am Router und bleibt dort stehen, liegt das Problem weiter hinten und gehört zu einer anderen Untersuchung.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Ob die echte Adresse eine Route wert ist

SNAT zu behalten bleibt die einfachere Antwort, wann immer das Zielnetz nicht umkonfiguriert werden kann, und der Preis ist, dass jeder Client in den Protokollen und der Richtlinie des Ziels wie der Router aussieht. Das Abschalten ist gerechtfertigt, wenn eine Anwendung die echte Quelladresse braucht oder wenn die Netzwerkrichtlinie Clients unterscheiden muss, die sich einen Router teilen. Beide Gründe sind legitim, und keiner ist kostenlos. Der Nutzen muss es wert sein, in jedem Zielnetz eine Route zu pflegen, plus die unten beschriebene Firewall-Überprüfung.

Für ein kleines LAN zahlt sich der Tausch meist aus, für eine Vielzahl von Geräten, die keine statische Route annehmen können, meist nicht. Halten Sie die Entscheidung und den Grund neben der Routerkonfiguration fest, damit der nächste Administrator weiß, welches Verhalten absichtlich ist. Eine Voreinstellung, die niemand notiert hat, ist von einem Versehen nicht zu unterscheiden.

Firewall, Protokollierung und die doppelte Rolle

Jede Regel, die auf die LAN-Adresse des Routers passte, passt jetzt auf eine andere Quelle, einschließlich Freigaberegeln und jedes Protokollfelds, das den Router als Client festhielt. Lesen Sie diese Regeln vor dem ersten Test statt nach dem ersten Fehlschlag, denn eine Regel, die nur die Adresse des Routers erlaubt, blockiert die neue Quelle vollständig. Verengen Sie den Ersatz auf die Clients und Ports, die ihn brauchen, und bestätigen Sie dann, dass er nicht still das ganze Tailnet zulässt.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

Ein Knoten, der zugleich Exit-Node und Subnetzrouter ist, ist eine dokumentierte Kombination, die Upstream-Verkehr verlieren kann, sobald Subnetz-SNAT deaktiviert ist. Die Trennung dieser Rollen auf verschiedene Knoten beseitigt den Vorbehalt und gibt jeder Route und Firewall-Richtlinie einen einzigen Eigentümer. Müssen die Rollen zusammenbleiben, rechnen Sie mit dem Verhalten und testen Sie es, bevor Sie einen Client beschuldigen. Halten Sie Route, Schaltereinstellung und Rollenzuweisung in einer Notiz fest, denn sie werden zusammen gelesen, wenn die nächste Verbindung scheitert.