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アドレスを取得できるようにするには、プロキシプロトコルを有効にする必要があります。 詳細については、「プロキシプロトコルの有効化」をご参照ください。
プロキシプロトコルの有効化
プロキシプロトコルは、プロキシサーバとバックエンドサーバとの間で元の接続情報を渡すインターネットプロトコルである。
ほとんどの場合、リクエストがプロキシサーバーからバックエンドサーバーに転送された後、送信元クライアントIPアドレスを運ぶリクエストヘッダーは上書きされます。 送信元クライアントのIPアドレスとポートは、プロキシサーバのIPアドレスとポートに置き換えられます。 この場合、バックエンドサーバーは元の接続情報を取得できません。
プロキシプロトコルにより、プロキシサーバーは、バックエンドサーバーに渡されるリクエストヘッダーに元の接続情報をカプセル化できます。 バックエンドサーバは、プロキシプロトコルによってカプセル化された要求ヘッダを解析することによって、元の接続情報を取得することができる。 元の接続情報は、送信元IPアドレス、送信元ポート、および送信プロトコルを含む。
Proxyプロトコルは、バックエンドサーバーの元の接続情報を保存して、きめ細かいロギング、アクセス制御、およびトラフィック監視をサポートします。
プロキシプロトコルは、プロキシサーバーとバックエンドサーバーの両方で有効になっている場合にのみ有効になります。 バックエンドサーバーがProxyプロトコルヘッダーを解析できないが、Proxyプロトコルが有効になっている場合、バックエンドサーバーで解析エラーが発生し、サービスの可用性が損なわれる可能性があります。
NLBを使用すると、リスナーはプロキシプロトコルを使用して、ソースIPアドレス、宛先IPアドレス、ソースポート、宛先などの元の接続情報を保存し、元のデータを上書きせずに接続情報をTCPまたはUDPヘッダーに挿入できます。
NLBはプロキシプロトコルv2のみをサポートします。 プロキシプロトコルv2は、TCPやUDPなどの複数の伝送プロトコルをサポートします。 詳細については、「PROXYプロトコル」をご参照ください。
次のシナリオでは、NLBおよびバックエンドサーバーがProxyプロトコルを有効にして、クライアントのIPアドレスを保持する必要があります。
IPv6クライアントは、バックエンドサーバーにデプロイされたIPv4サービスにアクセスします。
NLBインスタンスは、SSL over TCPを使用するリスナーで設定されています。 SSL over TCPを使用するリスナーは、クライアントIP保存が有効になっているサーバーグループに関連付けることはできません。
NLBインスタンスのバックエンドサーバーはIPアドレスで指定されます。 このタイプのバックエンドサーバーは、クライアントIPの保存をサポートしていません。
手順
クライアントIP保存機能の有効化
前提条件
NLBサーバーグループが作成され、バックエンドサーバーがサーバーグループに追加されます。 この例では、サーバータイプのサーバーグループが作成されます。 バックエンドプロトコルはTCPで、ECS (Elastic Compute Service) インスタンスはバックエンドサーバーとして使用され、ポート80はバックエンドアプリケーションによって使用されます。 詳細については、「サーバーグループの作成と管理」をご参照ください。
NLBインスタンスが作成され、NLBインスタンスのリスナーが作成されます。 この例では、ポート80を使用するTCPリスナーが使用されます。 詳細については、「NLBインスタンスの作成と管理」および「TCPリスナーの追加」をご参照ください。
手順1: サーバーグループのクライアントIP保存が有効かどうかを確認する
NLBコンソールにログインします。
上部のナビゲーションバーで、NLBインスタンスがデプロイされているリージョンを選択します。
[サーバーグループ] ページで、管理するサーバーグループのIDをクリックします。
サーバーグループの詳細ページで、クライアントIP保存のステータスが有効かどうかを確認します。 ステータスが [無効] の場合、[基本情報の変更] をクリックして機能を有効にします。
手順2: バックエンドサーバーがクライアントIPアドレスを保持できるかどうかを確認する
NGINXアプリケーションがバックエンドサーバーにデプロイされている場合は、NGINXログをチェックして、バックエンドサーバーがクライアントIPアドレスを保持できるかどうかを判断できます。
次のコードブロックは、NGINXログのフィールドのデフォルト設定を示しています。
http {
# Default configurations
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アドレスです。
プロキシプロトコルの有効化
前提条件
NLBサーバーグループが作成され、バックエンドサーバーがサーバーグループに追加されます。 この例では、サーバータイプのサーバーグループが作成されます。 バックエンドプロトコルはTCPで、ECSインスタンスはバックエンドサーバーとして使用され、ポート80はバックエンドアプリケーションによって使用されます。 詳細については、「サーバーグループの作成と管理」をご参照ください。
NLBインスタンスが作成され、NLBインスタンスのリスナーが作成されます。 この例では、ポート80を使用するTCPリスナーが使用されます。 詳細については、「NLBインスタンスの作成と管理」をご参照ください。
説明Proxyプロトコルを有効にする前に、バックエンドサーバーがProxyプロトコルv2をサポートしていることを確認してください。
複数のリスナーが同じバックエンドサーバーグループに関連付けられている場合、すべてのリスナーでプロキシプロトコルを有効にする必要があります。
NGINX Plus R16以降のバージョンおよびオープンソースNGINX 1.13.11以降のバージョンは、Proxyプロトコルv2をサポートしています。
手順1: リスナーのプロキシプロトコルの有効化
NLBコンソールにログインします。
上部のナビゲーションバーで、NLBインスタンスがデプロイされているリージョンを選択します。
[インスタンス] ページで、管理するインスタンスのIDをクリックします。
インスタンスの詳細ページで、[リスナー] タブをクリックし、管理するリスナーのIDをクリックします。
リスナーの詳細ページで、プロキシプロトコルの有効化のステータスが有効かどうかを確認します。 プロキシプロトコルが無効になっている場合は、[リスナーの変更] をクリックしてプロキシプロトコルを有効にします。
手順2: バックエンドサーバーのプロキシプロトコルの有効化
この例では、CentOS 7.9オペレーティングシステムとNGINX 1.20.1が使用されています。 使用する環境に基づいて設定を調整します。
バックエンドサーバーにログインし、
nginx -t
コマンドを実行して設定ファイルのパスを照会します。 デフォルトのパスは/etc/nginx/nginx.conf
で、使用する環境によって異なります。Proxyプロトコルの設定を変更し、変更を保存します。 次のコードブロックは、例を示しています。
http { # Set the variable $proxy_protocol_addr, which is used to record client IP addresses. 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"'; # Specify that the listener uses port 80, and add the 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プロトコルv2で送信されるサンプルパケット
使用するバックエンドサーバーは上記の例とは異なります。サーバープロバイダーのマニュアルと [PROXYプロトコル] を参照して、Proxyプロトコルv2で定義されたパケット構造に基づいて構成の解析をカスタマイズできます。
次の例は、IPv4クライアントIPアドレスがバイナリ形式のProxyプロトコルv2ヘッダーに保持される方法を示しています。
次の例は、IPv6クライアントIPアドレスがバイナリ形式のProxyプロトコルv2ヘッダーに保持される方法を示しています。
関連ドキュメント
Application Load Balancer (ALB) 、Classic Load Balancer (CLB) 、およびNLBは、クライアントIPアドレスを保持するために異なる方法を使用します。
CLBのレイヤー4リスナーは、クライアントIPアドレスを直接保持するか、プロキシプロトコルを使用してクライアントIPアドレスを保持できます。 詳細については、「レイヤー4リスナーを有効にしてクライアントIPアドレスを保持する」をご参照ください。
CLBのレイヤー7リスナーは、X-Forwarded-Forヘッダーを使用してクライアントIPアドレスを保持します。 詳細については、「レイヤー7リスナーを有効にしてクライアントIPアドレスを保持する」をご参照ください。
ALBは、X-Forwarded-Forヘッダーを使用してクライアントIPアドレスを保持します。 詳細については、「ALBによるクライアントIPアドレスの保持」をご参照ください。