同じネットワークであるIPから別のIPにポート転送を行う方法は?


77

私はいくつかNATをやりたいiptablesです。そのため、に到着するすべてのパケット192.168.12.87とポート80はport に転送され192.168.12.77ます80

iptablesでこれを行う方法は?

または

同じことを達成する他の方法はありますか?


@Matthewlfe、何らかの理由で、すべてのApacheリクエストを(192.168.12.87)から(192.168.12.77)に転送する必要があります。
座った

1
@ Matthewlfe、2台の運用サーバーがあります。1つはパブリック静的IPアドレスで接続されています。いくつかの接続性の問題により、からDBや他のシステムに接続できません192.168.12.87。したがって、すべてのリクエストをに転送する必要があり192.168.12.77ます。
座った

@lain、私はよく知らないiptables。そして、いくつかの例をみました。しかし、それは2つのイーサネットを必要とするようです。リンク:revsys.com/writings/quicktips/nat.html
座って

Webサーバー設定でプロキシモードを使用して、192.168.12.87から192.168.12.77にリクエストを送信することもできます(Webサーバーがサポートしている場合)
krisFR 14

回答:


75

これら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する必要もあります。


代替(および最善のアプローチ私見):

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


ポートがufwで許可されている場合でも、ufwが無効になっている限り機能しますが、ufwが有効になっている場合、この転送は機能しません。
スディールN

1
素晴らしい答えと素晴らしい質問。これが役立つ別のユースケースは、すべてのクライアントを再構成することなく元のサービスのメンテナンスを実行するために、あるサービス、たとえばsquidに着信するすべてのトラフィックを一時的に別のIP /ポートにリダイレクトする必要がある場合です!とても便利な!
PF4Public 16

3
「ただし、トラフィックをSNATする必要もあります。」->あなたは私の一日を救った。ありがとう
obayhan

この解決策は私には役に立たない。eth0からKVMゲストが使用する仮想ネットワーク(virb0)に転送する必要があります。-iおよび-oオプションを追加しようとしましたが、事前ルーティングには-oを使用できません。助言がありますか?
lostiniceland

このソリューションには注意してください。リモートマシンへのアクセスが完全に失われました。
ソレン

28

一見明らか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つのアプローチがあります。

  1. 最初のホストでは、DNATを実行するだけでなく、SNATも実行して、リターントラフィックが最初のホストを介して送り返されるようにします。ルールは次のようになりますiptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87
  2. IP層ではなくイーサネット層でパケットをDSRロードバランシングとDNATからインスピレーションを得てください。パケットの宛先MACを192.168.12.77のMACに置き換え、IPレイヤーに触れることなくイーサネットで送信することにより、192.168.12.77がダミーインターフェイスで192.168.12.87を構成し、TCP接続を終了できるようになります。クライアントが認識しているサーバーIPを使用します。
  3. 最初のホストで単純な(動作していない)ソリューションを使用します。次に、リターントラフィックでSNATを実行して、2番目のホストでリターンパケットを処理します。ルールは次のようになりますiptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87

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

  1. SNATを使用するとクライアントIPが失われるため、ホスト番号2はすべての接続が192.168.12.87から来たと見なします。さらに、すべての応答パケットにホスト番号1の帯域幅を使用します。これにより、他のアプローチではより直接的なルートを使用できます。
  2. DSRアプローチは、2つのノード間の他のすべての通信を中断します。DSRアプローチは、サーバーアドレスがどのホストのプライマリIPでもない場合にのみ適切です。各ホストには、DSR IPではないプライマリIPが必要です。
  3. あるホストで接続追跡を使用して1つの方向に変換し、別のホストで接続追跡を使用して別の方向に変換するのは見苦しいため、さまざまな方法で解決できます。たとえば、いずれかのホストでNATによってポート番号が変更された場合、それらを再構成する方法はありません。また、最初のパケットがACKではなくSYN-ACKである場合、接続追跡が正常に機能することも指定されていません。

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

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


-j MASQUERADEここで言及されていないことに驚いています。DNATでの通常のアプローチではありませんか?
レム

3
@remramのSNAT代わりに私が言及MASQUERADEしたのは、ドキュメントが言っていることだからです。マニュアルの正確な内容は次のとおりです。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
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.