デプロイ方法とアクセス構成を選ぶ
fn-knock を導入するときは、まず「どこで動かすか」「外部からのトラフィックをどうゲートウェイまで届けるか」「ゲートウェイから各サービスへどう振り分けるか」の 3 点を順に決めます。最後に、どのリクエストを通すかをアクセスポリシーで定めます。
fn-knock は公開口の集約と前段認証を担うものです。OS やアプリの更新、バックアップ、最小権限の原則、上流サービス側のセキュリティ設定を置き換えるものではありません。
デプロイ方法を選ぶ
| デプロイ方法 | 管理画面 | デフォルトのゲートウェイ入口 | 向いている環境 | 主な制約 |
|---|---|---|---|---|
| fnOS ネイティブ FPK | fnOS デスクトップの fn-knock アイコン（ローカル CGI からバックエンドの 7998 へ転送） | 7999 | fnOS ホストで、ホスト OS 連携をすべて利用したい場合 | 7998 は管理バックエンド用であり、外部公開用でもブラウザーから開く管理画面でもありません |
| Docker Compose | 7991 | 7999 | NAS、ホームサーバー、一般的な Docker ホスト | ダイレクトモード、ホストのファイアウォール管理、自動 HTTPS、SSH セキュリティ、スマート接続、Web ターミナルは利用できません |
| OpenWrt パッケージ | サービス → fn-knock。デフォルトポートは 7991 | 7999 | メインルーター、x86 ソフトウェアルーター、サブルーター | 自動 HTTPS、SSH セキュリティ、Web ターミナル、アプリ内 FPK 更新は利用できません。スマート接続は既存の dnsmasq 設定に依存します |
| Linux（systemd / OpenRC） | 7991 | 7999 | 一般的な Linux サーバー、VPS、自前で管理するホスト | root 権限と、稼働中の systemd または OpenRC が必要です。ホストのファイアウォールは管理者が別途管理します |
| Synology DSM 7 x86_64 / ARM SPK | DSM デスクトップのパッケージアイコン | 7999 | DSM 7 を搭載した Intel / AMD / ARM NAS | ダイレクトモード、ホストのファイアウォール管理、スマート接続、Web ターミナル、SSH セキュリティは利用できません。更新はパッケージセンターから行います |
| Windows x86_64 | 管理アプリからローカルの 127.0.0.1:7991 を開く | 7999。デフォルトでは全インターフェースで待ち受け | Windows サービスとローカルのタスクトレイ管理アプリを使いたい場合 | ファイアウォールと NAT は別途設定が必要です。ダイレクトアクセス許可、内蔵 FRP / Cloudflared、スマート接続、Web ターミナル、SSH セキュリティは利用できません |
Docker、OpenWrt、Linux、Windows の管理画面には、専用のパネルパスワードを設定します。このパスワードは管理画面を保護するためのもので、ゲートウェイ入口で使う TOTP、ユーザー名とパスワード、パスキーとは別の認証情報です。
fnOS 機器のアプリ名が Knock Lite の場合、それは Docker デプロイではなくネイティブの非 root 簡易パッケージで、表にある標準 FPK の完全なホスト権限を持ちません。Lite は Host プロキシ、認証、DDNS、証明書、WAF、組み込み FRP / Cloudflared、監視に対応します。ダイレクトモードとホストのファイアウォール、スマート接続、システム時刻同期、自動 HTTPS、fnOS 証明書ストア同期、Web ターミナル、FN Connect WAF 接続、アプリ内更新には対応しません。ここでいう「自動 HTTPS」は、ISP と受信経路が TCP 80 / 443 を許可している場合の標準ポート直結支援機能です。Lite が証明書や HTTPS を利用できないという意味ではありません。完全な境界と移行方法は、アプリストア Lite と標準 FPK の違いを参照してください。
インストール手順：
- fnOS ネイティブ FPK：インストールと初回アクセス
- Docker：Docker へのデプロイ
- OpenWrt：OpenWrt へのデプロイ
- Linux：Linux へのデプロイ（systemd / OpenRC）
- Synology：Synology DSM 7 へのデプロイ
- Windows：Windows x86_64 へのデプロイ
パッケージの入手元と検証
まず fn-knock 公式サイト から、対象プラットフォームのダウンロードページへ進んでください。正式リリースでは、次の検証情報も公開されます。
release-manifest.json：バージョン、プロジェクト本体と Go ゲートウェイのコミット、プラットフォーム、アーキテクチャ、ファイルサイズ、SHA-256 を記録しています。SHA256SUMS：GitHub Release にあるパッケージのチェックサムです。- Docker マルチアーキテクチャイメージの SBOM とビルド来歴（provenance）。
オフラインで受け取った場合や別の場所へコピーした場合は、インストール前に SHA-256 を再計算し、正式なリリースマニフェストと照合してください。チェックサムで確認できるのは「マニフェストに記載されたファイルと同一であること」だけです。プラットフォームと CPU アーキテクチャが正しいことも別途確認します。
次の順序で検証することを推奨します。
公式サイトから対応する GitHub Release へ移動します。チャットグループ、オンラインストレージ、検索結果にある同名ファイルは使用しません。
release-manifest.jsonで完全に同じファイル名を探し、リリースバージョン、プラットフォーム、アーキテクチャ、ファイルサイズを確認します。ローカルファイルの SHA-256 を計算します。
bash# Linux、OpenWrt、または sha256sum を利用できるその他のシステム sha256sum <パッケージファイル名> # macOS shasum -a 256 <パッケージファイル名>Windows PowerShell では次のコマンドを使います。
powershell(Get-FileHash -LiteralPath '<パッケージファイル名>' -Algorithm SHA256).Hash結果を、manifest の当該ファイルにある
sha256、またはSHA256SUMSの同名エントリーと一文字ずつ照合します。一致しない場合はインストールを中止し、改めてダウンロードしてください。ビルド元まで監査する場合は、パッケージの GitHub build provenance が公式リポジトリを指していることも確認します。Docker では、manifest にあるマルチアーキテクチャイメージの digest、SBOM、provenance も併せて確認できます。バージョンを固定して運用する場合は、digest を指定すると
latestの更新による差し替わりを避けられます。
release-manifest.json には、コントロールプレーンと Go ゲートウェイそれぞれのソースコミットも記録されており、パッケージを両方のソースまで追跡できます。SHA-256 の文字列だけを入手しても、配布者の身元は証明できません。マニフェスト、チェックサムファイル、ビルド来歴そのものが公式 Release から取得したものであることが重要です。
ネットワーク構成を選ぶ
グローバル IP から直接公開する
ドメインを自宅回線のグローバル IPv4 / IPv6 へ直接向けるか、ルーターのポートフォワーディングで外部ポートを fn-knock のゲートウェイ入口へ転送します。
利用できる条件：
- 外部ネットワークから自宅側の入口へ到達できる
- ドメインを用意している
- ルーター、ファイアウォール、ISP のいずれでも必要なポートが遮断されていない
Web サービスには グローバル IP からの直接公開：サブドメインルーティングを使います。SSH などの元ポートへ直接接続する必要がある場合に限り、元のポートへのダイレクトアクセスを選んでください。
FRP または Cloudflared トンネル
外部リクエストをいったん FRP サーバーまたは Cloudflare で受け、トンネル経由で fn-knock のゲートウェイ入口へ戻します。自宅回線に外部から着信可能なグローバル IP は必要ありません。
新しく公開する Web サービスでは、次の構成を基本とします。
- 管理画面のモード：
リバースプロキシモード - ルーティング方式：
サブドメインマッピング
手順全体は NAT 越え：サブドメインルーティングを参照してください。
EdgeOne または ESA を前段に置く
EdgeOne や ESA などのエッジプラットフォームで、インターネット側の標準ポート 80 / 443 を受け、fn-knock へオリジン接続できます。これらは直接公開構成の前段に加わるもので、fn-knock 内部の Host ルーティングやアクセスポリシーは変わりません。
エッジプラットフォームを接続する前に、fn-knock のローカルゲートウェイ、認証用サブドメイン、サービス用サブドメインが正常に動作する状態まで仕上げてください。
ルーティング方式を選ぶ
| ルーティング方式 | 外部 URL の例 | 向いているサービス | 説明 |
|---|---|---|---|
| Host ルーティング | https://nas.example.com | Web サービス | 推奨構成。サービスごとに専用サブドメインを割り当てます |
| パスルーティング | https://example.com/photos | サブパスでの公開に対応済みの Web サービス | 旧構成との互換用です。管理画面の リバースプロキシモード → パスモード にあり、現在は非推奨です |
| TCP / UDP 転送 | example.com:3306 | SSH、データベース、DNS などの非 Web プロトコル | 「プロトコルマッピング」で設定します。現在は管理画面のサブドメインモードでのみ利用できます |
Host ルーティングは、グローバル IP からの直接公開でも FRP / Cloudflared 経由でも利用できます。グローバル IP の有無によってサブドメインを使えるかどうかが決まるわけではありません。
パスルーティングを残すのは、次のような場合だけにしてください。
- 既存のパスマッピングを段階的に移行する必要がある
- 上流アプリがサブパスでの動作を明示的にサポートしている
- 外部公開に使えるホスト名が 1 つに固定されている
アクセスポリシーを選ぶ
現在の管理画面では、Host マッピングにある ログインを必須にする スイッチで新しいサービスの公開範囲を設定します。
| ポリシー | 現在の設定方法 | アクセスが許可される条件 |
|---|---|---|
| 公開アクセス | 現在のログイン優先マッピングで ログインを必須にする をオフ | fn-knock のログイン状態や許可リストを確認しません |
| ログイン必須 | ログインを必須にする をオン | 手動の送信元 IP 許可だけでも通過できます。ログイン後に作成される自動 IP 許可も、通常は同じ送信元からの継続アクセスを許可しますが、認証情報に設定されたサービススコープによる拒否を上書きしません。有効な送信元 IP 許可がない場合にセッションを確認します |
| サブドメインの高度な認証 | ログインを必須にする がオンの HTTP / HTTPS Host に高度な認証ルールを設定 | 送信元やリクエスト特性がルールに一致すると、その Host だけで使える一時認証情報を発行します。一致しない場合は通常のログイン処理へ進みます |
| 厳格な許可リスト | 旧バージョンから引き継いだマッピングにだけ残る可能性があり、現在の画面に選択項目はありません | ログインを必須にする をオフにしても公開されるとは限りません。有効な送信元 IP 許可レコード（手動、またはログイン後に自動作成）のみで判定し、ブラウザーのセッション Cookie だけでは代用できません |
通常、新しいサービス用マッピングでは ログインを必須にする をオンにします。一方、認証サービス自体は公開しておく必要があります。ここを保護すると、未ログインのユーザーがログインページへ到達できません。アップグレード後に旧来の厳格な許可リストルールが残っている場合は、手動と自動の両方の IP 許可レコードを確認してください。このルールを解除するには、マッピング内容を控えたうえで現在の画面から作り直します。ログインを必須にする をオフにするだけでは公開されません。厳格なルールで手動登録した送信元だけを許可したい場合は、ログイン後の自動 IP 許可を無効にし、残っている自動レコードも削除します。
ログイン用の認証情報には、アクセス可能なサブドメインを制限するサービススコープも設定できます。サブドメインの高度な認証は、特定の Host を許可する独立した経路であり、ログイン用認証情報に制限を追加する機能ではありません。設定前にサブドメインの高度な認証を確認してください。上流への Basic Auth 認証情報の挿入は、fn-knock から転送先サービスへ接続するための機能です。訪問者が fn-knock へログインする方法ではありません。
要件に合う手順へ進む
| 条件 | 選ぶ手順 |
|---|---|
| グローバル IP から到達できる入口とドメインがあり、主に Web サービスを使う | グローバル IP からの直接公開：サブドメインルーティング |
| グローバル IP がなく、FRP または Cloudflared を使う | NAT 越え：サブドメインルーティング |
| 既存のパスマッピングがあり、すぐには移行できない | NAT 越えページのパス互換構成 |
Web ログイン後に 5666 や 22 などの元ポートへ接続する必要がある | 元のポートへのダイレクトアクセス |
| まだインストールしていない、または管理画面とゲートウェイ入口の違いが分からない | インストールと初回アクセス |
| Windows x86_64 マシンへ導入して管理する | Windows x86_64 へのデプロイ |
外部向けゲートウェイ入口を持つ構成では、モバイル回線など実際の外部ネットワークから最終確認を行ってください。LAN 内やローカルホストからの通信はゲートウェイに信頼済みと判定されることがあるため、インターネット経由の認証テストの代わりにはなりません。Windows の 7999 はデフォルトで全インターフェースを待ち受けますが、Windows ファイアウォールのプロファイル、ルーターまたは NAT、IPv6 ファイアウォール、ISP の着信制限も併せて確認する必要があります。