Debian StretchソースTCPポート*常に*偶数

Debian StretchソースTCPポート*常に*偶数

Azure Load Balancerを使用していくつかの奇妙な動作をデバッグしている間、ローカルのDebian Stretch TCPスタックが偶数ポートにのみTCP接続を作成することがわかりました。私は奇妙なソースポートで単一のTCPハンドシェイクを開始しません。意図的なことでしょうか?

答え1

これはconnect()との間の競合を減らすためのものですbind()(Linux 4.2に登場し、Jessieは3.16、Stretchは4.9):

犯罪07f4c90062f8fc7c8c26f8f95324cbe8fa3145a5
著者:エリックデュマセット
日付:2015年5月24日日曜日14:49:35 -0700

    tcp/dccp: connect() で ip_local_port_range を使い果たさないようにしてください。

    使用量が多いサーバーの長い問題は、使用可能なTCPポートの数が少ないことです。
    範囲(/proc/sys/net/ipv4/ip_local_port_range)とデフォルト
    connect() システムコールでソースポートを順次割り当てます。

    ホストにアクティブなTCPセッションの数が多い場合は可能です。
    非常に高い、すべてのポートが1つ以上のフローで使用されます。
    その後のバインド(0)の試行は失敗するか、ほとんどをスキャンする必要があります。
    スロットが見つかるスペースです。

    今回のパッチでは、__inet_hash_connect() の始点を変更しました。
    だから私たちは偶数[1]ポートをサポートしようとし、バインド()に奇数ポートを残します。
    ユーザー。

    まだ順次検索をしているので保証できませんが、
    connect() ターゲットが非常に異なる場合、最終結果は私たちが去ることです。
    バインド()でより多くのポートを使用できるため、範囲全体に分散します。
    スロットを見つけるのに必要なconnect()とバインディング()の時間を短縮します。

    このポリシーは、/proc/sys/net/ipv4/ip_local_port_rangeの場合にのみ有効です。
    つまり、開始/終了値のパリティが異なる場合です。

    したがって、デフォルトの/proc/sys/net/ipv4/ip_local_port_rangeは次のように変更されます。
    32768 - 60999(32768 - 61000の代わりに)

    ここではセキュリティの観点から何も変更されていません。ちょうどいくつかの間違ったハッシュだけがあります。
    計画は最終的にこれらの変更の影響を受ける可能性があります。

    [1]: 奇数/偶数属性は ip_local_port_range 値パリティに依存します。

フォローアップを読むこともできます。1580ab63fc9a03593072cc5656167a75c4f1d173送信

関連情報