NAT 越えとトンネル

デバイスに到達可能な公開エントリーポイントがない場合、FRP または Cloudflared を使って LAN 内からトンネルを確立し、外部リクエストを fn-knock ゲートウェイへ転送できます。トンネルで変わるのはネットワーク構成だけです。リクエストがゲートウェイへ入った後は、引き続き Host または互換用のパスでルーティングされ、アクセスポリシーが適用されます。

システム設定 → モード で リバースプロキシモード を選択します。新しいデプロイでは サブドメインマッピング を選び、既存の単一ドメインによるパス形式のエントリーポイントがある場合にだけ、非推奨と表示された パスモード を選択してください。

macOS と Synology DSM 7 SPK では、FRP と Cloudflared のリソースおよびプロセスをアプリ内で管理できます。Windows x86_64 にはこれらのリソースが含まれないため、このページの システム設定 → FRP と システム設定 → Cloudflared の手順は Windows には適用されません。同じ Windows ホストでトンネルクライアントを独自に実行し、127.0.0.1:7999 をオリジンにすることはできますが、そのプロセスのインストール、認証情報、ライフサイクルは管理者が管理してください。

2 種類のトンネル

方式	外部リソース	適した構成
FRP	frps を実行する公開サーバーとリモートポート	公開アドレス、ポート、トランスポート設定を自分で管理したい
Cloudflared	Cloudflare Account、Zone、API Token	Cloudflare を使用し、Tunnel、ワイルドカード DNS、Ingress を自動管理したい

FRP と手動 Cloudflared のローカル転送先は通常 127.0.0.1:7999 の実ゲートウェイです。管理 Cloudflared は fn-knock が専用ローカル入口を自動設定するため、オリジンポートを手入力する必要はありません。

ルーティング方式の選択

サブドメインマッピング

推奨する経路は次のとおりです。

nas.example.com -> FRP / Cloudflared -> fn-knock -> Host nas.example.com -> FNOS

トンネルは元の Host を維持し、認証 Host とサービス用 Host の両方を同じゲートウェイへ送る必要があります。管理 Cloudflared は *.example.com の Ingress とプロキシ CNAME を自動管理します。FRP の TCP 転送では DNS とリモートポートを frps へ向けます。

パスモード

互換用の経路は次のとおりです。

https://example.com/alist -> トンネル -> fn-knock -> パス /alist -> AList

この方式では以前の URL を維持できますが、アプリケーションによってはプレフィックスの除去、HTML の書き換え、ルートディレクトリモードが必要です。トンネルを使用するという理由だけで、新しいサービスにパスルーティングを選ばないでください。

FRP

先に システム設定 → FRP でリソースをダウンロードし、その後 トンネル → FRP を開きます。デフォルトで生成されるプロキシには、通常、次の内容が含まれます。

type = "tcp"
localIP = "127.0.0.1"
localPort = 7999
transport.proxyProtocolVersion = "v2"

PROXY Protocol v2 は、インターネット側のクライアントアドレスをゲートウェイまで引き継ぐために使用します。frps、転送経路、またはカスタム設定が対応していない場合、ゲートウェイからは FRP ノードのアドレスしか見えず、ホワイトリストとログイン後の IP アクセス許可が正しく機能しなくなる可能性があります。

ページには 2 種類の編集方法があります。

• フォームモード では、サーバーアドレス、ポート、Token、ローカルポート、リモートポートを管理します。対応する項目だけが更新され、その他の有効な TOML は維持されます。
• カスタム では frpc.toml を直接編集します。保存前に frpc verify が実行され、構文エラーがある場合は保存できず、フォームモードへ確実に戻すこともできません。

既存のカスタム設定がある場合は、編集方法を切り替える前に元の内容をバックアップしてください。

システム設定 → FRP では、リソースの状態が「未ダウンロード」「古いバージョン」「ダウンロード済み（準備完了）」に分けて表示されます。古いリソースが検出された場合は先に更新してください。現在のプラットフォームに合うダウンロードパッケージが選ばれ、展開前に固定された公式 SHA-256 ダイジェストで検証されます。リソースの更新時に動作中の古い frpc が自動停止することはなく、トンネルの即時中断を避けます。古いプロセスはそのまま動作を続けられますが、停止済みの古いインスタンスはリソースを更新するまで再起動できません。

新しいリソースのインストール後も、トンネル → FRP では古い実行ファイルを使用中のインスタンスに警告が表示されます。警告が消えるまで各インスタンスを順に停止して再起動し、その後に外部ネットワークからトンネルを検証してください。新しいファイルのインストールと、動作中プロセスの切り替えは別々の手順です。「リソースの準備完了」を、すべてのインスタンスの切り替え完了とみなさないでください。

Cloudflared

リソース更新では、一時ファイルへダウンロードして固定ダイジェストを検証し、実行中の管理対象プロセスを一時停止して実行ファイルとメタデータをバックアップしてから置換・再開します。新しいファイルが起動しない場合は旧ファイルへ戻して再起動を試みます。短時間の Tunnel 中断後、外部アクセスを確認してください。

先に システム設定 → Cloudflared でリソースをダウンロードし、トンネル → Cloudflared で推奨の Cloudflare Account API Token を入力します。専用 Tunnel を選び、プレビューして適用すると、fn-knock が Tunnel の作成または接続、ワイルドカード DNS と Ingress、Tunnel Token 取得、プロセス起動を行います。詳細設定には手動 Tunnel Token モードも残っています。

管理構成、Token 権限、標準 HTTPS URL、最適化 Beta、フォールバックはCloudflared トンネルの設定を参照してください。

アクセスポリシーと実クライアント IP

トンネルは、fn-knock のログイン、ホワイトリスト、認証情報のサービススコープに代わるものではありません。Host の編集ページでは ログインを必須にする を使い、認証なしのアクセスとログイン優先のアクセスを切り替えます。過去の設定にある厳格なホワイトリストルールは、引き続き送信元 IP に基づいて適用されます。パスモードでは、マッピングごとにログインの要否を決定します。

認証の判定には、ゲートウェイが最終的に識別したクライアント IP が使用されます。プライベートネットワーク、ループバック、リンクローカルの送信元は local_exempt として扱われ、通常のログインと厳格なホワイトリストの確認をスキップします。そのため、送信元 IP の受け渡しはトンネルのセキュリティ境界の一部です。

• FRP ではデフォルトの PROXY Protocol v2 を維持することを優先します。
• 管理 Cloudflared は専用ループバック入口でだけ CF-Connecting-IP を信頼します。EdgeOne / ESA 設定を流用したり、訪問者の X-Forwarded-For を信頼したりしないでください。
• 起動後はモバイルネットワークからアクセスし、リクエストログのクライアント IP が 127.0.0.1、コンテナアドレス、トンネルノードのアドレスではなく、訪問者のグローバル IP になっていることを確認します。

プロセス監視と障害診断

fn-knock が管理する FRP / Cloudflared プロセスは、停止、起動中、実行中、再起動待ち の状態を表示します。常時実行する設定のプロセスが予期せず終了すると、約 1、2、5、10、30、60、120、300 秒の段階的な遅延と小さなランダム揺らぎで自動再起動します。約 5 分間安定して実行されると、連続失敗回数はリセットされます。手動停止すると、保留中の再試行も取り消されます。

再起動待ちでは、連続失敗回数、次回再試行時刻、直近の診断が表示されます。ログには PID、起動・終了時刻、実行時間、終了コードまたはシグナル、失敗の概要、最近の stdout/stderr が残り、Token、TLS、ネットワーク、設定、実行ファイルの問題を切り分けられます。ログを共有する前に、Token、ドメイン、グローバル IP、サーバー情報を伏せてください。

fn-knock サービス自体の再起動後は、常時実行として保存されたトンネルを再開し、検証できる場合は実行中のプロセスを引き継ぎます。この監視の対象は fn-knock が起動した組み込み FRP / Cloudflared だけです。Windows やその他の外部プロセスは管理者が引き続き管理します。

プラットフォームごとの制限

• トンネルは外向きの接続なので、fn-knock がホストのファイアウォールへルールを書き込む必要はなく、Docker でも使用できます。
• 実行環境には、アーキテクチャに合う FRP / Cloudflared 実行ファイルが必要です。システム設定 → FRP または システム設定 → Cloudflared の準備状態を基準にしてください。
• Synology DSM 7 SPK はこれらの組み込みリソースをサポートします。管理入口は DSM デスクトップ CGI から利用します。管理 Cloudflared のローカル入口は fn-knock が設定し、FRP と自前 Tunnel は実ゲートウェイポートを使います。
• macOS の Intel / Apple Silicon ネイティブパッケージも組み込みリソースをサポートします。ダウンロードは現在の Darwin アーキテクチャに一致し、管理画面はローカルの 127.0.0.1:7991 だけを待ち受けます。
• Windows では組み込みリソースも準備状態も提供されません。独自に導入したトンネルプロセスは、fn-knock の起動、停止、ログ管理の対象外です。
• Docker 内の 127.0.0.1 は現在のコンテナを指します。fn-knock ゲートウェイとトンネルプロセスが同じコンテナ内にある場合は使用できますが、別のトンネルコンテナを独自に構築する場合は、サービス名またはコンテナネットワークのアドレスを使用してください。
• リバースプロキシモードでは、スマート接続とプロトコルマッピングを利用できません。追加の TCP / UDP サービスは、FRP または Cloudflare 側で個別に設計する必要があります。
• リバースプロキシモードから切り替えると、fn-knock は管理下にあるトンネルプロセスの停止を試みます。外部で独立して実行しているプロセスは制御対象外です。

起動と検証

1. ルーティング方式、認証 Host、1 件以上のサービス用マッピングを保存します。
2. FRP を保存して起動するか、Cloudflared の API Token を接続し、プレビューを適用します。
3. 実行状態が接続になっていることを確認します。再起動待ち の場合は、連続失敗回数、次回再試行時刻、直近の診断を確認し、Token、TLS、ネットワーク、ポートのエラーを調べます。
4. 外部ネットワークから認証 Host とサービス用 Host へアクセスします。
5. リクエストログで Host、クライアント IP、認証の種類、アップストリームの Target を確認します。

操作手順については、リバースプロキシモードのセットアップとリバースプロキシでのアクセス手順を参照してください。