NAT 越えとトンネル

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

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

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

2 種類のトンネル

方式	外部リソース	適した構成
FRP	frps を実行する公開サーバーとリモートポート	公開アドレス、ポート、トランスポート設定を自分で管理したい
Cloudflared	Cloudflare Tunnel と Public Hostname	Cloudflare を使用済みで、frps を運用せずドメインから接続したい

どちらの場合も、ローカルの転送先は実際のゲートウェイエントリーポイントで、一般的には 127.0.0.1:7999 です。ポートを変更している場合は、管理画面の表示とデプロイ設定を基準にしてください。

ルーティング方式の選択

サブドメインマッピング

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

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

トンネルは元の Host を維持し、認証 Host とサービス用 Host の両方を同じゲートウェイへ送る必要があります。Cloudflared では *.example.com の Public Hostname を使用できます。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 が実行され、構文エラーがある場合は保存できず、フォームモードへ確実に戻すこともできません。

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

Cloudflared

先に システム設定 → Cloudflared でリソースをダウンロードし、その後 トンネル → Cloudflared で Tunnel Token を保存します。公開ドメインとオリジンの Service は Cloudflare Dashboard で設定し、fn-knock では作成しません。

Host ルーティングの推奨設定と TLS の選択については、Cloudflared トンネルの設定を参照してください。

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

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

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

• FRP ではデフォルトの PROXY Protocol v2 を維持することを優先します。
• Cloudflared では、リバースプロキシモード専用のサブドメイン経路を使用し、EdgeOne / ESA スイッチを流用しないでください。
• 起動後はモバイルネットワークからアクセスし、リクエストログのクライアント 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 からだけ利用でき、サービス用トラフィックは 7999 ゲートウェイへ入ります。
• Windows では組み込みリソースも準備状態も提供されません。独自に導入したトンネルプロセスは、fn-knock の起動、停止、ログ管理の対象外です。
• Docker 内の 127.0.0.1 は現在のコンテナを指します。fn-knock ゲートウェイとトンネルプロセスが同じコンテナ内にある場合は使用できますが、別のトンネルコンテナを独自に構築する場合は、サービス名またはコンテナネットワークのアドレスを使用してください。
• リバースプロキシモードでは、スマート接続とプロトコルマッピングを利用できません。追加の TCP / UDP サービスは、FRP または Cloudflare 側で個別に設計する必要があります。
• リバースプロキシモードから切り替えると、fn-knock は管理下にあるトンネルプロセスの停止を試みます。外部で独立して実行しているプロセスは制御対象外です。

起動と検証

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

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