本文へ移動

受信 PROXY Protocol と上流プロキシヘッダー

ゲートウェイは逆方向の二種類のプロキシ情報を扱います。前段ロードバランサーは PROXY Protocol で実際の接続元を fn-knock に伝え、fn-knock は X-Forwarded-* などをアプリ上流へ送ります。信頼境界と設定は別です。

受信 PROXY Protocol

HAProxy、Nginx stream などの L4 ロードバランサーを使う場合、システム設定 → ゲートウェイ → PROXY Protocol で v1 / v2 を有効にし、送信を許可するプロキシの IP / CIDR を指定します。訪問者ではなく TCP 接続元のプロキシアドレスを入力します。

有効化には一つ以上の信頼元が必要です。IP / CIDR のみを受け付け、ホスト名と IPv4 / IPv6 全体のネットワークは拒否します。登録した socket peer だけが PROXY ヘッダーを送信でき、それ以外の接続では偽装した X-Forwarded-ForX-Real-IP で上書きできません。

PROXY Protocol に認証はありません。クライアント許可リストや広い公開範囲を流用せず、固定プライベートアドレスとネットワーク制限を使ってください。管理対象 FRP は必要な設定を自動的に有効化します。

保存時はゲートウェイ設定を検証してトランザクションとして適用します。変更後、外部経路からアクセスし、リクエストログで socket peer とクライアント IP を確認してください。

HTTP プロキシヘッダーを上流へ転送

fn-knock がリクエストをリバースプロキシする際、アップストリームサービスが元のプロトコル、アクセス先 Host、クライアントアドレスを必要とすることがあります。システム設定 → ゲートウェイ → プロキシヘッダー では、ゲートウェイからアップストリームへ X-Forwarded-* などのプロキシヘッダーを送信するかどうかを、リバースプロキシ用サービス Host ごとに設定できます。この項目は、Host ルーティングを使うサブドメインモードでのみ編集できます。これには、グローバル IP から直接公開する サブドメインモード と、トンネル → サブドメインマッピング が含まれます。パスモード、直接接続モード、静的ファイルまたはディレクトリのレスポンスでは利用できません。静的レスポンスにはアップストリームがないためです。

有効にすると、アップストリームアプリはこれらのヘッダーに基づいて、正しい外部リンクの生成、HTTPS の判定、クライアントアドレスの記録、信頼するプロキシの設定を行えます。無効にすると、通常アプリから見えるのは fn-knock とアプリ間の接続情報だけです。

画面にはリバースプロキシ Host だけが表示されますが、実行時にはアップストリームの Target 単位で設定が反映されます。複数の Host が同じ Target を共有している場合、どれか 1 つの Host でプロキシヘッダーを無効にすると、同じ Target を共有する他の Host にも影響します。異なる設定が必要な場合は、それぞれ別の Target を使用してください。

アップストリーム側の設定

プロキシヘッダーを送信しても情報が渡されるだけで、アップストリームが自動的にその情報を使用するわけではありません。アプリまたはその前段の Web サーバーでも、次の設定が必要です。

  1. fn-knock の接続元アドレスまたは所属ネットワークを、信頼するプロキシとして設定します。
  2. 実際に使用するプロキシヘッダー名を指定します。
  3. 外部 URL、HTTPS の判定、アクセスログ内のクライアント IP を確認します。

アップストリームがあらゆる送信元からの X-Forwarded-For を信頼すると、攻撃者が fn-knock を迂回してアップストリームへ直接接続した際に、アドレスを偽装できます。アップストリームのリッスン範囲を限定するか、ファイアウォールで fn-knock からのアクセスだけを許可してください。

使用上の原則

  • アップストリームアプリが必要とし、これらのヘッダーを正しく処理できる場合にだけ有効にします。
  • アップストリームアプリが信頼するのは、fn-knock から届いたプロキシヘッダーだけにします。任意のクライアントが偽装した X-Forwarded-For を受け入れないようにしてください。
  • CDN、FRP、Tunnel が fn-knock の前段にある場合、前段の経路で、外部クライアントが偽装できる実 IP ヘッダーを削除または上書きする必要があります。その後、fn-knock が識別したクライアント IP をリクエストログで確認します。
  • 変更後、リクエストログとアップストリームのアクセスログを使って、Host、プロトコル、クライアント IP を照合します。

この設定が影響するのは、fn-knock からアップストリームへ送信するヘッダーだけです。fn-knock が受信リクエストのクライアント IP を識別する方法を決めるものではなく、信頼するプロキシのリストとしても機能しません。受信元の識別には、前段の経路で実 IP ヘッダーが正しく処理されている必要があります。デプロイ後は、必ずリクエストログで検証してください。

QQ コミュニティ:1081609274