Zielsetzung
Ich möchte so etwas machen:
Dabei hilft der „Mini-Router“ dabei, ein Altsystem zu steuern und zu sichern, das aus komplexen Gründen nicht aktualisiert werden kann und irgendwo „in der freien Wildbahn“ liegt. Wir hoffen, die Systeme mit einem billigen, stromsparenden (z. B. 0,5 V und < 100 mA) nachrüsten zu können. Es gibt mehrere Tausend dieser SCADA-Systeme, die überall verstreut sind. Wir müssen eine White-Hat-Nachrüstung durchführen, aber in etwa 15 bis 30 % der Umgebungen können wir keine IP-Adresse (kein DHCP) für den „Mini-Router“ erhalten und müssen die IP des Computer-/SCADA-Systems teilen. Ich dachte, wir könnten eine transparente Brücke einrichten (die br0 unten funktioniert als Brücke):
root% ip link add name br0 type bridge
root% ip link set dev br0 up
root% ip link set dev eth0 master br0
root% ip link set dev eth1 master br0
root% ip address add 10.253.252.2 dev br0
root% sysctl -w net.ipv4.conf.all.forwarding=1
Und dann verwenden Sie ebtables/iptables/iproute2, um den Datenverkehr von Server1 an den Computer weiterzuleiten, sodass wir den Datenverkehr zwischen ihnen SSL-verschlüsseln/entschlüsseln und/oder den Datenverkehr zwischen Server2 und Computer „verbrauchen“ können, da dies zum Konfigurieren und Steuern des „Mini-Routers“ gedacht ist.
Da ich eine komplett transparente Brücke haben möchte, habe ich die Adressen von eth0 und eth1 entfernt:
root% ip address flush dev eth0
root% ip address flush dev eth1
root% ip address add 0.0.0.0 dev eth0
root% ip address add 0.0.0.0 dev eth1
root% ip link set dev eth0 up
root% ip link set dev eth1 up
root% ip link set dev eth0 promisc on
root% ip link set dev eth1 promisc on
root% ip link set dev br0 promisc on # Not sure if needed
Leider kann ich den Verkehr nicht zu/von dem Dienst umleiten, der die Steuernachrichten verarbeitet.
HINWEIS: Ich kann br0 tatsächlich eine nicht routbare Adresse zuweisen (z. B. 169.254.1.2). Wenn sich Server1 im lokalen LAN-Segment befindet (z. B. auf demselben Switch), kann die unten beschriebene Methode (Versuche Version 1) funktioniert; die TCP/IP-Pakete haben jedoch eine Quelle oder ein Ziel von 169.254.1.2, die nicht geroutet werden können und keine Router oder LAN-Grenzen überschreiten können, aber Server1 und dem „Mini-Router“ scheint das egal zu sein. Wie oben beschrieben, kann ich nicht einfach einen DHCP auf br0 bekommen (was auch funktioniert), weil möglicherweise über tausend der „Mini-Router“ keine DHCP-Adresse bekommen können.
Frage:
Wie kann ich das erreichen? Nachfolgend sind die Dinge aufgeführt, die ich versucht habe.
Versuche:
Ich habe nach einer Reihe von Lösungen gesucht, aber mit wenig Erfolg. Zum Beispiel:„iptables – Ziel zum Weiterleiten von Paketen an eine bestimmte Schnittstelle?“, schlägt vor, dass das Markieren von Paketen und die Verwendung einer anderen Routing-Tabelle funktionieren könnten; die Beispiele sind jedoch nicht über eine Brücke. Ich habe ziemlich viel Zeit damit verbracht, dieNetfilter-Dokumentationund intuitiv sieht es so aus, als ob ich in der Lage sein sollte,Netfilter NATzwischen br0 und eth1, aber ich weiß wieder nicht wie.LAN-zu-LAN IPsecoder eine reine VPN-Lösung erfordert dauerhafte Verbindungen zwischen Endpunkten, die wir nicht haben werden. Der Computer muss nur regelmäßig nach Hause telefonieren oder Push-Informationen empfangen, benötigt aber keine dauerhafte sichere Verbindung. Da das Computer-/SCADA-System auch mit anderen Systemen kommunizieren muss, sollte der Mini-Router den bestehenden Datenverkehr zwischen dem Computer und dem LAN/Router nicht stören.
Versuche Version 1
Zuerst habe ich die Regeln geklärt:
root% ip rule flush
root% ip rule add lookup default priority 32767
root% ip rule add lookup main priority 32766
Abrufen von Ethernet-Frames zwischen Server1 und Computer zum „DROP“ an die Netzwerkschicht.
root% ebtables -t broute -A BROUTING -p IPv4 \
--ip-source 5.6.7.1 --ip-destination 10.0.0.1 \
-j redirect --redirect-target DROP
root% ebtables -t broute -A BROUTING -p IPv4 \
--ip-source 10.0.0.1 --ip-destination 5.6.7.1 \
-j redirect --redirect-target DROP
Umleitung des Server1<-->Computerverkehrs an die Adresse br0
root% iptables -t nat -A PREROUTING -p tcp \
-s 5.6.7.1 -d 10.0.0.1 \
-j DNAT --to-destination 10.253.252.2
root% iptables -t nat -A POSTROUTING -p tcp \
-d 10.253.252.2 \
-j SNAT --to-source 10.0.0.1
root% iptables -t nat -A POSTROUTING -j MASQUERADE
Hinzufügen einer Route zu Server1 über br0
root% ip route add 5.6.7.2 via 10.253.252.2 dev br0
Und drücke die Daumen, aber es funktioniert nicht. Habe viele verschiedene Permutationen davon ausprobiert.
Versuche Version 2
Vor Kurzem habe ich vergeblich eine Version ausprobiert, die der oben erwähnten näher kommt, mit -j MARK für das Paketrouting:
root% ip rule add fwmark 2 priority 1000 table 3
root% ip route add default via 10.0.0.1 table 3
root% ip route flush cache
root% ip route flush table 3
root% iptables -t mangle -A OUTPUT -p tcp -s 5.6.7.1 -j MARK --set-mark 2
root% iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
root% ip route add 0.0.0.0/1 via 10.253.252.2 dev br0 table 3