Kurz gesagt, ich habe ein Clustersystem zur Hand, für das ich den Verkehr über dessen Master leiten muss. Das Leiten des Verkehrs von den Knoten zur Außenwelt funktioniert, aber das Leiten des Verkehrs vom Subnetz unserer Abteilung zu den Knoten schlägt fehl. Leider kommt das Hinzufügen der Knoten zu unserem Subnetz nicht in Frage.
Die Einrichtung
Der Cluster besteht aus einem Master und einer Reihe von Knoten sowie einiger Peripheriegeräte. Die Knoten befinden sich in einem internen Netzwerk und sind vor unserem Intranet oder dem Internet verborgen. Auf dem Master ist bereits ein NAT eingerichtet, sodass die Knoten Zugriff auf interne und externe Server haben. Dieser Teil funktioniert.
Die externe Schnittstelle des Masters befindet sich im selben Subnetz wie unsere Workstation-PCs, die sich ein Gateway außerhalb unserer Kontrolle teilen.
Bearbeiten: Der Cluster läuft unter CentOS 7, die PCs unter einer auf Ubuntu Xenial basierenden Distribution.
Die Aufgabe
Einige unserer Softwarepakete benötigen direkten Zugriff auf die Knoten. Dazu wollten wir mithilfe von iptables ein zweites NAT auf dem Master einrichten und eine IP-Route auf den PCs hinzufügen, um den Datenverkehr über den Master an 10.10.1.0/24 zu senden.
Die Konfiguration
Master: IP-Route
default via 123.45.67.254 dev eth0 proto static metric 100
10.10.0.0/16 dev eth1 proto kernel scope link src 10.10.0.1
123.45.67.0/23 dev eth0 proto kernel scope link src 123.45.67.204 metric 100
Master: iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 7356 packets, 880K bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 4884 packets, 687K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 3445 packets, 225K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 3445 packets, 225K bytes)
pkts bytes target prot opt in out source destination
439 33324 MASQUERADE all -- * eth0 10.10.1.0/24 0.0.0.0/0
61828 3710K MASQUERADE all -- * eth1 123.45.67.0/23 10.10.1.0/24
Die Verwendung von SNAT anstelle von MASQUERADE macht keinen Unterschied.
Knoten: IP-Route
default via 10.10.0.1 dev eth1
10.10.0.0/16 dev eth1 proto kernel scope link src 10.10.1.1
PC: IP-Route
default via 123.45.67.254 dev eth0 proto static metric 100
10.10.0.0/16 via 123.45.67.204 dev eth0
123.45.67.0/23 dev eth0 proto kernel scope link src 123.45.67.191 metric 100
Bisherige Diagnose
- NAT von Node01 zum Internet/Intranet/PCs funktioniert einwandfrei.
- NAT von PC1 zu Node01 schlägt während des TCP-Handshakes fehl:
- SYN wird über den Master an node01 weitergeleitet und im tcpdump als SYN_RECV markiert.
- SYN+ACK wird von node01 an den Master gesendet
- SYN+ACK erscheint im TCPdump auf dem Master und wird an den Filter weitergeleitet.
- tcpdump zeigt die SYN+ACK-Weiterleitung zum Filter an
- iptables zeigt die SYN+ACK Pakete die durch den Filter FORWARD, Mangle FORWARD + POSTROUTING gehen
- Die SYN+ACK-Pakete schaffen es nie durch das NAT-POSTROUTING (sollten sie das?)
- Die SYN+ACK-Pakete kommen nie bei pc1 an
- Natürlich scheitert der Handschlag
- pc1 steckt in SYN_SENT fest
- node01 steckt in SYN_RECV fest
- irgendwann kommt es zu einer Zeitüberschreitung der Verbindung
- Ich habe keine Möglichkeit, Pakete am Gateway zu überwachen
Meine beste Vermutung ist, dass ein Stateful-Router unterwegs das SYN+ACK-Paket verwirft, da seine Quelladresse auf dem Master neu geschrieben wird und somit seine Beziehung zum ursprünglichen SYN-Paket verloren geht.
Wie können wir das zum Laufen bringen?
Lassen Sie mich wissen, ob zusätzliche Konfigurationen/Protokolle benötigt werden.