ポート・エンドポイント・URL パス
fn-knock には、利用者が触れる入口が 2 つあります。設定を変更するための管理入口と、サービストラフィックを受けるゲートウェイ入口です。fnOS ネイティブ FPK はデスクトップアイコンから管理画面を開きます。Docker、OpenWrt、Linux の管理パネルはデフォルトで 7991 を使用します。Synology DSM 7 SPK は DSM デスクトップのパッケージアイコンからのみ開けます。Windows では fn-knock Windows 管理アプリ がシステムブラウザーでローカルの 127.0.0.1:7991 を開くため、LAN やインターネット向けの管理入口としては使えません。ゲートウェイには通常 7999 を使用します。
7998、7997、7996 はコンポーネント間通信用の内部ポートです。インターネットへ直接公開しないでください。
デフォルトポート
| ポート | 役割 | デフォルトの用途 |
|---|---|---|
7991 | 管理パネル | Docker、OpenWrt、Linux のデフォルト管理入口。Windows ではローカルループバックからのみアクセス可能 |
7998 | 管理バックエンド | fnOS ネイティブ FPK のデスクトップ CGI がここへプロキシします。Docker でも内部的に使用 |
7997 | 認証サービス | ログイン、ログアウト、パスキー、ボット対策を処理 |
7996 | ゲートウェイ管理ポート | 管理バックエンドと Go ゲートウェイ間の内部通信 |
7999 | ゲートウェイ入口 | Web サービスのトラフィックを受け、認証とルーティングを実行 |
ポートはインストール時に変更できます。トラブルシューティングでは、実際のデプロイ設定と管理画面に表示されるアクセス先を基準にし、すべての環境がデフォルト値を使っているとは考えないでください。
デプロイ方式ごとの外部向けポート
| デプロイ方式 | 管理入口 | ゲートウェイ入口 | 説明 |
|---|---|---|---|
| fnOS ネイティブ FPK | fnOS のデスクトップアイコン | 7999 | デスクトップ CGI からローカルの 7998 へプロキシします。7991 は FPK の管理入口ではありません |
| Docker Compose | 7991 | 7999 | デフォルトではこの 2 ポートだけを公開します |
| OpenWrt | 7991 | 7999 | 内部の管理バックエンドはデフォルトで 17998 を使用します |
| Linux（systemd / OpenRC） | 7991 | 7999 | インストール時または sudo knock config で変更できます。7998、7997、7996 はローカルホストだけで待ち受けます |
| Synology DSM 7 SPK | DSM デスクトップのパッケージアイコン | 7999 | 7991 は公開しません。DSM CGI が内部の管理サービスへプロキシし、7998、7997、7996 はローカルホストだけで待ち受けます |
| Windows x86_64 | 管理アプリから 127.0.0.1:7991 を開く | 7999。デフォルトで 0.0.0.0 と :: を待ち受け | 管理画面はローカルからしか開けません。インストーラーが追加する静的なプログラムルールは、「ドメイン / プライベート」ネットワークプロファイルだけが対象です |
Docker のコンテナ側ポートとホスト側の公開ポートは、デプロイファイルの設定によって決まります。設定全体は Docker へのデプロイを参照してください。
リクエストがゲートウェイへ入った後の処理
ゲートウェイ入口が決めるのは、「トラフィックがどこから入るか」だけです。その後、ルーティングとアクセスポリシーを順に判定します。
- ネットワーク構成：インターネットまたは LAN からゲートウェイへ直接到達するか、FRP や Cloudflared などのトンネルからゲートウェイへ転送します。
- ルーティング：Web サービスは
nas.example.comのように、リクエストのHostで振り分ける構成を優先します。パスマッピングは、/alistのような従来の入口に依存するサービスとの互換目的に限ります。 - アクセスポリシー：現在の Host 編集画面では、
ログインを必須にするのオン・オフで公開アクセスとログイン優先を切り替えます。旧バージョンから残る厳格な許可リストルールは、引き続き送信元 IP で判定します。
TCP / UDP のプロトコルマッピングは、それぞれ専用の外部ポートで待ち受けるため、7999 の HTTP Host ルーティングを通りません。直接接続モードではゲートウェイをログイン入口として使い、ログイン後に送信元 IP に応じてサービス本来のポートを開放します。
local_exempt：LAN 内のテストだけでは外部公開時の保護を確認できない
認証サービスは、ゲートウェイがループバック、プライベートアドレス、リンクローカルなどと判定した送信元を local_exempt に分類します。この種のリクエストはローカルネットワークからのアクセスと見なされ、通常のログインや許可リストの確認を省略します。厳格な許可リストでも、インターネット側の送信元としてはブロックしません。
このため、次の点に注意してください。
- 同じ LAN からサービスを開いても、外部公開時のログインポリシーが機能するかは検証できません。
- リバースプロキシやトンネル経由の場合は、ゲートウェイがプロキシノードのプライベート IP ではなく、実際のクライアントのグローバル IP を認識していることをリクエストログで確認します。
- 外部公開の検証には、モバイル回線など実際の外部ネットワークを使用します。
local_exempt は送信元ネットワークに対する例外であり、ブラウザーのログインセッションではありません。ログアウトしても、そのネットワークがローカル例外として扱われることは変わりません。
プラットフォームごとの機能範囲
- Docker は Host / パスベースのゲートウェイを実行できますが、ホストのファイアウォールルールは変更しません。直接接続モードとスマート接続にも対応していません。
- fnOS ネイティブ FPK はホストのファイアウォールを管理でき、直接接続モードとスマート接続も利用できます。
- OpenWrt は root 権限でホストのファイアウォールと直接接続モードを利用でき、スマート接続にも対応します。スマート接続には、インストール済みの
dnsmasqと、メイン設定から/etc/dnsmasq.d/を読み込む構成が必要です。画面上のapt-getインストールは OpenWrt では使えません。SSH セキュリティ、Web ターミナル、アプリ内 FPK 更新には対応していません。 - Synology DSM 7 SPK の
7999は公開ゲートウェイポートとして DSM のファイアウォール画面へ登録されますが、パッケージ自体からホストのファイアウォールを変更することはできません。直接接続モード、スマート接続、Web ターミナル、SSH セキュリティには対応していません。 - Windows の
7999はデフォルトで全インターフェースを待ち受けます。インストーラーが作成するFnKnock Gatewayの静的なプログラムルールは、「ドメイン / プライベート」ネットワークプロファイルだけに適用されます。直接接続モード、アプリ内からのホストファイアウォール管理、スマート接続、内蔵トンネル、Web ターミナル、SSH セキュリティには対応していません。外部公開前に、ルーター / NAT、IPv6、ISP、サードパーティ製セキュリティソフトも確認してください。
Host またはパスルーティングで fn-knock が保護できるのは、実際にゲートウェイを通るリクエストだけです。上流サービスがインターネットや LAN から到達可能なアドレスでも待ち受けていれば、利用者はゲートウェイを迂回して直接接続できます。直接接続の IP 許可だけは例外で、対応するホストファイアウォールを使い、ログイン後の送信元 IP が許可された間だけ元のポートを開放します。別途、広すぎるインターネット向け許可ルールを追加しないでください。
通信経路に沿って切り分ける
fnOS ネイティブ FPK の管理画面を開けない場合は、まずデスクトップアイコン、アプリプロセス、7998 のバックエンドを確認します。Docker または OpenWrt では、7991、バインドアドレス、公開ポートを確認します。サービス用ドメインを開けない場合は、次の順序で切り分けてください。
- 外部トラフィックが実際のゲートウェイポート（デフォルトは
7999）へ到達しているか。 - リクエストの
Hostまたは互換用パスがマッピングに一致しているか。 fn-knockの実行環境からマッピング先へ接続できるか。- リクエストログのクライアント IP、許可の種類、上流の転送先が想定どおりか。
パス互換ルールはパスベースのリバースプロキシ、構成全体の選び方は動作モードを参照してください。