同じネットワーク内のある IP から別の IP へのポート転送を行うにはどうすればよいですか?

解決策 1:

iptables であると仮定すると、これらのルールは機能するはずです。サーバー 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

ポート 80 で着信トラフィックを DNAT する必要がありますが、戻ってくるトラフィックも SNAT する必要があります。

代替（および最良のアプローチIMHO）：

Web サーバーが何であるか (Apache、NGinx) に応じて、フロントエンドサーバー (192.168.12.87) で HTTP プロキシを検討する必要があります:

mod_proxy (Apache)
proxy_pass (NGinx)

解決策 2:

一見明白な iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77 の理由戻りパケットがどのようにルーティングされるかは、機能しません。

192.168.12.87 に送信されたパケットが単に 192.168.12.77 に NAT 変換されるルールを設定できますが、192.168.12.77 はクライアントに直接応答を返します。これらの応答は、iptables ルールが NAT を実行しているホストを経由しないため、一方向のパケットは変換されますが、他の方向のパケットは変換されません。

この問題を解決するには 3 つのアプローチがあります。

<オール>

最初のホストでは、DNAT だけでなく SNAT も実行して、リターントラフィックが最初のホストを介して送り返されるようにします。ルールは iptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87 のようになります

DSR 負荷分散から着想を得て、IP レイヤーではなくイーサネットレイヤーでパケットを DNAT します。パケットの宛先 MAC を 192.168.12.77 の MAC に置き換え、それを IP レイヤーに触れずにイーサネットで送信することにより、192.168.12.77 はダミーインターフェイスで 192.168.12.87 を構成できるため、TCP 接続を終了できます。クライアントに知られているサーバー IP を使用します。

最初のホストで素朴な (しかし機能しない) ソリューションを使用します。次に、リターントラフィックで SNAT を実行して、2 番目のホストでリターンパケットを処理します。ルールは iptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87 のようになります

これら 3 つのソリューションにはそれぞれ欠点があるため、この特定の転送を本当に行う必要があるかどうかを慎重に検討する必要があります。

<オール>

SNAT を使用するとクライアント IP が失われるため、ホスト番号 2 はすべての接続が 192.168.12.87 からのものであると認識します。さらに、すべての応答パケットにホスト番号 1 を介して帯域幅を使用します。これは、他のアプローチではより直接的なルートになります。

DSR アプローチは、2 つのノード間の他のすべての通信を遮断します。 DSR アプローチは、サーバーアドレスがどのホストのプライマリ IP でもない場合にのみ適切です。各ホストには、DSR IP ではないプライマリ IP が必要です。

あるホストでコネクショントラッキングを使用して一方向に変換し、別のホストでコネクショントラッキングを使用して別の方向に変換するのは、明らかに醜く、さまざまな方法で中断する可能性があります。たとえば、いずれかのホストでポート番号が NAT によって変更された場合、それらを再構築する方法はありません。また、最初に検出したパケットが ACK ではなく SYN-ACK である場合、接続追跡が正しく機能するということもありません。

3 つのアプローチのうち、最初のアプローチが最も効果的であると思います。したがって、クライアントの IP アドレスを知る必要がない場合は、それをお勧めします。

また、NAT を完全に忘れて、MAC または IP レイヤーの問題を解決しようとしないことも選択できます。 HTTP レイヤーまでずっと行き、そこで解決策を探すことができます。その場合、解決策は HTTP プロキシです。 HTTP プロキシを 192.168.12.87 にインストールして適切に構成すると、要求を 192.168.12.77 に転送し、応答を転送することができます。さらに、元のクライアント IP を保持する X-Forwarded-For ヘッダーを挿入できます。 192.168.12.77 上のサーバーは、192.168.12.87 からの X-Forwarded-For ヘッダーを信頼するように構成する必要があります。