「ポートアドレス変換(PAT)は、複数のホストが同じソースポート番号を使用して同時に異なる外部接続を確立した場合に発生する競合を解決します。PATは、接続にポート番号を割り当てることがあります。利用可能なポートのプールこのポート番号を送信元ポート フィールドに挿入します。"
https://en.wikipedia.org/wiki/ネットワークアドレス変換
数千のリクエストを受け入れる、高度にスケーラブルなサーバーが数十台ある場合はどうなるでしょうか? ポートの枯渇は非常に基本的な制限 (64k) のようで、簡単に達してしまいます。
業界はこのようなシナリオにどのように対処するのでしょうか?
答え1
結局のところ、NATはNATデバイス上のルックアップテーブルに過ぎず、そこにはどの接続がどこに向かうかのマッピングが含まれています。しかし、これらのテーブルエントリはセッションごと基礎。
例えば、ホストが10.10.10.10インターネット上のサーバーと通信したい場合8.8.8.8、パブリックIPが1.1.1.1通信が発生すると、インターネット ゲートウェイは次のようなエントリのペアを作成します。
ソース | スポーツ | 行き先 | Dポート | 行動 |
---|---|---|---|---|
10.10.10.10 | 20000 | 8.8.8.8 | 80 | SNAT 10.10.10.10:20000 --> 1.1.1.1:40000 |
8.8.8.8 | 80 | 1.1.1.1 | 40000 | DNAT 1.1.1.1:40000 --> 10.10.10.10:20000 |
一見すると1.1.1.1:40000このセッションで現在占有されており、残りポート数は約 63999 個ですが、これは正確には正しくありません。これらのエントリはセッションごとに存在するため、後続の通信が発生して次のようにテーブルが構築されるのは当然です。
ソース | スポーツ | 行き先 | Dポート | 行動 |
---|---|---|---|---|
10.10.10.10 | 20000 | 8.8.8.8 | 80 | SNAT 10.10.10.10:20000 --> 1.1.1.1:40000 |
8.8.8.8 | 80 | 1.1.1.1 | 40000 | DNAT 1.1.1.1:40000 --> 10.10.10.10:20000 |
10.10.10.10 | 20001 | 8.8.8.8 | 81 | SNAT 10.10.10.10:20001 --> 1.1.1.1:40000 |
8.8.8.8 | 81 | 1.1.1.1 | 40000 | DNAT 1.1.1.1:40000 --> 10.10.10.10:20001 |
10.10.10.10 | 20002 | 8.8.4.4 | 80 | SNAT 10.10.10.10:20002 --> 1.1.1.1:40000 |
8.8.4.4 | 80 | 1.1.1.1 | 40000 | DNAT 1.1.1.1:40000 --> 10.10.10.10:20002 |
10.10.10.10 | 20003 | 8.8.4.4 | 81 | SNAT 10.10.10.10:20003 --> 1.1.1.1:40000 |
8.8.4.4 | 81 | 1.1.1.1 | 40000 | DNAT 1.1.1.1:40000 --> 10.10.10.10:20003 |
したがって、パブリック インターフェイス (通常、NAT 枯渇が懸念される場所) では、実質的に 4 つのセッションがあることがわかります。
1.1.1.1:40000 --> 8.8.8.8:80
1.1.1.1:40000 --> 8.8.8.8:81
1.1.1.1:40000 --> 8.8.4.4:80
1.1.1.1:40000 --> 8.8.4.4:81
ただし、これら 4 つのセッションは 4 つのポートを完全に消費しているわけではなく、NAT デバイスはこれら 4 つのセッションのいずれかに属するトラフィックがどこにルーティングされるかを正確に認識しています。
したがって、64k のポート制限があるように見えるかもしれませんが、実際には宛先ソケットごとに 64k 程度です (いくつかの注意事項あり)。無尽蔵ではありませんが、フラットな 64k よりは確実にスケーラブルです。