Wir haben eine Bridge auf Ubuntu eingerichtet, um unser LAN mit unserem Gateway zu verbinden, das sich im selben Subnetz befindet. Wir brauchen dies, um den Datenverkehr steuern zu können, und sind derzeit nicht in der Lage, Subnetze zu ändern, sodass wir ihn nicht einfach umleiten können.
Das Gateway wird über unseren ISP gesteuert, der MPLS für verschiedene andere /24-Subnetze innerhalb von 192.168.0.0/16 bereitstellt.
Die aktuelle Konfiguration ist wie folgt:
192.168.10.1 (gw) <-> eth0 <-> br0 (192.168.10.3) <-> eth1 <-> LAN (192.168.10.0/24)
br0 Link encap:Ethernet HWaddr ..
inet addr:192.168.10.3 Bcast:192.168.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
...
eth0 Link encap:Ethernet HWaddr ..
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr ..
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Dies funktioniert gut und verursacht keine Probleme.
Wir haben auch ein Tinc-VPN zu unserer Rechenzentrumsinfrastruktur auf demselben Server (192.168.10.3), das nicht Teil der Brücke ist. zB:
tincvpn Link encap:Ethernet HWaddr ..
inet addr:192.168.10.3 Bcast:192.168.255.255 Mask:255.255.0.0
...
Wir möchten das Routing für Pakete, die vom LAN über die Brücke gehen, für bestimmte Ziele (z. B. 192.168.5.0/24) außer Kraft setzen, damit sie über Tinc laufen. D. h.: 192.168.10.x im LAN nach 192.168.5.x sollte über Tinc und nicht zum Gateway laufen.
Wir möchten, dass dies für alle Maschinen im LAN funktioniert, ohne dass wir etwas konfigurieren müssen, haben aber vorerst einen Workaround gefunden, der darin besteht, jedem PC/Server im LAN die folgende statische Route hinzuzufügen:
route add -net 192.168.5.0/24 via 192.168.10.3 dev eth0
Damit die statische Route funktioniert, mussten wir auch proxy_arp für alle Schnittstellen auf 192.168.10.3 aktivieren.
Wir haben die folgende Konfiguration versucht, aber sie hat nicht funktioniert:
ip rule add fwmark 20 lookup 20
ip route add 192.168.0.0/16 dev tincvpn table 20
ebtables -t broute -I BROUTING -i eth1 -p ipv4 --ip-dst 192.168.5.0/24 -j REDIRECT --redirect-target DROP
iptables -t mangle -I PREROUTING -i eth1 -d 192.168.5.0/24 -j MARK --set-mark 20
Mit diesem Setup kamen die Pakete bei der Mangle-Regel an und wurden markiert, aber sie wurden nicht auf die TinCVPN-Schnittstelle weitergeleitet.
Unser Verständnis war, dass wir die Pakete mithilfe von ebtables aus der Brücke entfernen und dann ein richtlinienbasiertes Routing verwenden mussten, damit die Pakete durch Tinc geleitet werden. Ist das richtig?
Wenn jemand eine Idee hat, warum das nicht funktioniert hat, wäre ich dankbar.
Vielen Dank,
Tom