Classic Load Balancer (CLB) のレイヤー4リスナーは、クライアントのIPアドレスを保持し、そのIPアドレスをバックエンドサーバーに渡すことができます。 ほとんどの場合、バックエンドサーバーはクライアントIPアドレスを直接取得できます。 追加の設定は必要ありません。 IPv6クライアントがIPv4サービスにアクセスするシナリオでは、バックエンドサーバーがクライアントIPアドレスを取得できるように、レイヤ4リスナーとバックエンドサーバーの両方に対してプロキシプロトコルを有効にする必要があります。
バックエンドサーバーがクライアントIPアドレスを取得する方法
クライアントIPアドレスの直接取得
ほとんどの場合、レイヤー4リスナーはソースIPアドレスをバックエンドサーバーに渡します。 バックエンドサーバーが取得する送信元IPアドレスは、クライアントIPアドレスです。
一部のシナリオでは、この機能は有効になりません。 バックエンドサーバーがクライアントIPアドレスを取得できるように、プロキシプロトコルを有効にする必要があります。 詳細については、「プロキシプロトコルの有効化」をご参照ください。
プロキシプロトコルの有効化
プロキシプロトコルは、プロキシサーバとバックエンドサーバとの間で元の接続情報を渡すインターネットプロトコルである。
ほとんどの場合、プロキシサーバーは、送信元クライアントのIPアドレスを含むリクエストヘッダーを上書きし、リクエストをバックエンドサーバーに転送します。 送信元クライアントのIPアドレスとポートは、プロキシサーバのIPアドレスとポートに置き換えられます。 このシナリオでは、バックエンドサーバーは元の接続情報を取得できません。
プロキシプロトコルは、プロキシサーバーが要求ヘッダーに元の接続情報をカプセル化することを可能にします。 バックエンドサーバは、プロキシプロトコルによってカプセル化された要求ヘッダを解析することによって、元の接続情報を取得することができる。 元の接続情報は、送信元IPアドレス、送信元ポート、および送信プロトコルを含む。
バックエンドサーバーによって取得された元の接続情報は、ロギング、アクセス制御、およびトラフィック監視でさらに使用できます。
プロキシプロトコルは、プロキシサーバーとバックエンドサーバーの両方で有効になっている場合にのみ有効になります。 バックエンドサーバーがProxyプロトコルヘッダーを解析できないが、Proxyプロトコルが有効になっている場合、バックエンドサーバーで解析エラーが発生し、サービスの可用性が損なわれる可能性があります。
レイヤ4リスナーは、Proxyプロトコルを使用して、送信元IPアドレス、宛先IPアドレス、送信元ポート、宛先ポートなどの元の接続情報を保持し、TCPまたはUDPヘッダーに情報をカプセル化できます。 Proxyプロトコルは、元の接続情報を破棄または上書きしません。
CLBはプロキシプロトコルv2のみをサポートします。 プロキシプロトコルv2は、TCPやUDPなどの複数の伝送プロトコルをサポートします。 詳細については、「PROXYプロトコル」をご参照ください。
IPv6クライアントがCLBインスタンスを介してIPv4サービスにアクセスするシナリオでは、バックエンドサーバーがクライアントIPアドレスを取得できるように、レイヤ4リスナーとバックエンドサーバーの両方に対してプロキシプロキシを有効にする必要があります。
手順
クライアントIPアドレスを直接取得する
このシナリオでは、バックエンドサーバーはクライアント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アドレスです。
プロキシプロトコルの有効化
前提条件
CLBインスタンスが作成され、リスナーが作成されます。 この例では、ポート80でリッスンするTCPリスナーが作成されます。 詳細については、「CLBインスタンスの作成と管理」および「TCPリスナーの追加」をご参照ください。
CLBインスタンスのサーバーグループが作成され、バックエンドサーバーがサーバーグループに追加されます。 この例では、バックエンドプロトコルとしてTCPを使用するvServerグループが作成されます。 ポート80を使用してリクエストを受信するElastic Compute Service (ECS) インスタンスがvServerグループに追加されます。 詳細については、「vServerグループの作成と管理」をご参照ください。
説明Proxyプロトコルを有効にする前に、バックエンドサーバーがProxyプロトコルv2をサポートしていることを確認してください。
NGINX Plus R16以降のバージョンおよびオープンソースNGINX 1.13.11以降のバージョンは、Proxyプロトコルv2をサポートしています。
バックエンドサーバーグループ内のバックエンドサーバーがCLBインスタンスの複数のリスナーに接続されている場合、これらすべてのリスナーに対してプロキシプロトコルを有効にする必要があります。
手順1: リスナーのプロキシプロトコルの有効化
CLB コンソールにログインします。
上部のナビゲーションバーで、CLBインスタンスがデプロイされているリージョンを選択します。
[インスタンス] ページで、管理するCLBインスタンスのIDをクリックします。
インスタンスの詳細ページで、[リスナー] タブをクリックし、レイヤー4リスナーを見つけて、そのIDをクリックします。
リスナーの詳細ページで、[プロキシプロトコル] パラメーターは [プロキシプロトコルを使用してクライアントIPアドレスをバックエンドサーバーに渡す] に設定されています。 パラメーターが表示されない場合は、[リスナーの変更] をクリックしてプロキシプロトコルを有効にします。
重要この機能はシームレスな移行をサポートしていません。 プロキシプロトコルを有効にするには、CLBはビジネスを一時停止および更新する必要があります。 作業は慎重に行ってください。
手順2: バックエンドサーバーでプロキシプロトコルを有効にする
この例では、CentOS 7.9オペレーティングシステムとNGINX 1.20.1が使用されています。 使用する環境に基づいて設定を調整します。
バックエンドサーバーにログインし、
nginx -t
コマンドを実行して設定ファイルのパスを照会します。 デフォルトのパスは/etc/nginx/nginx.conf
で、使用する環境によって異なります。Proxyプロトコルの設定を変更し、変更を保存します。 次のコードブロックに例を示します。
http { # Make sure that $proxy_protocol_addr is configured. 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 port 80 as the listener port 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アドレスです。
プロキシプロトコルv2ヘッダー形式
使用するバックエンドサーバーが上記の例と異なる場合は、サーバープロバイダーのマニュアルと「PROXYプロトコル」を参照して、Proxyプロトコルv2で定義されたヘッダー形式に基づいて構文解析構成をカスタマイズできます。
次の例は、IPv4クライアントIPアドレスがバイナリ形式のProxy Protocol v2ヘッダーに保持される方法を示しています。
次の例は、IPv6クライアントIPアドレスをバイナリ形式のProxy Protocol v2ヘッダーに保持する方法を示しています。
よくある質問
100で始まるIPアドレスがバックエンドECSインスタンスに頻繁にアクセスするのはなぜですか。
CLBは、システムサーバーのプライベートIPアドレスを使用して、外部リクエストをバックエンドECSインスタンスに転送します。 また、CLBはECSインスタンスにアクセスしてヘルスチェックを実行し、サービスの可用性を監視します。
CLBのシステムCIDRブロックは100.64.0.0/10で、Alibaba Cloudによって予約されています。 セキュリティの問題を防ぐために、このCIDRブロックは他のネットワーク要素に割り当てられません。 その結果、バックエンドECSインスタンスは、100で始まるIPアドレスによってアクセスされます。
サービスの可用性を確保するために、これらのIPアドレスからすべてのバックエンドサーバーへのアクセスを許可するセキュリティルールを追加することを推奨します。
Container Service for Kubernetes (ACK) クラスターにデプロイされた場合、CLBはどのようにクライアントIPアドレスを保持しますか。
CLBは、ACKクラスターにデプロイされるときにクライアントIPアドレスを保持できます。 クライアントIP保存は、異なる方法で実装されてもよい。 詳細については、「クライアントの実際のIPアドレスを取得するようにポッドを設定する方法」をご参照ください。
関連ドキュメント
Application Load Balancer (ALB) 、CLB、およびNetwork Load Balancer (NLB) は、クライアントIPアドレスを保持するために異なる方法を使用します。
NLBは、バックエンドサーバーグループのクライアントIP保存機能またはProxyプロトコルを使用して、クライアントIPアドレスを保存します。 詳細については、「NLBを有効にしてクライアントIPアドレスを保持する」をご参照ください。
CLBのレイヤー7リスナーは、X-Forwarded-Forヘッダーを使用してクライアントIPアドレスを保持します。 詳細については、「レイヤー7リスナーを有効にしてクライアントIPアドレスを保持する」をご参照ください。
ALBは、X-Forwarded-Forヘッダーを使用してクライアントIPアドレスを保持します。 詳細については、「クライアントIPアドレスの保存」をご参照ください。