WireGuard-Peergruppen am Hub: Quelleneigentum plus Richtlinie

Ein Hub, auf dem WireGuard läuft, kann Peergruppen ohne eigene Schnittstelle oder Routingtabelle pro Gruppe getrennt halten. Zwei Mechanismen leisten die Arbeit, und ihre Verwechslung ist der übliche Grund, warum eine Richtlinie korrekt aussieht und nichts bewirkt. Eine Schicht entscheidet, wer eine Quelladresse beanspruchen darf. Die andere entscheidet, wohin dieses Paket gehen darf.

Zwei Aufgaben, getrennt gehalten

Die Tunnelschicht beantwortet eine enge Frage: Hat der Schlüssel dieses Peers diese innere Quelladresse autorisiert. Die Weiterleitungsschicht beantwortet eine weitere: Darf dieses Paket zu jenem Ziel hinausgehen. Keine beantwortet die Frage der anderen, und keine ist für sich eine vollständige Zugriffsrichtlinie.

Diese Trennung ist der Grund, warum ein Peer authentifiziert und korrekt adressiert sein kann und dennoch einen Host nicht erreicht, den er nicht erreichen sollte. Sie erklärt auch das Gegenteil: Eine Firewallregel, die alles erlaubt, beweist nichts darüber, wer welche Adresse beanspruchen darf.

Entwerfen Sie beide Schichten zusammen und testen Sie dann beide. Eine Konfiguration, die in einer Schicht korrekt und in der anderen ungetestet ist, scheitert offen oder geschlossen, je nach Standard.

Geben Sie jedem Peer nur seine eigene Adresse

Peers mit mehreren Hosts verleiten dazu, auf der Serverseite den gesamten Gruppenbereich zu gewähren. Diese Erlaubnis ist ein Anspruch auf eine Quelladresse, also kann ein kompromittierter oder falsch konfigurierter Client jede Adresse im Bereich vorweisen, und der Tunnel akzeptiert sie. Weisen Sie pro Peer eine /32 für seine eigene innere Adresse zu. Setzen Sie Gruppenbereiche nur auf den Clients, wo sie beschreiben, welche Ziele dieser Client erreichen darf statt welche Quellen er verwenden darf.

Die Firewall gleicht dann eine Quelle ab, der sie trauen kann. Eine für den Gruppenbereich geschriebene Regel bleibt eine nützliche Gruppierung, und sie wird erst dann bedeutsam, wenn kein einzelner Peer eine Adresse beanspruchen kann, die zu einem anderen Mitglied gehört.

Schreiben Sie die Weiterleitungsrichtlinie, die Gruppen trennt

Der interessante Verkehr tritt hier über dieselbe Tunnelschnittstelle ein und aus, er durchläuft also den Weiterleitungspfad und nicht den Eingabepfad des Hosts. Regeln gehören in die vorhandene Weiterleitungskette des Firewall-Managers, dem der Host gehört, und sie sind Fragmente, kein vollständiges Regelset.

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

Die ersten beiden Regeln erlauben Verkehr innerhalb jeder Gruppe. Die letzte blockiert alles andere, was diese Schnittstelle durchquert, und das erzeugt die Isolation zwischen den Gruppen. Fügen Sie explizite Regeln für die andere Adressfamilie hinzu, falls Sie sie brauchen, denn ein für IPv4 geschriebenes Drop erlaubt oder beschreibt kein IPv6-Verhalten.

Die Reihenfolge entscheidet, ob die Richtlinie greift

Die Regelreihenfolge ist wichtiger als das Fragment selbst. Eine generische Regel, die bestehende Verbindungen akzeptiert und vor diesen Einträgen steht, lässt einen alten gruppenübergreifenden Fluss weiterlaufen, sodass die Isolation nur für neue Verbindungen gilt. Entscheiden Sie vor dem Neuladen, welches dieser beiden Ergebnisse Sie wollen.

Ein Akzepturteil ist über Ketten am selben Hook hinweg auch nicht immer endgültig. Läuft später eine andere Basiskette, ist die wirksame Richtlinie die Kombination, also prüfen Sie die Zähler statt die Datei, die Sie bearbeitet haben. Zähler sind der billigste verfügbare Beleg. Eine Regel ohne Paketzähler trifft nicht, und eine Regel, die trifft, während eine spätere Kette akzeptiert, sagt Ihnen, dass das Drop an der falschen Stelle steht.

Testen Sie die Matrix, nicht die Dateizahl

Bauen Sie eine kleine Matrix erwarteter Ergebnisse und prüfen Sie jede Zelle. Gruppe A zu Gruppe A sollte funktionieren, Gruppe B zu Gruppe B sollte funktionieren, und A zu B sollte nicht, in beide Richtungen und für beide Adressfamilien, wenn Sie sie unterstützen.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

Die ersten beiden zeigen, was konfiguriert ist. Der Ping von einem Mitglied der falschen Gruppe zeigt, was tatsächlich passiert. Die conntrack-Auflistung zeigt, ob ein älterer Fluss noch akzeptiert wird, und genau so tritt eine Isolationsänderung still nicht in Kraft.

Hostdienste auf dem Hub und der Zugang zu einem LAN dahinter sind getrennte Pfade mit getrennter Richtlinie. Notieren Sie, welche davon die Matrix abdeckt, denn ein Test, der nur Peer-zu-Peer-Verkehr prüft, sagt über keinen von beiden etwas aus.