PROXY プロトコルでクライアント IP を保持する
Phoenix クラスターが Layer-4（TCP）ロードバランサーの背後に配置されている場合、Coordinator Nodes（FE）は実際のクライアントではなく、すべての接続のソースとしてロードバランサーの IP アドレスを認識することがあります。これにより、次の 2 つの問題が発生します。
- IP 制限付きアカウント（例：
'user'@'203.0.113.10'）は、接続がロードバランサーから来ているように見えるため、正しく照合できません。 - 監査ログと
PROCESSLISTには、実際のクライアント IP ではなくロードバランサーの IP が記録されます。
この問題が発生するかどうかは、ロードバランサーによって異なります。
- クライアント IP 保持が有効な AWS Network Load Balancer（NLB）、同一リージョンの場合：NLB でクライアント IP 保持が有効になっており、クライアントがクラスターと同じリージョンにある場合、NLB はネットワーク層で実際のクライアント IP を透過的に保持します。この場合、FE はすでに実際のクライアント IP を認識しているため、PROXY プロトコルは不要必要ありません。
- その他のケース— たとえば HAProxy、クロスリージョン NLB トラフィック、またはクライアント IP 保持が利用できないプロキシの場合 — FE はロードバランサーの IP を認識します。実際のクライアントアドレスを復元するには PROXY プロトコルを使用してください。
カーネルバージョン 4.1.2 以降、Phoenix は MySQL ポートでHAProxy PROXY プロトコル v1をサポートしています（9030）。PROXY プロトコルが有効な場合、信頼されたロードバランサーは各接続の先頭に実際のクライアント IP とポートを含む小さなテキストヘッダーを付加します。Phoenix はこのヘッダーを解析し、認証、PROCESSLIST、および監査ログに実際のクライアントアドレスを使用します。
PROXY プロトコルv1（人間が読めるテキスト形式）のみがサポートされています。TCP4（IPv4）および TCP6（IPv6）の両方のソースアドレスが受け入れられます。
設定パラメーター
PROXY プロトコルのサポートは、以下の Coordinator Node（FE）パラメーターによって制御されます。両方のパラメーターは動的です。
| パラメーター | デフォルト | 説明 |
|---|---|---|
mysql_proxy_protocol_networks | ""（空） | ポート 9030 で PROXY プロトコル v1 ヘッダーを提供することを信頼するアップストリームピアを制御します。
|
mysql_proxy_protocol_header_timeout_ms | 1000 | 信頼されたピアから PROXY プロトコル v1 ヘッダーを読み取るためのタイムアウト（ミリ秒）。ピアアドレスが mysql_proxy_protocol_networks に一致する場合にのみ適用されます。この時間内にヘッダーが完全に受信されない場合、接続はエラーで閉じられます。無期限に待機するには 0 に設定します（非推奨）。 |
信頼されたピアが PROXY ヘッダーを送信することが期待されているにもかかわらず、欠落または不正な形式のヘッダーを送信した場合（またはタイムアウト内に何も送信しない場合）、接続は拒否され、Coordinator Node に以下のような警告がログに記録されます。
PROXY protocol header required but not received: <reason>
PROXY プロトコルヘッダーを提供できるピアは、特権アカウントで使用される IP を含む任意のクライアント IP を偽装できます。**信頼されたロードバランサーの IP 範囲のみを mysql_proxy_protocol_networks に追加してください。**信頼されていないクライアントからアクセス可能な本番環境では、* に設定しないでください。
仕組み
- ロードバランサーは、ポート
9030への各 TCP 接続の開始時に PROXY プロトコル v1 ヘッダーを送信するように設定されています。 - Phoenix は、接続しているピア（ロードバランサー）が
mysql_proxy_protocol_networksで定義された信頼済みネットワークに含まれているかどうかを確認します。- ピアが信頼されている場合、Phoenix は PROXY ヘッダーを読み取って解析し、接続のソースアドレスをヘッダーに含まれる実際のクライアント IP とポートに置き換えます。
- ピアが信頼されていないいない場合、接続は TCP ピアアドレスを使用して直接処理され、PROXY ヘッダーは期待されません。
UNKNOWNファミリーを使用するヘルスチェック接続（例：PROXY UNKNOWN\r\n）は受け入れられ、TCP ピアアドレスにフォールバックします。
PROXY プロトコルを有効にする
クラスターの PROXY プロトコルを有効にするには、次の手順に従ってください。
-
ロードバランサーが PROXY プロトコルを送信するように設定するv1リスナーの header を Phoenix ポート
9030に転送するように設定します。たとえば、対応するserver行にsend-proxyを指定して HAProxy を設定します。注記v1（テキスト）ヘッダーのみサポートされています。バイナリ形式の v2 ヘッダーはサポートされていません。AWS Network Load Balancer のネイティブ PROXY プロトコルサポートは v2 ヘッダーを送出するため、この機能とは互換性がありません。NLB を使用しており、クライアントがクラスターと同じリージョンにある場合は、PROXY プロトコルの設定が不要な NLB のクライアント IP 保持機能を優先してください。v1 ヘッダーを送出する HAProxy などのプロキシと組み合わせて PROXY プロトコルを使用してください。
-
Phoenix Cloudコンソールで、Coordinator Node パラメーター
mysql_proxy_protocol_networksおよびmysql_proxy_protocol_header_timeout_msを信頼するロードバランサーの範囲と希望するタイムアウト値に設定します。コンソールから Coordinator Node パラメーターを設定する手順については、静的パラメーターの設定をご覧ください。たとえば、
10.0.0.0/8のロードバランサーを信頼する場合:mysql_proxy_protocol_networks = 10.0.0.0/8mysql_proxy_protocol_header_timeout_ms = 1000 -
ロードバランサー経由の接続が実際のクライアント IP を報告していることを確認します。たとえば、監査ログを確認するか、
SHOW PROCESSLISTを実行してHost列にロードバランサーのアドレスではなくクライアントのアドレスが表示されていることを確認してください。