グローバル IP とサブドメインでサービスを公開

外部から到達可能なグローバル IPv4 または IPv6 と独自ドメインがあり、Web サービスごとに個別のサブドメインを使いたい環境向けの構成です。最終的なアクセス先は、たとえば次のようになります。

auth.example.com     ログイン用の入口
nas.example.com      fnOS または NAS サービス
files.example.com    ファイルサービス

この構成で使うのは サブドメインモード（グローバル IP から直接接続 + Host ルーティング）であり、「リバースプロキシモード / サブドメインマッピング」ではありません。公開入口がない場合は、グローバル IP なしでトンネル経由のサブドメインを公開を参照してください。

前提条件

• fn-knock のゲートウェイポートへインターネットから到達できる。この構成は、fnOS FPK、Docker、OpenWrt、Linux、Synology DSM 7 SPK、Windows で利用できます。Docker ではゲートウェイポートを公開してください。Synology と Windows では、DSM / Windows ファイアウォール、ルーター、または前段のプロキシから公開トラフィックがゲートウェイへ届くことも確認します。
• ルーター、クラウドのセキュリティグループ、ホストから、サービス本来のポートが個別にインターネットへ公開されていない。
• DNS を変更できる example.com のようなドメインを用意している。
• TOTP、またはユーザー名とパスワードの復旧に使える端末が少なくとも 1 台ある。
• モバイル回線など、実際の外部ネットワークから検証できる。

設定手順

1. システム設定 → モード で サブドメインモード を選び、保存します。
2. サブドメインマッピング を開き、ルートドメインと認証サービスが使用する実際の公開ポートを入力します。たとえばルートドメインが example.com、認証用 Host が auth.example.com で、公開側の 443 を内部ゲートウェイの 7999 へ転送する場合は、公開ポートに 443 を指定します。
3. 認証サービスのマッピングを作成します。認証サービスは常に外部から到達できる状態にし、認証サービス自身では「ログインを必須にする」、従来の厳格な許可リスト、アップストリームへの Basic 認証情報の自動入力を有効にしないでください。
4. files.example.com など、最初のサービス用 Host を作成します。転送先にはサービスの LAN 内 HTTP アドレスを指定し、「ログインを必須にする」を有効にします。
5. DNS で認証用 Host とサービス用 Host を同じ公開入口へ向けます。サービスが多い場合はワイルドカードレコードも利用できます。同時に、ルーターがゲートウェイポートを fn-knock へ転送していることを確認してください。
6. TLS 証明書 で、認証用 Host とサービス用 Host をカバーする証明書を設定します。
7. グローバル IP が変わる場合は DDNS を設定します。固定アドレスなら不要です。

DNS とポートの例

auth.example.com  A/AAAA -> 公開入口
files.example.com A/AAAA -> 公開入口
公開側 443/TCP -> fn-knock 7999/TCP

この場合、ブラウザーからは https://files.example.com にアクセスし、ルートドメイン設定の認証サービス用ポートには 443 を指定します。外部から https://files.example.com:8443 を使う場合は、公開側の 8443 を実際のゲートウェイポートへ転送し、関連する公開ポート設定にも 8443 を入力してください。

A と AAAA を同時に公開する前に、IPv4 と IPv6 のどちらからもゲートウェイへ到達できることを個別に確認します。AAAA が到達不能なアドレスを指していると、IPv6 対応クライアントが失敗する経路を優先することがあります。安定した IPv6 の着信経路がない場合は、A レコードだけを公開してください。

サービス用マッピングの項目

項目	推奨設定
Host	完全なドメインを入力するか、画面上でルートドメインと組み合わせます。パスは指定できません
Target	fn-knock の実行環境から到達できる http:// または https:// アドレスを指定します
ログインを必須にする	非公開サービスでは有効、認証サービスでは必ず無効にします
Host ヘッダー	デフォルトでは訪問先の Host を維持します。アップストリームが自身の Host だけを受け付ける場合に無効にします
Basic 認証を自動入力	アップストリーム自身の Basic 認証情報を送る用途だけに使います。fn-knock へのログインの代わりにはなりません
WAF	アプリの互換性に合わせ、Host ごとに有効化またはスキップします

Docker 内の 127.0.0.1 はコンテナ自身だけを指します。ホストや別のコンテナ上のサービスには、コンテナから到達できるアドレスを指定してください。複数の Host が同じ Target を共有すると、Host ヘッダーの設定も共有されます。異なるポリシーが必要なら、別々の Target を使ってください。

検証

自宅の Wi-Fi を切り、モバイル回線から次の順にテストします。

1. 認証用 Host を開き、ログインします。
2. サービス用 Host を開き、正しいアップストリームへ進むことを確認します。
3. リクエストログで Host、クライアント IP、認証結果、アップストリームの転送先を確認します。
4. サービス本来の公開ポートへアクセスし、ゲートウェイを迂回できないことを確認します。

LAN 内でログインなしにアクセスできても、公開側のルールが正常とは限りません。fn-knock はプライベートネットワークやローカルの送信元をローカル例外として扱います。

さらに、次の異常系もテストしてください。

• 未設定の Host へアクセスすると、別のサービスではなくゲートウェイのデフォルト応答が返る。
• サービススコープに含まれない認証情報で制限対象の Host へアクセスすると拒否される。
• ログアウト後にサービス用 Host を開き直すと、現在の送信元に有効な IP 許可が残っていない限り、再び認証フローへ進む。
• WebSocket、アップロード、ダウンロード、アプリのコールバックが正常に動作する。

切り戻し

一括移行する前に、まずサービス用 Host を 1 つだけ接続してください。切り戻す場合は、以前の DNS とポートフォワーディングを復元してから、新しいマッピングを削除または無効化します。証明書と DDNS タスクは、他の Host が使っていないことを確認してから整理してください。唯一の認証用 Host を先に削除すると、ログインが必要なすべてのサービス用 Host で正規の入口が失われます。

よくある問題

症状	確認する項目
認証用 Host を開けない	DNS、ゲートウェイポート、ルーターの転送、証明書、認証サービスのマッピング
ログイン後もサービス用 Host で拒否される	マッピングのアクセスポリシー、認証情報のサービススコープ、Cookie ドメイン、実クライアント IP
別のアプリが開く	Host 名、DNS レコード、アップストリームの転送先
証明書エラーが表示される	証明書がその Host をカバーしていない、または CDN / オリジン接続で誤った TLS 名を使っている

• サブドメインマッピング
• TLS 証明書と HTTPS
• DDNS 管理