Frage Wie funktioniert die Port-Weiterleitung von einer IP-Adresse zu einer anderen IP-Adresse im selben Netzwerk?


Ich möchte etwas tun NAT im iptables. So, dass alle Pakete kommen 192.168.12.87 und Hafen 80 wird weitergeleitet an 192.168.12.77 Hafen 80.

Wie mache ich das mit iptables?

Oder

Gibt es noch andere Möglichkeiten, dasselbe zu erreichen?


62
2018-04-03 17:58


Ursprung


@ Mathewlfe, aus irgendeinem Grund muss ich alle Apache-Anfrage von (192.168.12.87) zu (192.168.12.77) weiterleiten. - sat
@ Mathewlfe, ich habe zwei Produktionsserver. Einer ist mit der öffentlichen statischen IP-Adresse verbunden. Aufgrund einiger Verbindungsprobleme kann ich keine Verbindung zu DB und anderen Systemen herstellen 192.168.12.87. Also, ich muss die Anfrage an alle weiterleiten 192.168.12.77. - sat
@lain, ich bin nicht vertraut mit iptables. Und ich habe ein paar Beispiele gesehen. Aber es scheint zwei Ethernet zu erfordern. Verknüpfung: revsys.com/writings/quicktips/nat.html - sat
Sie können auch den Proxy-Modus in Ihrer Webserver-Konfiguration verwenden, um Anfragen von 192.168.12.87 an 192.168.12.77 zu senden (wenn Ihr Webserver dies unterstützt). - krisFR
askapache.com/htaccess/ ... - dmourati


Antworten:


Diese Regeln sollten funktionieren, vorausgesetzt, dass iptables läuft auf dem 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 Verkehr an Port 80 DNAT, aber Sie müssen auch den Verkehr SNAT SNAT.


Alternative (und beste Vorgehensweise IMHO):

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


62
2018-04-03 21:46



Funktioniert so lange wie ufw deaktiviert ist, obwohl der Port in ufw erlaubt ist, aber wenn ufw aktiviert ist, funktioniert diese Weiterleitung nicht, irgendeine Idee? - Sudhir N
Große Frage mit großer Antwort. Ein weiterer Anwendungsfall ist nützlich, wenn Sie den gesamten Verkehr, der zu einem Dienst kommt, temporär umleiten müssen, sagen wir Tintenfisch, zu einem anderen IP / Port, um einige Wartungsarbeiten am ursprünglichen Dienst durchzuführen, ohne alle Clients neu konfigurieren zu müssen! Sehr praktisch! - PF4Public
"Aber Sie müssen auch den Verkehr zurück SNAT SNAT." -> Du hast meinen Tag gerettet. Vielen Dank - obayhan
Diese Lösung funktioniert nicht für mich. Ich muss von eth0 zu einem virtuellen Netzwerk (virb0) weiterleiten, das von einem KVM-Gast verwendet wird. Ich habe versucht, die Optionen -i und -o hinzuzufügen, aber -o ist nicht für die Vorrouting erlaubt. Irgendwelche Vorschläge? - lostiniceland


Der Grund ist scheinbar offensichtlich iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77 wird nicht funktionieren, ist wie die Rücksendung Pakete weitergeleitet werden.

Sie können Regeln einrichten, die dazu führen, dass die Pakete, die an 192.168.12.87 gesendet werden, einfach an 192.168.12.77 NATATED werden. 192.168.12.77 sendet dann die Antworten direkt an den Client zurück. Diese Antworten gehen nicht durch den Host, wo Ihre iptables-Regel NAT ausführt, daher werden die Pakete in einer Richtung übersetzt, aber die Pakete in die andere Richtung nicht.

Es gibt drei Ansätze, um dieses Problem zu lösen.

  1. Auf dem ersten Host tun Sie nicht nur DNAT, sondern auch SNAT, so dass der zurückkehrende Datenverkehr über den ersten Host zurückgesendet wird. Die Regel könnte ungefähr 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 und DNAT-Paketen auf der Ethernet-Ebene statt auf der IP-Ebene inspirieren. Indem die Ziel-MAC der Pakete durch die MAC-Adresse 192.168.12.77 ersetzt und auf das Ethernet gesendet werden, ohne die IP-Schicht zu berühren, kann 192.168.12.77 192.168.12.87 auf einer Dummy-Schnittstelle konfiguriert 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. Behandeln Sie dann die Rückgabepakete auf dem zweiten Host, indem Sie einen SNAT für den Rückverkehr ausführen. Eine Regel könnte so 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, Sie müssen also sorgfältig überlegen, ob Sie diese spezielle Weiterleitung wirklich benötigen.

  1. Die Verwendung von SNAT führt dazu, dass die Client-IP verloren geht. Daher wird Host 2 denken, dass alle Verbindungen von 192.168.12.87 stammen. Darüber hinaus verwenden Sie für alle Antwortpakete Bandbreite bis Hostnummer 1, was einen direkteren Weg zu den anderen Ansätzen bedeutet.
  2. Der DSR-Ansatz unterbricht alle andere Kommunikation zwischen den zwei Knoten. Der DSR-Ansatz ist nur dann sinnvoll, 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, um in eine Richtung zu übersetzen, und die Verbindungsverfolgung auf einem anderen Host, um in die andere Richtung zu übersetzen, ist einfach hässlich, und es gibt verschiedene Möglichkeiten, wie es brechen kann. Wenn zum Beispiel Port-Nummern durch NAT auf jedem Host 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 nicht ein ACK ist.

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

Sie können auch NAT 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 ist die Lösung, die Sie finden, ein HTTP-Proxy. Wenn Sie einen HTTP-Proxy unter 192.168.12.87 installieren und ihn entsprechend konfigurieren, können Sie die Anforderungen an 192.168.12.77 weiterleiten und die Antworten zurückleiten. Zusätzlich kann ein X-Forwarded-For-Header eingefügt werden, der die ursprüngliche Client-IP-Adresse beibehält. Der Server unter 192.168.12.77 muss dann so konfiguriert werden, dass er dem Header X-Forwarded-For von 192.168.12.87 vertraut.


26
2018-04-03 21:44



Ich bin überrascht -j MASQUERADE wird hier nicht erwähnt; Ist das nicht der übliche Ansatz mit DNAT? - remram
@remram habe ich erwähnt SNAT anstatt MASQUERADE, denn das sagt die Dokumentation. Der genaue Wortlaut in der Dokumentation lautet: It should only be used with dynamically assigned IP (dialup) connections: if you have a static IP address, you should use the SNAT target. - kasperd