NAT 越え：サブドメインルーティング
外部から着信可能なグローバル IP がない、ポートフォワーディングを設定できない、または FRP / Cloudflared をインターネット側の入口にしたい環境向けの構成です。外部トラフィックをトンネル経由で fn-knock ゲートウェイへ届け、アクセス先ドメインに応じて各サービスへ転送します。
- ネットワーク構成：NAT 越え / トンネル
- ルーティング方式：
Hostでサービスを振り分け - 推奨ポリシー：ログイン優先
- 管理画面の場所：
システム設定 → モード → リバースプロキシモード → サブドメインマッピング
NAT 越えでは、サブドメインマッピングを基本構成とします。パスモード は、旧構成との互換性を保つ場合や、パスプレフィックス配下での公開が必須のアプリに限って使用します。
作業を始める前に
次のものを用意します。
- DNS を管理できるドメイン（例：
example.com）。 - FRP サーバー、または利用可能な Cloudflare Tunnel。
- 少なくとも 1 つの有効なログイン方法。
- fn-knock を実行する機器から、公開対象のサービスへ接続できるネットワーク経路。
fnOS FPK、Docker、OpenWrt、Linux、Synology DSM 7 SPK では、アプリ内でトンネルを利用できます。Windows x86_64 には FRP / Cloudflared が内蔵されていません。同じ Windows ホストでトンネルクライアントを別途動かす場合は、ローカルの 127.0.0.1:7999 をオリジンにすることを推奨します。ただし、そのトンネルの導入と運用は fn-knock の管理対象外です。Docker コンテナ内の 127.0.0.1 はコンテナ自身を指します。上流サービスがホスト上または LAN 内の別機器にある場合は、コンテナから到達できるアドレスを指定してください。
リクエストの経路
外部リクエストは次の順序で流れます。
auth.example.comまたはnas.example.comのインターネット側エンドポイント。- FRP または Cloudflared トンネル。
- fn-knock の実際のゲートウェイポート。fnOS ネイティブ FPK、Docker Compose、OpenWrt、Linux、Synology DSM 7 SPK、Windows のデフォルトは
7999です。Windows でトンネルを別途管理する場合は、同じホストのループバックアドレスをオリジンとして優先します。 - 認証サービス、または該当する上流サービス。
トンネルは元の Host ヘッダーを fn-knock へ渡す必要があります。すべてのドメインを同じローカルゲートウェイへ向け、その後の振り分けを fn-knock が行います。
1. リバースプロキシモードとサブドメインマッピングを選ぶ
システム設定 → モード を開きます。
リバースプロキシモードを選びます。- ルーティング方式に
サブドメインマッピングを選びます。 - 設定を保存します。
保存後、サイドバーに サブドメインマッピング とトンネル関連のメニューが表示されます。
他のモードから切り替える場合は、既存のルート、証明書、認証 URL を確認してください。パスモードのマッピングを、そのままサブドメインマッピングとして使うことはできません。
2. ルートドメインと認証サービスを設定する
サブドメインマッピング を開き、サブドメインモード の設定を展開します。ドメイン に example.com を入力して保存してください。認証サービスの公開 HTTPS ポート には、利用者が実際にアクセスする外部ポートを入力します。その後、認証サービスを追加 をクリックし、auth.example.com を追加します。
認証サービスは、次の条件を満たす必要があります。
- 未ログインでも公開アクセスできる。
- 旧マッピングに厳格な許可リストルールが残っている場合、そのまま認証サービスには使えません。元の設定を控えたうえで、認証サービスを作り直してください。
- 現在使用する唯一の認証入口である。
- トンネル経由でローカルの fn-knock ゲートウェイへ到達できる。
認証 URL を外部ネットワークから開けることを先に確認してから、サービス用マッピングを設定します。
3. サービス用マッピングを追加する
サブドメインマッピング を開き、サービスを追加します。例：
| 設定項目 | 例 |
|---|---|
| サブドメイン | nas |
| 転送先 | http://192.168.1.20:5666 |
| ログインを必須にする | オン |
保存後、外部からは https://nas.example.com でアクセスできます。
上流サービスで HTTP Basic 認証が必要な場合は、マッピングの詳細設定で Basic 認証を自動入力 を有効にし、上流用の認証情報を入力します。この認証情報は fn-knock から上流へ接続するためのもので、利用者の fn-knock ログインを置き換えるものではありません。
4. アクセスポリシーを設定する
Host マッピングの編集画面には、ログインを必須にする スイッチがあります。
| 設定 | 動作 |
|---|---|
ログインを必須にする をオフ（現在のログイン優先マッピング） | 公開アクセスになります。fn-knock のログイン状態や許可リストを確認しません |
ログインを必須にする をオン | 有効な送信元 IP 許可がなければ、セッションと認証情報のサービススコープで続けて判定します |
| 旧バージョンの厳格な許可リストルール | ログインを必須にする をオフにしても公開されるとは限りません。有効な送信元 IP 許可レコード（手動、またはログイン後に自動作成）だけで判定し、セッション Cookie だけでは送信元条件を満たせません |
ほとんどのトンネル構成では ログインを必須にする をオンにします。現在の画面では厳格な許可リストを新たに選べません。旧ルールを解除するには、現在の画面からマッピングを作り直す必要があり、ログインを必須にする をオフにするだけでは公開されません。Cloudflare、FRP、その他のプロキシノードの送信元 IP を利用者の固定 IP として許可リストへ追加しないでください。すべてのリクエストが同じ送信元と見なされるおそれがあります。
5. トンネルを設定する
まず システム設定 で FRP または Cloudflared のリソースを用意し、続いてトンネル画面でトンネルを作成して起動します。
Cloudflared を使う
Cloudflare Zero Trust で、入口ごとに Public Hostname を設定します。
| 公開ドメイン | ローカルサービス |
|---|---|
auth.example.com | http://127.0.0.1:<実際のゲートウェイポート> |
nas.example.com | http://127.0.0.1:<実際のゲートウェイポート> |
fn-knock が管理する Cloudflared とゲートウェイが同じ実行環境にある場合は、127.0.0.1 と実際のゲートウェイポートを指定します。Cloudflared を別コンテナで動かし、fn-knock と同じ Docker ネットワークに接続している場合に限り、fn-knock のコンテナサービス名とポートを使用できます。ネットワークが異なる場合は、Cloudflared コンテナから到達可能なアドレスを指定してください。
インターネット側の TLS は Cloudflare で終端できます。ローカルオリジンへの接続に HTTPS を使う場合は、証明書がオリジンアドレスをカバーし、Cloudflared から信頼されていなければなりません。それ以外の場合は、管理された内部ネットワーク内で HTTP オリジン接続を使用します。
FRP を使う
FRP サーバーでは、外部の HTTP / HTTPS トラフィックを fn-knock の実際のゲートウェイポートへ転送し、元の Host ヘッダーを保持します。認証用ドメインとサービス用ドメインは、同じゲートウェイ入口を共有できます。
外部ポート、証明書、DNS は、FRP サーバー側の構成に合わせて設定します。fn-knock の管理入口を、FRP のサービス用オリジンとして公開しないでください。
6. HTTPS と公開認証 URL を確認する
エッジプラットフォームで TLS を終端する場合、ブラウザーから見える公開 URL は HTTPS にし、fn-knock の認証リダイレクト URL も一致させる必要があります。公開 URL とローカルオリジンへの接続プロトコルが異なる場合でも、利用者に見える認証 URL へローカルの HTTP アドレスを設定してはいけません。
FRP で HTTPS を直接提供する場合は、FRP サーバーまたは fn-knock ゲートウェイに、すべてのサブドメインをカバーする証明書を設定します。証明書については TLS 証明書と HTTPSを参照してください。
7. 外部ネットワークから検証する
スマートフォンのモバイル回線を使い、次の順序でテストします。
auth.example.comを開き、ログインページへ到達できることを確認します。nas.example.comを開き、認証フローへ進むことを確認します。- ログイン後、サービスの画面へ戻ることを確認します。
- トンネルの状態と fn-knock の
リクエストログを確認し、正しい Host と上流サービスに一致していることを確かめます。
パスモードは互換目的に限る
リバースプロキシモード → パスモード は、現在の画面で非推奨と表示されます。使用するのは次の場合だけです。
- 既存のパスマッピングを残す必要があり、すぐには移行できない。
- 外部公開に使えるドメインが 1 つしかない。
- 上流アプリがパスプレフィックス配下での公開を明示的にサポートしている。
たとえば、https://example.com/nas/ を NAS へ転送する構成です。上流アプリがパスプレフィックス、リダイレクト、Cookie、WebSocket を正しく処理できなければ、静的ファイルの 404、ログインループ、ルートパスへの意図しないリダイレクトが発生しやすくなります。
新しい構成では、サービスごとに専用サブドメインを割り当ててください。旧構成からの移行方法は、NAT 越えとパスマッピングを参照してください。
よくあるトラブル
| 症状 | 最初に確認する項目 |
|---|---|
| トンネルはオンラインだがドメインがタイムアウトする | Public Hostname、FRP の入口、DNS、トンネルの転送先ポート |
| どのサブドメインも同じサービスへ入る | トンネルまたは前段プロキシが Host ヘッダーを保持しているか |
| 502 が返る | トンネルからゲートウェイへ接続できるか、ゲートウェイから上流サービスへ接続できるか |
| ログイン後にリダイレクトがループする | 公開側のプロトコル、認証ドメイン、ルートドメイン、Cookie のスコープ、前段プロキシの Host / X-Forwarded-* が一致しているか。元のサービス用 Host からアクセスし直します |
| Cloudflared で TLS エラーが出る | オリジン接続のプロトコルまたは証明書の信頼設定 |
| パスモードで静的ファイルが 404 になる | 上流がパスプレフィックスに対応していません。サブドメインマッピングへの移行を優先します |
トラブルシューティング全体は FAQを参照してください。