Routing mit WireGuard. Habe eine funktionierende Lösung, aber es fühlt sich wie ein Hack an

Routing mit WireGuard. Habe eine funktionierende Lösung, aber es fühlt sich wie ein Hack an

Ich versuche, den Datenverkehr aus einem Docker-Netzwerk umzuleiten. Ich habe Wireguard installiert und ausgeführt, und anders als in den Beispielen in der Dokumentation, die den GESAMTEN Datenverkehr basierend auf dem Ziel über das VPN leiten, versuche ich, nur EINEN TEIL des Datenverkehrs basierend auf dem Quellnetzwerk, der Richtlinienweiterleitung und dann dem Ziel umzuleiten.

Im Wesentlichen möchte ich, dass der gesamte Datenverkehr von 10.30.0.0 (Docker Bridge-Netzwerk) über die wg0-Schnittstelle läuft, mit Ausnahme des Datenverkehrs, der zum selben Netzwerk oder meinem LAN zurückgeht. Also im Wesentlichen nur ausgehender Internetverkehr.

Bei mir funktioniert es ... irgendwie ... mit statischen Routen.

post-up ip rule add from 10.30.0.0/16 table 200
post-up ip route add default via a.b.c.d metric 2 table 200
post-up ip route add blackhole default metric 3 table 200
post-up ip route add 192.168.0.0/16 via 192.168.0.1 table 200
post-up ip route add 10.30.0.0/16 via 10.30.0.1 table 200

Bei Verwendung von Tabelle 200 für den gesamten Datenverkehr von 10.30.0.0 erfolgt die Standardroute über wg0. Die Fallback-Route ist ein Blackhole, ein Kill Switch, falls wg0 ausfällt.

Die nächsten beiden Routen kümmern sich um das interne Routing um wg0, da die Container sonst nicht über die Netzwerke miteinander kommunizieren können oder auf Web-GUIs nicht zugegriffen werden kann. Das funktioniert perfekt.

AUSSER ich rufe diese Routen in /etc/network/interfaces.d/wg0 auf, damit die Schnittstellen erstellt und beim Booten mit den richtigen Routen aufgerufen werden. Bis auf diese Route ist alles in Ordnung:

post-up ip route add 10.30.0.0/16 via 10.30.0.1 table 200

Es schlägt fehl, weil die Docker-Bridge noch nicht aktiv ist, wenn wg0 hochfährt. Daher kann die Route nicht erstellt werden, da das Gateway fehlt. Vorerst habe ich es zusammengehackt und „@reboot“ in cron verwendet, um diese Route zu erstellen, nachdem das Docker-Netzwerk hochgefahren ist.

Gibt es eine elegantere Lösung? Ich habe überlegt, alle Pakete von 10.30.0.0 zu markieren, die nicht für 10.30.0.0 oder 192.168.0.0 bestimmt sind, und (iptables -s 10.30.0.0/16 ! -d 192.168.0.0/16 usw. usw.) auszuführen, um diese Route nicht verwenden zu müssen, aber ich komme beim besten Willen nicht dahinter, wie das geht.

Ich bin für jede Hilfe dankbar

Antwort1

Ich habe es gelöst, indem ich die Haupttabelle für diese lokalen Routen aufgerufen habe, anstatt Routen in Tabelle 200 für sie zu haben

post-up ip rule add from 10.30.0.0/16 table 200
post-up ip rule add from 10.30.0.0/16 to 192.168.0.0/16 table main
post-up ip rule add from 10.30.0.0/16 to 10.30.0.0/16 table main
post-up ip route add default via a.b.c.d metric 2 table 200
post-up ip route add blackhole default metric 3 table 200

verwandte Informationen