Network Load Balancer(NLB)のレイヤー 4 リスナーは、バックエンドサーバーと連携してクライアント IP アドレスを保持できます。ほとんどの場合、バックエンドサーバーでクライアント IP アドレスの保持が有効になっている場合、バックエンドサーバーはクライアント IP アドレスを取得できます。 IPv6 クライアントが IPv4 サービスにアクセスし、NLB インスタンスが SSL over TCP を使用するリスナーで構成され、NLB インスタンスのバックエンドサーバーが IP アドレスで指定されている場合、バックエンドサーバーで Proxy プロトコルが有効になっていない限り、バックエンドサーバーはクライアント IP アドレスを取得できません。
NLB がクライアント IP アドレスを保持する方法

クライアント IP アドレス保持機能を有効にする
NLB インスタンスのサーバーグループを作成するときに [クライアント IP の保持] をオンにすると、バックエンドサーバーはソース IP アドレス(クライアント IP アドレス)を取得できます。
状況によっては、この機能は有効になりません。バックエンドサーバーがクライアント IP アドレスを取得できるようにするには、Proxy プロトコルを有効にする必要があります。詳細については、「Proxy プロトコルを有効にする」をご参照ください。
Proxy プロトコルを有効にする
Proxy プロトコルは、プロキシサーバーとバックエンドサーバー間で元の接続情報を渡すインターネットプロトコルです。
ほとんどの場合、ソースクライアント IP アドレスを伝送するリクエストヘッダーは、リクエストがプロキシサーバーからバックエンドサーバーに転送された後に上書きされます。ソースクライアントの IP アドレスとポートは、プロキシサーバーの IP アドレスとポートに置き換えられます。この場合、バックエンドサーバーは元の接続情報を取得できません。
Proxy プロトコルを使用すると、プロキシサーバーは元の接続情報をリクエストヘッダーにカプセル化して、バックエンドサーバーに渡すことができます。バックエンドサーバーは、Proxy プロトコルによってカプセル化されたリクエストヘッダーを解析することにより、元の接続情報を取得できます。元の接続情報には、ソース IP アドレス、ソースポート、および伝送プロトコルが含まれます。
Proxy プロトコルは、バックエンドサーバーの元の接続情報を保持して、詳細なログ記録、アクセスの制御、およびトラフィックの監視をサポートします。
Proxy プロトコルは、プロキシサーバーとバックエンドサーバーの両方で有効になっている場合にのみ有効になります。バックエンドサーバーが Proxy プロトコルヘッダーを解析できないが Proxy プロトコルが有効になっている場合、バックエンドサーバーで解析エラーが発生し、サービスの可用性が損なわれる可能性があります。
NLB では、リスナーが Proxy プロトコルを使用して、ソース IP アドレス、宛先 IP アドレス、ソースポート、宛先などの元の接続情報を保持し、元のデータを上書きせずに TCP または UDP ヘッダーに接続情報を挿入できます。
NLB は Proxy protocol v2 のみをサポートしています。Proxy protocol v2 は、TCP や UDP などの複数の伝送プロトコルをサポートしています。詳細については、「The PROXY protocol」をご参照ください。
クライアント IP アドレスを保持できるようにするには、次のシナリオで NLB とバックエンドサーバーで Proxy プロトコルを有効にする必要があります。
IPv6 クライアントがバックエンドサーバーにデプロイされた IPv4 サービスにアクセスする。
NLB インスタンスが SSL over TCP を使用するリスナーで構成されている。 SSL over TCP を使用するリスナーは、クライアント IP アドレスの保持が有効になっているサーバーグループに関連付けることはできません。
NLB インスタンスのバックエンドサーバーが IP アドレスで指定されている。このタイプのバックエンドサーバーは、クライアント IP アドレスの保持をサポートしていません。
手順
クライアント IP アドレス保持機能を有効にする
前提条件
NLB サーバーグループが作成され、バックエンドサーバーがサーバーグループに追加されます。この例では、サーバータイプのサーバーグループが作成されます。バックエンドプロトコルは TCP、Elastic Compute Service(ECS)インスタンスはバックエンドサーバーとして使用され、ポート 80 はバックエンドアプリケーションによって使用されます。詳細については、「サーバーグループを作成および管理する」をご参照ください。
NLB インスタンスが作成され、NLB インスタンスのリスナーが作成されます。この例では、ポート 80 を使用する TCP リスナーが使用されます。詳細については、「NLB インスタンスを作成および管理する」および「TCP リスナーを追加する」をご参照ください。
手順 1:サーバーグループでクライアント IP アドレスの保持が有効になっているかどうかを確認する
NLB コンソール にログインします。
上部のナビゲーションバーで、NLB インスタンスがデプロイされているリージョンを選択します。
[サーバーグループ] ページで、管理するサーバーグループの ID をクリックします。
サーバーグループの詳細ページで、[クライアント IP の保持] のステータスが [有効] であることを確認します。ステータスが [無効] の場合は、[基本情報の変更] をクリックして機能を有効にします。
手順 2:バックエンドサーバーがクライアント IP アドレスを保持できるかどうかを確認する
バックエンドサーバーに NGINX アプリケーションがデプロイされている場合は、NGINX ログを確認して、バックエンドサーバーがクライアント IP アドレスを保持できるかどうかを判断できます。
次のコードブロックは、NGINX ログのフィールドのデフォルト構成を示しています。
http {
# デフォルト構成
log_format main '$remote_addr- $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
#...
}
NGINX ログのデフォルトパスは、/var/log/nginx/access.log です。
各ログエントリの最初の IP アドレスは、クライアント IP アドレスです。

Proxy プロトコルを有効にする
前提条件
NLB サーバーグループが作成され、バックエンドサーバーがサーバーグループに追加されます。この例では、サーバータイプのサーバーグループが作成されます。バックエンドプロトコルは TCP、ECS インスタンスはバックエンドサーバーとして使用され、ポート 80 はバックエンドアプリケーションによって使用されます。詳細については、「サーバーグループを作成および管理する」をご参照ください。
NLB インスタンスが作成され、NLB インスタンスのリスナーが作成されます。この例では、ポート 80 を使用する TCP リスナーが使用されます。詳細については、「NLB インスタンスを作成および管理する」をご参照ください。
説明Proxy プロトコルを有効にする前に、バックエンドサーバーが Proxy protocol v2 をサポートしていることを確認してください。
複数のリスナーが同じバックエンドサーバーグループに関連付けられている場合は、すべてのリスナーで Proxy プロトコルを有効にする必要があります。
NGINX Plus R16 以降のバージョンとオープンソース NGINX 1.13.11 以降のバージョンは、Proxy protocol v2 をサポートしています。
手順 1:リスナーの Proxy プロトコルを有効にする
NLB コンソール にログインします。
上部のナビゲーションバーで、NLB インスタンスがデプロイされているリージョンを選択します。
[インスタンス] ページで、管理するインスタンスの ID をクリックします。
インスタンスの詳細ページで、[リスナー] タブをクリックし、管理するリスナーの ID をクリックします。
リスナーの詳細ページで、[proxy プロトコルの有効化] のステータスが [有効] であることを確認します。Proxy プロトコルが無効になっている場合は、[リスナーの変更] をクリックして Proxy プロトコルを有効にします。
手順 2:バックエンドサーバーの Proxy プロトコルを有効にする
この例では、CentOS 7.9 オペレーティングシステムと NGINX 1.20.1 が使用されています。使用する環境に基づいて構成を調整してください。
バックエンドサーバーにログインし、
nginx -tコマンドを実行して、構成ファイルのパスをクエリします。デフォルトのパスは/etc/nginx/nginx.confですが、使用する環境によって異なる場合があります。Proxy プロトコルの構成を変更し、変更を保存します。次のコードブロックは例を示しています。
http { # クライアント IP アドレスを記録するために使用される変数 $proxy_protocol_addr を設定します。 log_format main '$proxy_protocol_addr - $remote_addr- $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; # リスナーがポート 80 を使用することを指定し、proxy_protocol を追加します。 server { listen 80 proxy_protocol; #... } }sudo nginx -s reloadコマンドを実行して、NGINX 構成ファイルを再読み込みします。
手順 3:バックエンドサーバーがクライアント IP アドレスを保持できるかどうかをテストする
バックエンドサーバーに NGINX アプリケーションがデプロイされている場合は、NGINX ログを確認して、バックエンドサーバーがクライアント IP アドレスを保持できるかどうかを判断できます。
NGINX ログのデフォルトパスは /var/log/nginx/access.log です。
各ログエントリで、変数 $proxy_protocol_addr の IP アドレスはクライアント IP アドレスです。

Proxy protocol v2 で送信されるサンプルパケット
使用しているバックエンドサーバーが前の例のものと異なる場合は、サーバープロバイダーのマニュアルと The PROXY protocol を参照して、Proxy protocol v2 で定義されているパケット構造に基づいて解析構成をカスタマイズできます。
次の例は、バイナリ形式の Proxy protocol v2 ヘッダーで IPv4 クライアント IP アドレスがどのように保持されるかを示しています。

次の例は、バイナリ形式の Proxy protocol v2 ヘッダーで IPv6 クライアント IP アドレスがどのように保持されるかを示しています。

FAQ
Container Service for Kubernetes(ACK)クラスタにデプロイされている場合、CLB はどのようにクライアント IP アドレスを保持しますか?
CLB は、ACK クラスタにデプロイされている場合、クライアント IP アドレスを保持できます。クライアント IP アドレスの保持は、さまざまな方法で実装できます。詳細については、「クライアントの実際の IP アドレスを取得するようにポッドを構成するにはどうすればよいですか?」をご参照ください。
関連情報
Application Load Balancer(ALB)、Classic Load Balancer(CLB)、および NLB は、クライアント IP アドレスを保持するために異なる方法を使用します。
CLB のレイヤー 4 リスナーは、クライアント IP アドレスを直接保持するか、Proxy プロトコルを使用してクライアント IP アドレスを保持できます。詳細については、「レイヤー 4 リスナーがクライアント IP アドレスを保持できるようにする」をご参照ください。
CLB のレイヤー 7 リスナーは、X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを保持します。詳細については、「レイヤー 7 リスナーがクライアント IP アドレスを保持できるようにする」をご参照ください。
ALB は、X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを保持します。詳細については、「クライアント IP アドレスを保持し、バックエンドサーバーに渡すように ALB を有効にする」をご参照ください。