fn-knock の前段に Tencent Cloud EdgeOne を配置
EdgeOne に fn-knock の DNS、TLS、エッジ入口を担わせる構成です。接続後も、認証用 Host とサービス用 Host は fn-knock で処理します。エッジ側で動的なログインページを静的コンテンツとしてキャッシュしたり、実クライアント IP を失ったりしないようにしてください。
接続前の確認
- fn-knock のサブドメインマッピングが、ローカルまたは公開入口で動作確認済みである。
- 公開する各 Host のアップストリームとアクセスポリシーが明確になっている。
- EdgeOne からオリジンへの接続先アドレス、ポート、プロトコルが到達可能である。
- モバイル回線からアクセスできるテスト用ドメインを用意している。
設定の要点
サブドメインマッピング → サブドメインモード設定 → エッジ経由の実クライアント IP 検出でTencent EdgeOneを選びます。ゲートウェイはEO-Connecting-IPを読み取り、復元したアドレスをクライアント IP として扱い、X-Forwarded-Forで認証サービスへ渡します。- EdgeOne にドメインを追加し、認証用 Host とサービス用 Host のオリジンを fn-knock のゲートウェイ入口に設定します。
- リクエストの Host、WebSocket の Upgrade、EdgeOne の実クライアント IP ヘッダーがオリジンまで引き継がれるようにします。
- 認証、コールバック、動的なサービスパスはキャッシュをバイパスさせます。キャッシュポリシーはアプリごとに判断し、ログインページを一律にキャッシュしないでください。
- EdgeOne で HTTPS を設定したら、公開側から認証用 Host、サービス用 Host、WebSocket / 長時間接続を使うアプリの順にテストします。
オリジン接続の設定
認証用 Host とサービス用 Host は同じオリジンアドレスとポートを共有できます。ただし、fn-knock が対応するマッピングに一致させられるよう、オリジンへのリクエストでは利用者がアクセスした Host を維持する必要があります。オリジンの転送先はゲートウェイ入口で、デフォルトは 7999 です。管理入口の 7991 や内部バックエンドの 7998 ではありません。
TLS を終端する場所に合わせて、オリジン接続のプロトコルを選びます。
| 外部 TLS | EdgeOne から fn-knock | fn-knock 側の要件 |
|---|---|---|
| EdgeOne で HTTPS を終端し、HTTP でオリジン接続 | HTTP | オリジンポートへ到達できること。前段から外部側のプロトコルを正しく伝えること |
| EdgeOne で HTTPS を終端し、HTTPS でオリジン接続 | HTTPS | fn-knock の証明書がオリジン接続時の Host をカバーし、EdgeOne がその証明書チェーンを信頼できること |
| エンドツーエンド HTTPS | HTTPS | エッジ証明書とオリジン証明書の両方を検証すること |
認証ページ、認証 API、OIDC / QQ コールバック、ログアウト、セッション状態、Cookie を設定するレスポンスは、すべてキャッシュをバイパスさせます。サービスアプリをキャッシュできるかどうかは、そのレスポンスヘッダーとログイン方式に基づいて判断してください。ファイル拡張子だけを見て静的コンテンツだと決めつけないでください。
実 IP ヘッダーの保護
EdgeOne をプロバイダーとして選ぶと、ゲートウェイは EO-Connecting-IP を信頼します。オリジンポートへ任意のインターネットクライアントが直接接続できるままだと、攻撃者が EdgeOne を迂回し、このヘッダーを偽装できる可能性があります。ファイアウォール、オリジンのアクセス制御、またはインターネットからルーティングできないオリジン接続経路を使い、ゲートウェイ入口では EdgeOne からのオリジン接続と必要な運用監視だけを受け入れてください。
切り替え前は、管理者だけが使える直接接続テスト用 Host を一時的に残しても構いません。ただし、本番サービスと広範な公開許可ルールを共有しないでください。検証後は切り戻し用 DNS を削除するか、接続元を制限します。
検証のポイント
モバイル回線と、もう 1 つの外部ネットワークから個別にアクセスし、同じ出口 IP だけでテストしないようにします。
- 認証用 Host を開き、未ログイン時に認証ページが表示されることを確認します。
- ログイン後にサービス用 Host へアクセスし、本来の転送先が表示され、リダイレクトループが起きないことを確認します。
リクエストログを開き、クライアント IPが利用者のアドレスであることを確認します。接続元 IPは EdgeOne ノードのアドレスでも問題ありません。また、EO-Connecting-IPが記録されていることも確認します。- Host、認証結果、アップストリームの Target、レスポンスステータスが現在のリクエストと一致することを確認します。
- WebSocket、ファイルのアップロードとダウンロード、ログアウトをテストします。ログアウト後、ログインが必要な Host へ再度アクセスしてください。
- EdgeOne を経由しないアドレスからオリジンへの直接接続を試し、ネットワーク層で拒否されることを確認します。
ログインループ、ページリソースの異常、送信元地域の誤判定が起きる場合は、キャッシュ、Cookie ドメイン、オリジン接続時の Host、外部側のプロトコル、実 IP ヘッダーの順に確認します。リクエストが fn-knock のログにまったく記録されない場合は、DNS、EdgeOne のオリジン接続、またはオリジン側のネットワーク層に問題があります。ログに記録されていて 502 が返る場合は、fn-knock からサービスの Target までの経路を確認してください。
切り戻し
変更前に、元の DNS、オリジンアドレス、ポート、プロトコル、キャッシュルールを記録します。切り戻す場合は、先に元の DNS を復元するか高速化ドメインを無効にし、その後 fn-knock の実クライアント IP プロバイダーを実際の入口に合う選択肢へ戻します。DNS の変更が完全に反映されるまでは両方の経路にリクエストが届く可能性があるため、片方から古い認証コンテンツを返さないようにしてください。
EdgeOne の管理画面、プラン、オリジン接続の選択肢は変更されることがあります。エッジ側の操作については、EdgeOne 公式ドキュメントを参照してください。