ZeroTier in ein LAN: UFW-Routenregeln statt einer Portfreigabe

Einen Drucker im Büro-LAN über ein ZeroTier-Mitglied zu erreichen klingt nach einer Regel, ist aber tatsächlich drei Entscheidungen an drei verschiedenen Stellen. Das Overlay muss wissen, wo das LAN liegt, der Linux-Host muss bereit sein, Pakete weiterzuleiten, und das LAN muss wissen, wie es die Antwort zurückschickt. Eine eingehende Regel, die einen Port am Gateway öffnet, berührt nichts davon. Sie ist das falsche Werkzeug am richtigen Host.

Drei Aufgaben, drei Zuständigkeiten

Die verwaltete Route gehört zur ZeroTier-Netzkonfiguration. Sie teilt den Mitgliedern mit, dass ein Präfix über eine bestimmte Mitgliedsadresse erreichbar ist.

Die Weiterleitung gehört dem Linux-Kernel und dem, der seine Firewall-Richtlinie besitzt. Er entscheidet, ob ein Paket, das über das Overlay ankommt, die physische Schnittstelle wieder verlässt. Ein Host, der nicht weiterleitet, verwirft das Paket stillschweigend, nachdem er es angenommen hat. Der Absender sieht eine Zeitüberschreitung, und im Dienstprotokoll erscheint nichts.

Der Rückweg gehört dem LAN. Dessen Hosts und dessen Router müssen wissen, dass das Overlay-Präfix über die LAN-Adresse Ihres Gateways erreichbar ist, oder irgendetwas muss den Verkehr übersetzen, damit sich die Frage gar nicht stellt.

Jedes davon kann korrekt sein, während die anderen scheitern, und deshalb beweist ein Test, der nur das Gateway anpingt, nichts über den Dienst dahinter.

Richten Sie die verwaltete Route auf das Mitglied

Fügen Sie eine Route für das vorgesehene LAN-Präfix über die Overlay-Adresse des Gateways hinzu, nicht über seine LAN-Adresse. Die Overlay-Adresse ist die, die andere Mitglieder erreichen können; die LAN-Adresse ist nur auf dem Kabel sinnvoll.

Mitglieder müssen verwaltete Routen akzeptieren, damit das Design funktioniert, und ihre eigenen lokalen Netze dürfen das von Ihnen angekündigte Präfix noch nicht verwenden. Ein entfernter Laptop, der zu Hause auf 192.168.60.0/24 sitzt, kann nicht zugleich 192.168.60.0/24 über das Overlay routen.

Halten Sie das angekündigte Präfix so schmal, wie die Aufgabe es zulässt. Ein größeres Aggregat anzukündigen, um die Präferenz zu beeinflussen, kann auch Adressraum beanspruchen, der Ihnen nicht gehört, und der daraus entstehende Konflikt zeigt sich auf den Geräten, die mit beiden Netzen verbunden sind. Es kann außerdem ein Mitglied dazu bringen, einen Weg zu bevorzugen, der nirgendwo hinführt. Halten Sie die Route ehrlich und lassen Sie die Richtlinie den Rest erledigen.

Schreiben Sie das Präfix und die Mitgliedsadresse in dieselbe Notiz wie die Firewall-Regeln, denn der häufigste Fehler ist eine Route, die auf das falsche Mitglied zeigt.

Aktivieren Sie die Weiterleitung im Kernel

Lesen Sie den laufenden Weiterleitungswert, bevor Sie etwas ändern, und machen Sie die Einstellung dann über den Mechanismus dauerhaft, den Ihr System bereits nutzt, nicht über einen einmaligen Befehl, der beim Neustart verschwindet.

Wenn UFW die Richtlinie besitzt, drücken seine Routenregeln die Weiterleitung für ein Paar aus Quelle, Ziel und Schnittstelle aus. Sie sind getrennt von eingehenden Regeln, die einen Dienst am Gateway selbst öffnen:

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

Der Schnittstellenname ist das tatsächliche Overlay-Gerät auf diesem Host, das Sie mit ip link auslesen können; er ist keine feste Zeichenkette über Installationen hinweg. Wenn der Host standardmäßig weiterleitet und UFW nicht im Weg ist, wird die Routenregel ignoriert, und die Kernel-Einstellungen sind das, worauf es ankommt.

Wählen Sie, wie Antworten zurückkommen

Bei Quellenerhaltung sieht der LAN-Dienst die echte Overlay-Adresse und antwortet darauf. Das erfordert eine Route auf dem LAN-Host oder dessen Router, die das Overlay-Präfix auf Ihr Gateway zeigt, und das ist eine Änderung außerhalb der Linux-Kiste.

Wenn diese Route nicht hinzugefügt werden kann, lässt eine begrenzte Quellenübersetzung die Anfrage so aussehen, als käme sie vom Gateway im LAN. Antworten kehren dann lokal zurück, und es ist keine Änderung am LAN-Routing nötig, zum Preis des Verlusts der ursprünglichen Quelle in den Dienstprotokollen.

Begrenzen Sie die Übersetzung auf die Overlay-Quelle und das konkrete LAN-Ziel. Alles zu übersetzen, was die LAN-Schnittstelle verlässt, ist die breite Variante, die später jeden überrascht, der die Regeln liest, und sie verbirgt außerdem Verkehr, der hätte blockiert werden sollen.

Keine der beiden Optionen gewährt unaufgeforderten Zugriff vom LAN zurück auf beliebige Overlay-Mitglieder. Wenn das gewünscht ist, ist es eine eigene Regel mit eigener Prüfung.

Testen Sie von einem echten Mitglied aus

Verbinden Sie sich von einem anderen Mitglied, nicht vom Gateway, und fordern Sie einen erlaubten Dienst an. Versuchen Sie dann einen Dienst, der geschlossen bleiben soll, und wiederholen Sie beide Tests nach einem erneuten Verbinden und nach einem Neustart des Gateways.

Ein Mitglied, das ONLINE meldet, oder ein erfolgreicher Ping auf die Overlay-Adresse des Gateways validiert weder die Route noch die Weiterleitungsregel noch den Rückweg:

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

Der zweite Befehl zeigt, welche Schnittstelle das Paket zum LAN-Host nutzen würde, und der dritte zeigt, ob die Routenregel in der von Ihnen beabsichtigten Form existiert. Wenn beides richtig aussieht und der Dienst trotzdem ausläuft, ist der Rückweg der verbleibende Verdächtige.