グローバル IP なしでトンネル経由のサブドメインを公開
グローバル IP がなくても、サブドメインマッピングを利用できます。FRP または Cloudflared で外部リクエストを fn-knock のゲートウェイ入口へ届け、ゲートウェイから Host に応じて LAN 内のサービスへ振り分ける構成です。
既存環境では引き続きパスマッピングを利用できますが、新規構築では「リバースプロキシモード / サブドメインマッピング」を優先してください。
前提条件
- fn-knock をデプロイ済みで、ローカルからゲートウェイポートを利用できる。
- FRP サーバーまたは Cloudflare Zero Trust アカウントを用意している。
- 管理できるドメイン、または Tunnel が提供する公開 Host がある。
- ログイン用の認証情報と、実際の外部ネットワークから検証できる環境を用意している。
設定手順
システム設定 → モードでリバースプロキシモードを選び、サブモードにサブドメインマッピングを指定します。サブドメインマッピングでルートドメイン、認証用 Host、最初のサービス用 Host を設定します。サービス用 Host の Target には、fn-knock の実行環境から到達できる LAN 内サービスのアドレスを入力し、デフォルトで「ログインを必須にする」を有効にします。認証用 Host は公開しておく必要があります。トンネルで FRP または Cloudflared をインストールして設定し、外部トラフィックを fn-knock の実際のゲートウェイポートへ転送します。- トンネル事業者側で認証用 Host とサービス用 Host の DNS / Public Hostname を設定し、Host、WebSocket、実クライアント IP が正しく引き継がれるようにします。
- 外部向け HTTPS を設定します。Tunnel または前段のリバースプロキシで TLS を終端する場合は、オリジン接続のプロトコルと証明書の検証方法を明確にしてください。内部の
localhostアドレスをブラウザーのアクセス先にしないでください。 - モバイル回線から認証用 Host を開いてログインし、その後サービス用 Host へアクセスします。
FRP と Cloudflared の違い
| 項目 | FRP | Cloudflared |
|---|---|---|
| 公開入口 | 自前の frps または事業者のノード | Cloudflare エッジと Tunnel |
| DNS | 通常は FRP サーバーを参照 | 通常は Public Hostname の作成時に DNS を作成または関連付け |
| 実際の送信元 IP | HTTP ヘッダー、または正しく設定した PROXY Protocol | Cloudflare のリクエストヘッダー。入口に合わせた設定が必要 |
| fn-knock での管理 | 複数の frpc インスタンス、設定、ログを管理 | リソース、Tunnel token、プロセス、ログを管理 |
FRP が TCP 転送だけを行う場合、fn-knock から見える接続元がトンネルノードやローカルの中継アドレスになることがあります。FRP の経路に合わせて PROXY Protocol または信頼できる実 IP ヘッダーを設定し、リクエストログで結果を確認してください。ページが開けるというだけで、許可リスト、地域判定、スキャンルールに正しいクライアントアドレスが使われているとは限りません。
Cloudflared の Public Hostname のオリジンには、http://127.0.0.1:7999 のようなゲートウェイ入口を指定します。サービスへ直接接続すると、fn-knock の Host ルーティングと認証を迂回してしまいます。
Target アドレス
- fn-knock とサービスを同じホスト上でネイティブ実行している場合は、サービスが実際に待ち受けている
127.0.0.1:<ポート>を指定できます。 - Docker 内の
127.0.0.1は fn-knock コンテナ自身を指します。ホスト上のサービスにはコンテナから到達できるアドレスを指定し、別のコンテナには共有ネットワーク上の名前で接続してください。 - サービスが別の LAN 機器にある場合は、固定されたプライベート IP または内部 DNS 名を指定します。
- Target に HTTPS を使う場合は、証明書の名前と信頼チェーンを確認します。LAN 内の証明書に問題があると、ゲートウェイでは
502として現れます。
DDNS が不要な理由
トンネル構成では、公開ドメインは通常、家庭回線のアドレスではなく FRP サーバーや Cloudflare のエッジネットワークを参照します。この状態で同じ Host に家庭回線向けの DDNS を設定すると、名前解決が競合します。DNS が最終的に、アドレスの変わる自前の公開入口を参照する必要がある場合に限り、DDNS を設定してください。
経路の検証
次の順に確認します。
- fn-knock にトンネルリソースがインストールされ、インスタンスまたは Tunnel が実行中であり、ログに再接続が繰り返し記録されていない。
- 公開 DNS が正しい入口を参照している。
- 認証用 Host を開いてログインできる。
- リクエストログに正しい Host と実クライアント IP が表示される。
- サービス用 Host が正しいアップストリームに一致する。
DNS を解決できてもリクエストログに記録がなければ、トンネルまたは前段のプラットフォームに問題があります。ログにリクエストが記録されていて転送に失敗する場合は、マッピングとアップストリームサービスを確認してください。
続いて WebSocket、アップロード、ダウンロード、ログアウト、認証情報のサービススコープをテストします。LAN 内からのリクエストは local_exempt と判定されることがあるため、最終的な動作は実際の外部ネットワークで確認してください。
切り戻しと移行
トンネルを切り替える前に fn-knock の設定をエクスポートし、旧 DNS、frpc 設定、または Tunnel Public Hostname を記録します。切り戻す場合は、先に以前の入口を復元してから新しいトンネルを停止してください。同じ Host に対して、実 IP や TLS の扱いが異なる 2 つの入口を長期間併用しないでください。
パスモードからサブドメインマッピングへ移行する場合は、先に新しいサービス用 Host を並行して作成し、検証を済ませてから旧パスを削除します。アップストリームアプリに絶対 URL のコールバック先が保存されている場合は、アプリ側の設定も更新してください。