ZeroTier-Exit-Node funktioniert nicht? Route, NAT und Client prüfen

Die Routentabelle zeigt eine Standardroute über die ZeroTier-Schnittstelle, das Netzwerk meldet sich als online, und ein Browser verlässt trotzdem die lokale ISP-Adresse. Diese Kombination ist häufig und kein Fehler des Clients. Eine Standardroute sagt nur, wohin Pakete gehen sollen; am anderen Ende muss etwas sie weiterleiten und übersetzen. Drei getrennte Teile müssen zutreffen, bevor ein Exit-Node funktioniert.

Die Route existiert, aber nichts geht hinaus

Prüfen Sie zuerst die Routentabelle des Clients. Eine Zeile wie default via 10.147.20.5 dev zt0 beweist, dass die Route installiert wurde, nicht dass das Ziel den Verkehr annimmt. Der nächste Hop muss ein Mitglied sein, das bereit und in der Lage ist, sie weiterzuleiten.

Wenn dieselbe Anfrage weiterhin über die physische Schnittstelle hinausgeht, hat der Client die Route nicht installiert oder sie mit einer Metrik installiert, die gegen die lokale Standardroute verlor. Wenn die Anfrage nach der Installation der Route verschwindet, empfängt das Exit-Mitglied Pakete und kann sie nicht weiterleiten oder übersetzen. Ein Client, der die physische Standardroute behält, sendet überhaupt kein Paket an den Exit.

Diese Unterscheidung entscheidet, wo gearbeitet werden muss. Der Vergleich einer öffentlichen Adresse vor und nach der Änderung trennt eine nie genutzte Route von einer, die genutzt und verworfen wurde, und erfordert einen Befehl statt einer Durchsicht der gesamten Konfiguration. Führen Sie den Vergleich durch, bevor Sie etwas anderes ändern, damit beide Ergebnisse vom selben Ausgangszustand stammen.

Drei Teile, die alle zutreffen müssen

Ein Exit ist eine Kette, und das schwächste Glied bestimmt das Symptom. Die Tabelle unten listet die Glieder in der Reihenfolge auf, in der sie üblicherweise versagen.

Die erste Zeile ist die, die der Optionsname verbirgt. Ein Mitglied wird erst dann ein Exit, wenn sein Kernel Pakete zwischen der ZeroTier-Schnittstelle und der internetzugewandten Schnittstelle weiterleitet und wenn der Rückweg zurück in den Tunnel übersetzt wird. Ohne diese Weiterleitung ist das Mitglied ein Peer, kein Gateway.

Die Controller-Zeile ist Autorisierung, nicht Konfiguration. 0.0.0.0/0 über ein Mitglied anzukündigen, sagt jedem Client, wo der Exit ist; es macht das Mitglied nicht fähig, den Verkehr zu tragen. Es prüft auch nicht, ob das Mitglied einen funktionierenden Weg ins Internet hat. Die ZeroTier-Dokumentation zum Exit-Node behandelt dieselbe Trennung zwischen Knoten, Route und Client.

Konfigurieren Sie den Exit-Node zum Weiterleiten und Übersetzen

Aktivieren Sie die IPv4-Weiterleitung dauerhaft und fügen Sie dann Quell-NAT für Verkehr hinzu, der die WAN-Schnittstelle verlässt. Die Filterregeln müssen den weitergeleiteten Fluss in beide Richtungen erlauben, denn Weiterleitung und Übersetzung sind von der Erlaubnis getrennt:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o zt0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Ersetzen Sie zt0 und eth0 durch die Namen auf dem Host; eine für eine Beispielschnittstelle gespeicherte Regel folgt keinen Paketen auf einer echten. Machen Sie die Änderungen über den Firewall-Manager dauerhaft, dem die Regeln gehören, denn ein Befehl in einer interaktiven Shell verschwindet beim nächsten Neustart.

Läuft auf dem Host ein Firewall-Manager wie UFW oder firewalld, fügen Sie die Regeln über diesen Manager hinzu, statt iptables-Zeilen daneben zu stapeln. Zwei Eigentümer, die dieselben Ketten bearbeiten, erzeugen eine Richtlinie, die von der Startreihenfolge abhängt. Die Reihenfolge zählt, wenn der Manager eigene Ketten erzeugt. Testen Sie von einem Client aus, nachdem der Manager neu geladen wurde, nicht davor.

Kündigen Sie die Route an und akzeptieren Sie sie auf dem Client

Fügen Sie auf dem Netzwerk-Controller eine verwaltete Route für 0.0.0.0/0 hinzu, deren nächster Hop die ZeroTier-Adresse des Exit-Mitglieds ist. Erlauben Sie dann auf dem Mitglied, das sie nutzen soll, die Überschreibung für dieses Netzwerk. Die Erlaubnis ist lokal: Sie konfiguriert andere Mitglieder nicht um und ändert den Controller nicht.

zerotier-cli listnetworks
zerotier-cli set <network-id> allowDefault=1
ip route get 1.1.1.1

Der letzte Befehl sollte die ZeroTier-Schnittstelle und die Adresse des Exit-Mitglieds melden. Meldet er weiterhin die physische Schnittstelle, fehlt die Route oder eine konkurrierende Standardroute hat eine bessere Metrik.

Halten Sie die Einstellung auf das Netzwerk beschränkt, das sie braucht. Die Annahme der Standardroute global oder in einem Netzwerk zu aktivieren, das nur ein privates Subnetz bereitstellen soll, schickt Verkehr über einen Exit, der dafür nie dimensioniert wurde.

Prüfen Sie den Exit und die anderen Adressfamilien

Fordern Sie eine öffentliche Adresse von einem Dienst an, der die Quelle meldet, und vergleichen Sie sie mit der WAN-Adresse des Exit-Nodes. Laden Sie dann eine benannte Seite, um zu bestätigen, dass DNS weiterhin auflöst, und testen Sie eine wichtige Anwendung statt nur eines Browsers.

Ein Client mit dualem Stack kann seinen nativen IPv6-Pfad weiter nutzen, während IPv4 über ZeroTier hinausgeht. Soll der gesamte Verkehr verborgen oder kontrolliert werden, sind eine separate ::/0-Route und IPv6-Weiterleitung am Exit nötig, und ein IPv4-Test sagt nichts darüber.

Die umgekehrte Pfadfilterung unter Linux kann auch gültigen Exit-Verkehr am Client verwerfen. ZeroTier dokumentiert eine rp_filter-Überlegung für teilnehmende Mitglieder; ändern Sie diese Einstellung bewusst und erst, nachdem Route und NAT bestätigt sind, nicht als erstes Experiment.

Wenn die Anforderung der Zugang zu einem NAS oder einem Büro-Subnetz ist, ist eine verwaltete Route für dieses Präfix eine kleinere und sicherere Änderung als ein vollständiger Exit. Den gesamten Browserverkehr über ein anderes Gerät zu leiten, ist eine andere Entscheidung als ein privates Ziel zu erreichen, und sie verdient eine eigene Prüfung.