ポート/秒を外部IPに透過的に転送するIptables（リモートエンドは実際の送信元IPを確認する必要があります）

質問は簡単ですが、答えは具体的な回答なしで無数の関連トピックを通り抜けたので、答えはそうではないと思う。

私はポートを転送したい1234からx.x.x.xにy.y.y.y（すなわち、異なる場所で、インターネット上の両方y.y.y.yのような内部IPではない10.a.b.c方法で、など）y.y.y.yに接続している元のソースIPを取得することができますx.x.x.x。

現時点ではx.x.x.x、通常のSNATまたはMASQUERADEルールを使用するソースIP と見なされます。場合はy.y.y.y（上で実行されているLXCコンテナのようないくつかの内部IPをあるx.x.x.x同じルールが動作）とコンテナが実際のソースIPを見ることができますが、ない場合はy.y.y.y、外部です。

これは何らかの方法で達成できますか？

NATのみ–いいえ。IPパケットには、「ソース」フィールドが1つしかありません。

• iptablesに元のクライアントアドレス（DNATのみ）を保持させると、yyyyは元のクライアント（xxxxと通信していると考え、yyyyからのパケットを期待していない）に直接応答を送信しようとします。

• iptablesにアドレスを新しいソース（DNAT + SNAT）として設定すると、yyyyは元のソースアドレスを知ることができません。

（これは、実際にはLANから同じLANにポート転送しようとするのと同じ問題であり、2番目の方法は「NATヘアピニング」または「NATリフレクション」と呼ばれます。）

これを機能させるには、xxxxとyyyyの間にトンネル/ VPNが必要です– yyyyに送信される別の IPパケット内に、元のパケットを変更せずにラップします（トンネル化されたパケットをアンラップし、元のソースを表示します） 。

もちろん、これは、トンネルを設定するために両方のシステムでルート権限が必要であることを意味します。さらに、宛先（yyyy）は「ポリシールーティング」をサポートする必要があります。LinuxおよびFreeBSD pfはこれに対応しています。送信元アドレスがVPNアドレスである場合、VPNを介してすべてをルーティングするルールが必要です。

それでもiptables DNATルールが必要ですが、その「宛先」はパブリックアドレスではなくyのVPNアドレスになります。これには、基本的な「IP-in-IP」からGRE、OpenVPN、WireGuardまで、任意のトンネル/ VPNタイプを使用できます。例えば：

• xxxx

  トンネルを立ち上げます。

  ip link add gre-y type gre local x.x.x.x remote y.y.y.y ttl 64
  ip link set gre-y up
  ip addr add 192.168.47.1/24 dev gre-y
  

  LANと同様に、ポート転送ルールを追加します。

  iptables -t nat -I PREROUTING -p tcp --dport 1234 -j DNAT --to-destination 192.168.47.2
  

• yyyy

  トンネルを立ち上げます。

  ip link add gre-x type gre local y.y.y.y remote x.x.x.x ttl 64
  ip link set gre-x up
  ip addr add 192.168.47.2/24 dev gre-x
  

  動作することを確認してください：

  ping 192.168.47.1
  

  返信（および返信のみ）がトンネルを通過するように、ポリシールーティングを設定します。

  ip route add default via 192.168.47.1 dev gre-x table 1111
  ip rule add pref 1000 from 192.168.47.2 lookup 1111
  

（別のトンネル/ VPNタイプを使用するには、「トンネルの起動」部分のみを交換します。）

いいえ、あなたはそれを達成することはできません。問題は、ルーティングが機能しないことです。

ホストE（外部）はパケットをホストF（フォワーダー）に送信します。F同じソースでそのパケットをホストD（宛先）に送信します。この部分は、D内部であろうと外部であろうと機能します。

ここでD、応答を返さなければならず、それをパケット内の送信元アドレスに送信しますE。

• 場合D、内部ホストとFのデフォルトゲートウェイでありD、そのパケットが通過Fソース場合、D応答パケットには、に変更されますF。ホストEはからのパケットを確認しF、すべて正常です。
• Dが外部ホストの場合F、はのデフォルトゲートウェイではないためD、にD直接回答を送信しますE。ホストEはから答えを得るでしょうが、から答えをD期待しますF、そして、したがって、パケットを捨てDます。ホストEは数回再試行し、間違った送信元アドレスからの回答を再び破棄し、最終的にタイムアウトします。

送信元アドレスが返信パケットに使用されるため、おそらくこれを実現することはできません。したがって、送信元アドレスがNATの背後にある場合、より広いインターネットからは到達できません。

一般的に使用されている少なくとも2つの回避策（追加のソフトウェアと構成が必要）があります-最初はVPNを使用してルーターをバイパスするか、代わりにルーターと宛先の間で使用して宛先がソースに到達する方法を知ることです。

HTTPおよびHTTPSの場合、IPTABLESファイアウォールルールを使用せず、代わりにルーターで（透明または通常の）プロキシを使用し、外部アプリケーションがアクセスおよび処理できるX-FORWARDED-FORヘッダーをプロキシサーバーに追加する。

正確なアプリケーションとファイアウォールに応じて、リクエストの発信元ポートを変更することで「相対」内部IPアドレスをマークすることも可能です（それでもルーターアドレスから発信されますが、送信元ポートに基づいて、ルーターの背後にあるどのシステムが送信したかのヒント）。これが実際に使用されるのを見たことはありません。