クラシックロードバランサー(CLB)のレイヤー 4 リスナーは、クライアント IP アドレスを保持し、バックエンドサーバーに渡すことができます。ほとんどの場合、バックエンドサーバーはクライアント IP アドレスを直接取得できます。追加の構成は必要ありません。IPv6 クライアントが IPv4 サービスにアクセスするシナリオでは、バックエンドサーバーがクライアント IP アドレスを取得できるように、レイヤー 4 リスナーとバックエンドサーバーの両方で Proxy プロトコルを有効にする必要があります。
バックエンドサーバーがクライアント IP アドレスを取得する方法

クライアント IP アドレスを直接取得する
ほとんどの場合、レイヤー 4 リスナーはソース IP アドレスをバックエンドサーバーに渡します。バックエンドサーバーが取得するソース IP アドレスは、クライアント IP アドレスです。
一部のシナリオでは、この機能は有効になりません。バックエンドサーバーがクライアント IP アドレスを取得できるように、Proxy プロトコルを有効にする必要があります。詳細については、「Proxy プロトコルを有効にする」をご参照ください。
Proxy プロトコルを有効にする
Proxy プロトコルは、プロキシサーバーとバックエンドサーバー間で元の接続情報を渡すインターネットプロトコルです。
ほとんどの場合、プロキシサーバーはソースクライアント IP アドレスを保持するリクエストヘッダーを上書きし、リクエストをバックエンドサーバーに転送します。ソースクライアント IP アドレスとポートは、プロキシサーバーの IP アドレスとポートに置き換えられます。このシナリオでは、バックエンドサーバーは元の接続情報を取得できません。
Proxy プロトコルを使用すると、プロキシサーバーは元の接続情報をリクエストヘッダーにカプセル化し、バックエンドサーバーに渡すことができます。バックエンドサーバーは、Proxy プロトコルによってカプセル化されたリクエストヘッダーを解析することにより、元の接続情報を取得できます。元の接続情報には、ソース IP アドレス、ソースポート、および伝送プロトコルが含まれます。
バックエンドサーバーによって取得された元の接続情報は、ロギング、アクセスの制御、およびトラフィックの監視にさらに使用できます。
Proxy プロトコルは、プロキシサーバーとバックエンドサーバーの両方で有効になっている場合にのみ有効になります。バックエンドサーバーが Proxy プロトコルヘッダーを解析できないが Proxy プロトコルが有効になっている場合、バックエンドサーバーで解析エラーが発生し、サービスの可用性が損なわれる可能性があります。
レイヤー 4 リスナーは、Proxy プロトコルを使用して、ソース IP アドレス、宛先 IP アドレス、ソースポート、宛先ポートなどの元の接続情報を保持し、その情報を TCP または UDP ヘッダーにカプセル化できます。 Proxy プロトコルは、元の接続情報を破棄したり上書きしたりしません。
CLB は Proxy protocol v2 のみをサポートしています。Proxy protocol v2 は、TCP や UDP などの複数の伝送プロトコルをサポートしています。詳細については、「The PROXY protocol」をご参照ください。
IPv6 クライアントが CLB インスタンスを介して IPv4 サービスにアクセスするシナリオでは、バックエンドサーバーがクライアント IP アドレスを取得できるように、レイヤー 4 リスナーとバックエンドサーバーの両方で Proxy プロキシを有効にする必要があります。
手順
クライアント IP アドレスを直接取得する
このシナリオでは、バックエンドサーバーはクライアント 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 プロトコルを有効にする
前提条件
CLB インスタンスが作成され、リスナーが作成されます。この例では、ポート 80 でリッスンする TCP リスナーが作成されます。詳細については、「CLB インスタンスの作成と管理」および「TCP リスナーを追加する」をご参照ください。
CLB インスタンスのサーバーグループが作成され、バックエンドサーバーがサーバーグループに追加されます。この例では、バックエンドプロトコルとして TCP を使用する vServer グループが作成されます。ポート 80 を使用してリクエストを受信する Elastic Compute Service(ECS)インスタンスが vServer グループに追加されます。詳細については、「vServer グループの作成と管理」をご参照ください。
説明Proxy プロトコルを有効にする前に、バックエンドサーバーが Proxy protocol v2 をサポートしていることを確認してください。
NGINX Plus R16 以降のバージョンとオープンソース NGINX 1.13.11 以降のバージョンは、Proxy protocol v2 をサポートしています。
バックエンドサーバーグループのバックエンドサーバーが CLB インスタンスの複数のリスナーに接続されている場合は、これらのすべてのリスナーで Proxy プロトコルを有効にする必要があります。
手順 1:リスナーの Proxy プロトコルを有効にする
CLB コンソール にログインします。
上部のナビゲーションバーで、CLB インスタンスがデプロイされているリージョンを選択します。
[インスタンス] ページで、管理する CLB インスタンスの ID をクリックします。
インスタンスの詳細ページで、[リスナー] タブをクリックし、レイヤー 4 リスナーを見つけて、その ID をクリックします。
リスナーの詳細ページで、[proxy プロトコル] パラメーターは [proxy プロトコルを使用してクライアント IP アドレスをバックエンドサーバーに渡す] に設定されています。パラメーターが表示されない場合は、[リスナーの変更] をクリックして Proxy プロトコルを有効にします。
重要この機能はシームレスな移行をサポートしていません。Proxy プロトコルを有効にするには、CLB はビジネスを一時停止して更新する必要があります。注意して進めてください。
手順 2:バックエンドサーバーで Proxy プロトコルを有効にする
この例では、CentOS 7.9 オペレーティングシステムと NGINX 1.20.1 を使用しています。使用する環境に基づいて構成を調整してください。
バックエンドサーバーにログインし、
nginx -tコマンドを実行して構成ファイルのパスをクエリします。デフォルトパスは/etc/nginx/nginx.confですが、使用する環境によって異なる場合があります。Proxy プロトコルの構成を変更し、変更を保存します。次のコードブロックは例を示しています。
http { // $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 アドレスがどのように保持されるかを示しています。

よくある質問
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 アドレスを保持する」をご参照ください。