Bidirektionales NAT mit iptables

Bidirektionales NAT mit iptables

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

Cluster-Setup, der Einfachheit halber ohne dumme Switches

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.

verwandte Informationen