Wie wird die Portweiterleitung von einer IP zu einer anderen IP im selben Netzwerk durchgeführt?

Lösung 1:

Diese Regeln sollten funktionieren, vorausgesetzt, dass iptables läuft auf Server 192.168.12.87 :

#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -F
iptables -t nat -F
iptables -X

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.12.77 --dport 80 -j SNAT --to-source 192.168.12.87

Sie müssen eingehenden Datenverkehr auf Port 80 mit DNAT versehen, aber Sie müssen den Datenverkehr auch per SNAT zurücksenden.

Alternative (und IMHO beste Herangehensweise):

Abhängig von Ihrem Webserver (Apache, NGinx) sollten Sie einen HTTP-Proxy auf Ihrem Front-End-Server (192.168.12.87) in Betracht ziehen:

• mod_proxy (Apache)

• proxy_pass (NGinx)

Lösung 2:

Der Grund ist ein scheinbar offensichtlicher iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77 nicht funktionieren wird, wie die Rückpakete geroutet werden.

Sie können Regeln aufstellen, die bewirken, dass die an 192.168.12.87 gesendeten Pakete einfach an 192.168.12.77 NATted werden, aber 192.168.12.77 sendet dann Antworten direkt an den Client zurück. Diese Antworten gehen nicht über den Host, auf dem Ihre iptables-Regel NAT ausführt, daher werden die Pakete in eine Richtung übersetzt, Pakete in die andere Richtung jedoch nicht.

Es gibt drei Ansätze zur Lösung dieses Problems.

1. Führen Sie auf dem ersten Host nicht nur DNAT, sondern auch SNAT durch, sodass der Rückverkehr über den ersten Host zurückgesendet wird. Die Regel könnte in etwa so aussehen:iptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87
2. Lassen Sie sich vom DSR-Load-Balancing inspirieren und DNAT die Pakete auf der Ethernet-Schicht statt auf der IP-Schicht. Indem der Ziel-MAC der Pakete durch den MAC von 192.168.12.77 ersetzt und über das Ethernet gesendet wird, ohne die IP-Schicht zu berühren, könnte 192.168.12.77 192.168.12.87 auf einer Dummy-Schnittstelle konfiguriert haben und somit in der Lage sein, die TCP-Verbindung zu beenden mit der dem Client bekannten Server-IP.
3. Verwenden Sie die naive (aber nicht funktionierende) Lösung auf dem ersten Host. Bearbeiten Sie dann die Rückpakete auf dem zweiten Host, indem Sie eine SNAT für den Rückverkehr durchführen. Eine Regel könnte wie folgt aussehen:iptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87

Jede dieser drei Lösungen hat Nachteile, daher müssen Sie sorgfältig abwägen, ob Sie diese spezielle Weiterleitung wirklich benötigen.

1. Bei Verwendung von SNAT geht die Client-IP verloren, sodass Host Nummer 2 davon ausgeht, dass alle Verbindungen von 192.168.12.87 stammen. Außerdem verwenden Sie Bandbreite über Host Nummer 1 für alle Antwortpakete, was bei den anderen Ansätzen einen direkteren Weg nehmen würde.
2. Der DSR-Ansatz wird die gesamte andere Kommunikation zwischen den beiden Knoten unterbrechen. Der DSR-Ansatz ist wirklich nur angemessen, wenn die Serveradresse nicht die primäre IP eines der Hosts ist. Jeder Host muss eine primäre IP haben, die nicht die DSR-IP ist.
3. Die Verwendung von Verbindungsverfolgung auf einem Host zum Übersetzen in eine Richtung und Verbindungsverfolgung auf einem anderen Host zum Übersetzen in die andere Richtung ist einfach hässlich, und es gibt verschiedene Möglichkeiten, wie es brechen könnte. Wenn beispielsweise Portnummern auf einem der beiden Hosts durch NAT geändert werden, gibt es keine Möglichkeit, diese zu rekonstruieren. Es ist auch nicht selbstverständlich, dass die Verbindungsverfolgung korrekt funktioniert, wenn das erste Paket, das es sieht, ein SYN-ACK und kein ACK ist.

Von den drei Ansätzen denke ich, dass der erste derjenige ist, der am wahrscheinlichsten funktioniert. Wenn Sie also die Client-IP-Adressen nicht kennen müssen, würde ich diese empfehlen.

Sie können NAT auch ganz vergessen und nicht versuchen, das Problem auf MAC- oder IP-Ebene zu lösen. Sie können bis zur HTTP-Schicht gehen und dort nach einer Lösung suchen. In diesem Fall finden Sie als Lösung einen HTTP-Proxy. Wenn Sie einen HTTP-Proxy auf 192.168.12.87 installieren und entsprechend konfigurieren, können Sie die Anfragen an 192.168.12.77 weiterleiten und die Antworten zurückleiten. Zusätzlich kann es einen X-Forwarded-For-Header einfügen, der die ursprüngliche Client-IP beibehält. Der Server auf 192.168.12.77 muss dann so konfiguriert werden, dass er dem X-Forwarded-For-Header von 192.168.12.87 vertraut.