クライアントの送信元IPを取得する方法

特定の状況において、私たちのサービスは、特定のビジネスやセキュリティ上の理由からクライアントIPを使用する必要があります。しかし、通常のシナリオでは、トラフィックが実際のサービスに到達する前に、複数のネットワーク、ロードバランサー、またはプロキシサービスを通過します。このプロセスの各層で、元のクライアントIPが失われる可能性があり、私たちのサービスには前のネットワークのIPしか残らないことがあります。この結果は私たちにとって理想的ではありません。

私たちの技術スタックの複雑さにより、クライアントIPを取得するには、さまざまな方法を組み合わせて使用する必要があります。

NATを介したクライアントIPの管理

ユーザーが設立またはリースした特定のIDCインフラストラクチャでは、私たちのサービスはゲートウェイの背後にある別のLANネットワークに存在する場合があります。クライアントが外部ネットワークから私たちのサービスに接続しようとすると、トラフィックはゲートウェイを通過します。

同様のシナリオは、クラウドサービスを利用する場合にも発生する可能性があります。パブリッククラウドプラットフォームが提供するVPCネットワークは、他のVPCやインターネットから隔離された独立したLANネットワークとして機能します。その結果、外部インターネットにアクセスし、外部サービスに接続するためにはゲートウェイが必要です。

このゲートウェイは、ルーターやファイアウォールデバイスである可能性があり、通常、内部サービスに対してDNAT（Destination NAT）アドレス変換サービスを提供します。これには、ゲートウェイが1つ以上のパブリックIPアドレスを保持し、パブリックIPの特定のポートからのトラフィックを内部IPの特定のポートに転送することが含まれます。ゲートウェイはトラフィックの転送とポートマッピングを管理します。しかし、ゲートウェイが元のIPパケットヘッダーの送信元アドレスを変更するため、内部ネットワーク内の私たちのサービスは、実際のクライアントアドレスではなく、ゲートウェイのIPアドレスのみを識別できます。

歴史的に、ネットワークデバイスやソフトウェアが提供するDNAT機能は比較的基本的でした。これらは主にレイヤー3で動作し、より深い層のペイロードに対する認識や操作能力がありませんでした。それらの主な目的はサービスの公開であり、クライアントIPを下流に渡すことはできませんでした。さらに、これらのデバイスやソフトウェアのパフォーマンス制限により、アクティブな接続数や新しい接続の最大数に制約がありました。ハードウェアのアップグレードなしにスケーリングすることはしばしば困難であり、今日の動的な環境に適応するのが難しかったです。

これらの制限に対処するために、より高度なトラフィック操作能力を持つロードバランシングに頼ります。

ロードバランシングにおけるクライアントIP

一般的に、ロードバランシングは、その動作層に基づいて主に2つのタイプに分類されます：レイヤー4とレイヤー7で、それぞれTCPデータストリームとアプリケーショントラフィック（HTTPで表される）に対応します。

IPゲートウェイとは異なり、ロードバランシングはIPパケットヘッダーを変更しません。IPパケットレベルでは、透明な転送のみを行います。その結果、前述のDNATとは対照的に、ロードバランシングはIPパケットに含まれる送信元IPをロードバランサーの背後にあるコンポーネントに正しく渡すことができます。

レイヤー4ロードバランシングでは、基本的なトラフィック転送を達成した後、後続のサービスは特別な処理を必要とせずにクライアントIPを正確に取得できます。例外的なシナリオでは、Proxy Protocolを利用できます。これには、元のトラフィックペイロードの前に新しいセクションを追加し、クライアントIPを含めることが含まれます。ロードバランサーの背後にある他のリバースプロキシサーバーやサービス自体がProxy Protocolデータを解釈してクライアントIPを取得できます。

レイヤー7ロードバランシングでは、より深いトラフィック処理能力を持っています。HTTPプロトコルレベルで送信元IPを直接伝えることができます。一般的なアプローチは、X-Forwarded-For HTTPヘッダーの使用です。ロードバランシングコンポーネントは、トラフィックのIPパケットから送信元IPを抽出し、その後HTTPリクエストを解析して書き換えます。リクエストヘッダーに新しいXFFフィールドを挿入し、クライアントIP値を含めます。

HTTPSは、その暗号化されたペイロードのために特に課題となります。これにより、ロードバランシングコンポーネントはHTTPヘッダーを直接操作できません。このような状況では、以下のアプローチを検討できます：

特定の要件がない場合、HTTPSトラフィックを標準のTLSトラフィックとして扱い、レイヤー4で直接転送することができます。このシナリオでは、クライアントIPは依然としてIPパケットヘッダーを介してロードバランサーの背後にあるサービスに伝達されます。
レイヤー7機能が必要な場合、ロードバランシングコンポーネントにTLS証明書をホストすることでTLS終端を可能にします。このプロセスには、ロードバランシング層でTLS暗号化を解除し、ロードバランサーの背後にあるLANで平文のHTTPを使用するか、直接転送する代わりにサービスへの新しいHTTPS接続を確立することが含まれます。これにより、ロードバランシングコンポーネントは再び元のHTTPトラフィックを処理し、XFFメソッドを使用してIPを渡し続けることができます。

微妙なトラフィック処理を通じて、ロードバランシングはバックエンドサービスにクライアントIPを伝えるためのさまざまな方法を提供します。ロードバランシングコンポーネントの代表的な実装には、クラウドベースのELBサービス、ハードウェアベースのF5 BIG-IP、Linuxカーネルに基づくLinux Virtual Server（LVS）、ユーザーソフトウェアベースのNGINXがあります。

Client_IP_1

CDNサービスにおけるクライアントIPの伝達

時折、私たちはパブリッククラウドプラットフォームが提供するCDNサービスを利用して、ユーザーが私たちのサービスにアクセスする速度を向上させます。それらの機能はレイヤー7リバースプロキシサーバーに似ていますが、より広い文脈では、CDNはロードバランシングの一部と見なすことができます。

CDNサービスは通常、TLS終端機能を提供し、サービスに送信されるHTTPリクエストにクライアントIPを含めることができます。例えば、AWS CloudFront CDNサービスは、XFFメソッドを使用してクライアントIPを渡すことをサポートしており、レイヤー7ロードバランシングで使用されるアプローチに似ています。

APIゲートウェイの利用

ロードバランシングコンポーネントは通常、トラフィックに対する基本的な制御機能を提供しますが、クラウドベースまたはハードウェアロードバランサーが提供するAPIは、私たちの特定のビジネスニーズに合わせるのが難しい場合があります。このようなシナリオでは、私たちのサービスに合わせた戦略を適用するために、より適応性の高いコンポーネントに頼ります。これが、Apache APISIXやAPI7 EnterpriseのようなAPIゲートウェイの出番です。

APISIXとAPI7 EnterpriseはProxy Protocolをサポートしており、ロードバランサーからクライアントIPを取得できます。

さらに、NGINXのngx_http_realip_moduleに似た「real-ip」というプラグインを備えています。このプラグインは、クライアントのIPをソースから取得し、下流への伝達とロギングに使用します。APISIXとAPI7 Enterpriseのreal-ipプラグインは、NGINXの機能を強化しています。リアルソースIP機能を動的に有効または無効にすることができ、HTTPヘッダーやProxy Protocolに限定されていたngx_http_realip_moduleの制約を超えて、クライアントIPのソースを拡張します。クエリパラメータやPOSTフォームフィールドなど、NGINXやAPISIXの拡張変数を利用できます。

Client_IP_2