解決策 1:
元の回答が正しいと確信できなかったため、元の回答を削除しました。それ以来、問題のネットワークをシミュレートするために、VM の小さな仮想ネットワークをセットアップする時間がありました。これが私のために機能した一連のファイアウォールルールです（iptables-saveで） nat のフォーマット 表のみ):
-A PREROUTING -d 89.179.245.232/32 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10
-A POSTROUTING -s 192.168.2.0/24 -o ppp0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.10/32 -p tcp -m multiport --dports 22,25,80,443 -j MASQUERADE
最初の POSTROUTING ルールは、インターネット接続を LAN と共有する簡単な方法です。完全を期すために残しました。
PREROUTING ルールと 2 番目の POSTROUTING ルールを組み合わせて適切な NAT を確立し、接続が LAN の外部または内部のどちらから発生したかに関係なく、外部 IP アドレスを介したサーバーへの接続が発生できるようにします。 LAN 上のクライアントが外部 IP アドレス経由でサーバーに接続すると、サーバーは接続がルーターの内部 IP アドレス (192.168.2.1) からのものと見なします。
興味深いことに、2 番目の POSTROUTING ルールにも機能するいくつかのバリエーションがあることがわかりました。ターゲットが -j SNAT --to-source 192.168.2.1 に変更された場合 、効果は（驚くべきことではありませんが） MASQUERADE と同じです :サーバーは、ローカル LAN クライアントからの接続を、ルーターの内部から発信されたものとして認識します。 IPアドレス。一方、ターゲットを -j SNAT --to-source 89.179.245.232 に変更すると、 の場合、NAT は引き続き機能しますが、今回はサーバーはローカル LAN クライアントからの接続をルーターの 外部 から発信されたものとして認識します。 IP アドレス (89.179.245.232)。
最後に、元の PREROUTING に注意してください /DNAT -i ppp0 のルール ルールが LAN クライアントからのパケットと一致しないため (ppp0 経由でルーターに入らないため)、機能しません。 インターフェース）。 2番目の PREROUTING を追加することで機能させることができます 内部 LAN クライアントのためだけのルールですが、それは洗練されておらず (IMO)、外部 IP アドレスを明示的に参照する必要があります。
さて、「ヘアピン NAT」（または「NAT ループバック」、または「NAT リフレクション」、またはそれを呼びたいもの）ソリューションを詳細に説明した後でも、私はまだスプリット ホライズン DNS ソリューションであると信じています-- -外部クライアントが外部IPに解決され、内部クライアントが内部IPに解決される場合---より推奨されるルートです。なんで？ NAT の仕組みを理解するよりも、DNS の仕組みを理解している人の方が多いため、優れたシステムを構築するためには、保守可能なパーツを使用することを選択することが重要です。 DNS セットアップは難解な NAT セットアップよりも理解される可能性が高く、したがって正しく維持されます (もちろん IMO です)。
解決策 2:
OpenWRT でデフォルトで使用される UCI 構成システムを使用して、これを正しい方法で行う方法をほぼ 8 年経っても誰も説明していないことに驚いています。
Steven Monday の答えは正しいですが、iptables を使用しています これは、UCI 構成システムよりも下位層であり、可能であればほとんどの OpenWRT ユーザーが触れないようにしておくのが最善です。
UCI の別の内部ホストからパブリック IP/ポートの組み合わせを介して内部サーバーにアクセスする正しい方法は、構成オプション reflection を有効にすることです。 ファイル /etc/config/firewall 内の特定の DNAT ターゲットごとに .この動作はここに文書化されています。
例:
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option src_dport '44322'
option dest_ip '192.168.5.22'
option dest_port '443'
option name 'apache HTTPS server'
option reflection '1'
注:示された OpenWRT ドキュメントによると、reflection デフォルトで有効になっています。私のテストでは、そうではありませんでした。
解決策 3:
一般的な解決策は、これらのホスト名に対して正しい「内部」アドレスを返すローカル DNS サーバーで内部ホストをポイントすることです。
もう 1 つの解決策は (私が Cisco ファイアウォールで作業している場所でこれを使用しています)、これらのアドレスに対応するファイアウォールの DNS 応答を書き換えることです。現在、これを行う Linux 用のツールはないと思います。
正しいことを行うために、ゲートウェイでルーティングを構成できるはずです。外部でマッピングされた IP アドレスを認識できるようにサーバーを構成する必要がある場合があります (たとえば、ダミー インターフェイスに割り当てます)。この構成では、ある内部システムから別の内部システムへの通信 (その「外部」アドレスを使用) は、ルーターを経由します。
解決策 4:
あなたがしようとしていることは NAT Loopback と呼ばれています また、LAN からサーバーへのパケットがルーターを経由して戻るように、SNAT ルールを追加する必要があります。
-A POSTROUTING -p tcp -s 192.168.2.0/24 -d 192.168.2.10 -m multiport --dports 22,25,80,443 -j SNAT --to-source 89.179.245.232