このトピックでは、X-Forwarded-For リクエストヘッダーを使用して、Classic Load Balancer(CLB)のレイヤー 7 リスナーがクライアント IP アドレスを保持できるようにする方法について説明します。
X-Forwarded-For のしくみ
HTTP および HTTPS リスナーは、X-Forwarded-For ヘッダーをサポートしています。バックエンドサーバーが X-Forwarded-For ヘッダーからクライアント IP アドレスを取得するように構成できます。
X-Forwarded-For の形式:
X-Forwarded-For: <Client IP address, IP address of Proxy Server 1, IP address of Proxy Server 2, ...>したがって、X-Forwarded-For ヘッダーに含まれる一番左側の IP アドレスがクライアント IP アドレスです。
CLB の HTTPS リスナーは、CLB 上の リクエストを暗号化します。ただし、CLB は HTTP を介してバックエンドサーバーと通信します。したがって、HTTPS リスナーを使用している場合でも、バックエンドサーバーは HTTP を使用します。
手順
前提条件
CLB インスタンスが作成されています。CLB インスタンス用にレイヤー 7 リスナーが作成されています。この例では、ポート 80 を使用する HTTP リスナーを使用します。詳細については、「CLB インスタンスの作成と管理」および「HTTP リスナーの追加」をご参照ください。
CLB インスタンス用にサーバーグループが作成されています。バックエンドサーバーがサーバーグループに追加されています。この例では、Elastic Compute Service(ECS)インスタンスを含み、HTTP とポート 80 を使用する vServer グループを使用します。詳細については、「vServer グループの作成と管理」をご参照ください。
ステップ 1: X-Forwarded-For に基づくクライアント IP の保持がリスナーで有効になっているかどうかを確認する
CLB コンソール にログインします。
上部のナビゲーションバーで、CLB インスタンスがデプロイされているリージョンを選択します。
[インスタンス] ページで、管理する CLB インスタンスの ID をクリックします。
インスタンスの詳細ページで、[リスナー] タブをクリックし、管理するレイヤー 7 リスナーの ID をクリックします。
リスナーの詳細ページで、[カスタム HTTP ヘッダー] に [x-forwarded-for: クライアント IP の取得] オプションが含まれているかどうかを確認します。
説明デフォルトでは、CLB のレイヤー 7 リスナーは、X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを保持します。このヘッダーは無効にすることができません。
ステップ 2: バックエンドサーバーを構成する
以下の手順は、バックエンドサーバーを構成する方法を示しています。使用するバックエンドサーバーのタイプに基づいて手順を選択してください。
NGINX サーバーを構成する
この例では、CentOS 7.9 オペレーティングシステムと NGINX 1.20.1 を使用します。使用する環境に基づいて構成を調整してください。
NGINX サーバーで
nginx -V | grep http_realip_moduleコマンドを実行して、http_realip_module モジュールが NGINX サーバーにインストールされているかどうかを確認します。NGINX サーバーは、http_realip_module モジュールを使用して X-Forwarded-For の値を解析します。出力に
--with-http_realip_moduleが含まれている場合、http_realip_module が NGINX サーバーにインストールされていることを示しており、次のステップに進むことができます。説明2011 年にリリースされた NGINX 1.0.4 以降は、http_realip_module モジュールをサポートしています。NGINX のバージョンが 1.0.4 より前の場合は、データをバックアップし、新しいバージョンにアップグレードすることをお勧めします。
http_realip_module モジュールが NGINX サーバーにインストールされていない場合は、NGINX を再コンパイルおよびインストールしてから、http_realip_module をインストールします。YUM などのパッケージマネージャーを使用して NGINX をインストールおよび管理することをお勧めします。パッケージマネージャーはプロセスを簡素化します。
NGINX 構成ファイルを変更して保存します。次のコードブロックは例を示しています。
nginx -tコマンドを実行して、構成ファイルのパスをクエリします。デフォルトでは/etc/nginx/nginx.confです。パスは、使用する環境によって異なる場合があります。http { # X-Forwarded-For の値を記録するために使用される変数 $http_x_forwarded_for を設定します。 log_format main '$remote_addr- $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; # ... }sudo nginx -s reloadコマンドを実行して、NGINX 構成ファイルを再読み込みします。
Apache サーバーを構成する
この例では、CentOS 7.9 オペレーティングシステムと Apache 2.4.6 を使用します。使用する環境に基づいて構成を調整してください。
Apache サーバーで
httpd -M | grep remoteip_moduleコマンドを実行して、remoteip_module モジュールが Apache サーバーにインストールされているかどうかを確認します。Apache は remoteip_module を使用して X-Forwarded-For の値を解析します。出力に
remoteip_module (shared)が含まれている場合、モジュールが Apache サーバーにインストールされていることを示しており、次のステップに進むことができます。説明2012 年にリリースされた Apache 2.4.0 以降は、remoteip_module モジュールをサポートしています。Apache のバージョンが 2.4.0 より前の場合は、データをバックアップし、新しいバージョンにアップグレードすることをお勧めします。
remoteip_module モジュールが Apache サーバーにインストールされていない場合は、Apache を再コンパイルおよびインストールしてから、remoteip_module をインストールします。YUM などのパッケージマネージャーを使用して Apache をインストールおよび管理することをお勧めします。パッケージマネージャーはプロセスを簡素化します。
Apache 構成ファイルを変更して保存します。次のコードブロックは例を示しています。構成ファイルのデフォルトパスは
/etc/httpd/conf/httpd.confです。パスは、使用する環境によって異なる場合があります。# ... <IfModule log_config_module>sudo systemctl restart httpdコマンドを実行して、Apache を再起動します。
IIS サーバーを構成する
この例では、Windows Server 2016 オペレーティングシステムを使用します。使用する環境に基づいて構成を調整してください。
F5XForwardedFor ファイル をダウンロードして解凍します。
F5XFFHttpModule.dllファイルとF5XFFHttpModule.iniファイルをx86\またはx64ディレクトリから IIS サーバーのディレクトリにコピーします。IIS プロセスがディレクトリに対する読み取りおよび書き込み権限を持っていることを確認してください。[サーバーマネージャー] で [IIS マネージャー] を開きます。
IIS サーバーを選択し、[モジュール] をダブルクリックします。

[ネイティブモジュールの構成] をクリックし、表示されるダイアログボックスで [登録] をクリックします。

ダウンロードした .dll ファイルを追加します。
ファイル名を入力し、パスを選択して、[OK] をクリックします。

登録するモジュールが自動的に選択されます。[OK] をクリックします。
IIS マネージャーのホームページに戻り、[ログ] をダブルクリックします。
X-Forwarded-Forに関する情報を記録するログ形式を構成します。[フィールドの選択] をクリックします。

左下隅にある [フィールドの追加] をクリックし、次のフィールドを追加して、[OK] をクリックします。

右側のアクションペインで [適用] をクリックします。
IIS サーバーを再起動し、構成が有効になるまで待ちます。
ステップ 3: バックエンドサーバーがクライアント IP アドレスを取得できるかどうかをテストする
以下の手順は、テストを実行する方法を示しています。使用するバックエンドサーバーのタイプに基づいて手順を選択してください。
NGINX サーバー
NGINX サーバーを使用している場合は、NGINX ログを確認して、バックエンドサーバーがクライアント IP アドレスを取得できるかどうかを判断できます。
NGINX ログのデフォルトパスは /var/log/nginx/access.log です。
各ログエントリで、$http_x_forwarded_for 変数の一番左側の IP アドレスがクライアント IP アドレスです。

Apache サーバー
Apache サーバーを使用している場合は、Apache ログを確認して、バックエンドサーバーがクライアント IP アドレスを取得できるかどうかを判断できます。
Apache ログのデフォルトパスは /var/log/httpd/access_log です。
各ログエントリで、%{X-Forwarded-For}i 変数の一番左側の IP アドレスがクライアント IP アドレスです。

IIS サーバー
IIS サーバーを使用している場合は、IIS ログを確認して、バックエンドサーバーがクライアント IP アドレスを取得できるかどうかを判断できます。
ログファイルへのパスは、ログモジュールにあります。

各ログエントリで、X-Forwarded-For の一番左側の IP アドレスがクライアント IP アドレスです。

FAQ
100 で始まる IP アドレスがバックエンド ECS インスタンスに頻繁にアクセスするのはなぜですか?
CLB は、システムサーバーのプライベート IP アドレスを使用して、外部リクエストをバックエンド ECS インスタンスに転送します。また、CLB は ECS インスタンスにアクセスして、ヘルスチェックを実行し、サービスの可用性を監視します。
CLB のシステム CIDR ブロックは 100.64.0.0/10 で、Alibaba Cloud によって予約されています。セキュリティの問題を防ぐため、この CIDR ブロックは他のネットワーク要素に割り当てられていません。その結果、バックエンド ECS インスタンスは 100 で始まる IP アドレスからアクセスされます。
サービスの可用性を確保するために、これらの IP アドレスからのアクセスをすべてのバックエンドサーバーに許可するセキュリティルールを追加することをお勧めします。
Web Application Firewall(WAF)、Content Delivery Network(CDN)、または Global Accelerator(GA)と組み合わせて使用する場合、CLB はどのようにクライアント IP アドレスを保持しますか?
リクエストが CLB に到達する前に WAF、CDN、または GA によってフィルタリングされる場合、X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを保持できます。WAF、CDN、および GA は、デフォルトで X-Forwarded-For ヘッダーをバックエンドサーバーに渡すことができます。追加の構成は必要ありません。
サービスのセキュリティを損なう可能性のある X-Forwarded-For なりすましを防ぐには、クライアント IP アドレスを記録するヘッダーを指定できます。たとえば、リクエストがクライアント、CDN、WAF、CLB、および ECS を経由し、CDN が Ali-Cdn-Real-Ip ヘッダーをバックエンドサーバーに渡す場合、Ali-Cdn-Real-Ip を有効にしてクライアント IP アドレスを記録し、$http_Ali_Cdn_Real_Ip 変数を NGINX 構成ファイルに追加できます。$http_Ali_Cdn_Real_Ip によって記録された IP アドレスがクライアント IP アドレスです。
システムのセキュリティを向上させるために、次の対策を講じることもできます。
X-Forwarded-For ヘッダーを認証する: バックエンドサーバーが無効または信頼できない X-Forwarded-For ヘッダーを含むリクエストをフィルタリングできるようにします。X-Forwarded-For ヘッダーの形式と IP アドレスを確認して、有効で信頼できるかどうかを判断できます。
ファイアウォールとアクセス制御リスト(ACL)を有効にする: CLB とそのバックエンドサーバーの間にファイアウォールと ACL をデプロイして、X-Forwarded-For ヘッダーを操作する可能性のある悪意のあるリクエストをフィルタリングします。
SSL/TLS 暗号化を有効にする: SSL/TLS 暗号化を有効にして、X-Forward-For ヘッダーの送信を含むデータ送信を暗号化します。この対策により、中間者攻撃(MITM)とデータ改ざんを防ぎます。
Container Service for Kubernetes(ACK)クラスタにデプロイされている場合、CLB はどのようにクライアント IP アドレスを保持しますか?
CLB は、ACK クラスタにデプロイされている場合、クライアント IP アドレスを保持できます。クライアント IP の保持は、さまざまな方法で実装できます。詳細については、「ポッドがクライアントの実際の IP アドレスを取得するように構成するにはどうすればよいですか?」をご参照ください。
関連情報
Application Load Balancer(ALB)、Classic Load Balancer(CLB)、および NLB は、クライアント IP アドレスを保持するために異なる方法を使用します。
ALB は、X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを保持します。詳細については、「ALB がクライアント IP アドレスを保持し、バックエンドサーバーに渡すことを有効にする」をご参照ください。
NLB は、バックエンドサーバーグループのクライアント IP 保持機能または Proxy プロトコルを使用して、クライアント IP アドレスを保持します。詳細については、「NLB がクライアント IP アドレスを保持することを有効にする」をご参照ください。
CLB のレイヤー 4 リスナーは、クライアント IP アドレスを直接保持するか、Proxy プロトコルを使用してクライアント IP アドレスを保持できます。詳細については、「レイヤー 4 リスナーがクライアント IP アドレスを保持することを有効にする」をご参照ください。