私は2つの実験をしました。 2つのネットワークは次のとおりです。
[private network] [public network]
A -------------------- R ----------------- B
192.168.0.5 192.168.0.1|192.0.2.1 192.0.2.8
ㅏデフォルトゲートウェイは右。右IPv4 転送が有効になっており、次の iptables ルールがあります。
iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE --to-ports 50000
目的はTCPからの着信トラフィックですㅏマスキングに192.0.2.1を使用します。右ポート50000
ポート60000にTCPサービスを公開しました。第二使用nc -4l 192.0.2.8 60000。
その後、接続を開きました。ㅏ:nc -4 192.0.2.8 60000
ㅏ次のようにパケット転送を開始します。
192.168.0.5:53269 -> 192.0.2.8:60000
右それを翻訳する
192.0.2.1:50000 -> 192.0.2.8:60000
今まではそんなに良くなった。
その後、次のクライアントを開こうとします。右：nc -4 192.0.2.8 60000 -p 50000。メッセージを送りましたが、何も起こりませんでした。パケットを見ることができません右tcpdump.tcpdump.
変装ルールが存在するため、または少なくともアクティブになっているので、期待していたでしょう。右2つのncを同じポートにバインドすると、発生した「nc：アドレスはすでに使用中です」というエラーメッセージが表示され、ncは失敗します。
次に、conntrack マッピングが消えるまでしばらく待ちます。
2番目の実験は私が開こうとしたものです。右顧客が最初です。右次に始める第二まさに。その後、接続を開くとㅏ、対応するパケットは無視されます。ㅏSYN到着右、しかし応答を受け取らない。 ICMPエラーにも応答しません。原因かどうかはわかりませんが右仮面舞踏会ポートが不足しているか、Linuxが完全に混乱しているためです（技術的にはポートをブロックしていますが、すでに確立されている接続が何らかの方法で妨げられています）。
NATの動作が間違っているようです。誤って masquerading (特に iptables ルール中に指定されていない) および services 用のポートを設定でき、--to-portsカーネルは自動的に切断されました。私もそのような記録はどこにもありません。
たとえば、
- ㅏ通常のリクエストをしてみてください第二。右50kのポートマスクを使用してください。
- ㅏDNSクエリの作成右。それだけです。時間再帰的であり、右（偶然一時ポート50kを使用）特権ネームサーバークエリジポート53から。
ちょうど衝突が起こった。右次に、2 つの個別 TCP 接続にポート 50k を使用します。
私はこれが通常ルータにサービスを公開しないからだと思います。もしそうなら、TCPポートプールからポートを「借りる」ことは、カーネルが積極的に偽装しているときにカーネルに害を及ぼしますか？
私の一時ポートを私のポートと組み合わせることができることを知っています--to-ports。しかし、これがデフォルトの動作ではないようです。 NATと一時ポートの両方がデフォルトで32768-61000に設定されています。これは不気味です。
(/proc/sys/net/ipv4/ip_local_port_range を照会して一時的な範囲を見つけ、別の実験で単に多数のUDP要求をNATし、サーバー側でソースポートを印刷してNAT範囲を見つけました.範囲を印刷する方法が見つかりません。
ベストアンサー1
TCPポートプールからポートを「借りる」ことは、カーネルが活発に偽装されているときにカーネルに害を及ぼしますか？
私は答えが「いいえ、でも構いません」と思います。
私は間違って推測しました。右応答パケットの宛先送信アドレスのみを使用して、パケットが次の方向にあることを確認します。ㅏまたはそれ自体。実際、接続を識別するために、送信元宛先転送アドレスタプル全体を使用しているようです。したがって、NATが同じ接続を使用して複数の接続を作成するのは実際には正常です（右has) ポートが存在すると混乱は発生しません。したがって、TCP / UDPポートプールは重要ではありません。
今考えてみると、これはあまりにも当然のことだ。
その後、次のクライアントを開こうとします。右：
nc -4 192.0.2.8 60000 -p 50000。メッセージを送りましたが、何も起こりませんでした。パケットを見ることができません右tcpdump.tcpdump.
これは私が台無しにした実験の一部です。
ソースが原因で障害が発生します。そして送信元アドレスが同じであるためではなく、宛先転送アドレスも同じです。
これはnc -4 192.0.2.8 60001 -p 50000実際に機能します。 NATマスクと同じポートを使用しても同様です。
NATの動作が間違っているようです。誤って masquerading (特に iptables ルール中に指定されていない) および services 用のポートを設定でき、
--to-portsカーネルは自動的に切断されました。
シールド接続のせいではありません。右- 開始された接続の宛先が異なる可能性が高い。
変装ルールが存在するため、または少なくともアクティブになっているので、期待していたでしょう。右2つのncを同じポートにバインドすると、発生した「nc：アドレスはすでに使用中です」というエラーメッセージが表示され、ncは失敗します。
私はまだこの質問に対する明確な答えを探していますが、すべてが「これは実装方法による否定的な結果であり、私たちが喜んで取るのに十分小さい」と指摘しているようです。