TCP / UDP ストリームプロキシ

プロトコルマッピング は、SSH、データベース、DNS など HTTP 以外のサービス用に TCP / UDP のリッスンポートを追加します。ドメインの Host や URL パスは読み取らず、外部ポートのバイトストリームを host:port へ転送します。

この機能は、インターネットから直接到達する サブドメインモード を補完するものです。Web サービスには引き続きサブドメインマッピングを使用し、パス互換ルールについてはパスマッピングを参照してください。

有効になる条件

サイドバーに プロトコルマッピング を表示するには、次の条件を両方満たす必要があります。

1. システム設定 → モード が サブドメインモード である。
2. システム設定 → 機能 → プロトコルマッピング が有効になっている。

機能スイッチを無効にすると、プロトコルマッピングのリスナーが停止してメニューが非表示になりますが、保存済みのルールは保持されます。再度有効にすると以前の設定が復元されます。サブドメインモードから切り替えた場合も機能とリスナーは停止しますが、ルールは保持されます。

リバースプロキシモード → サブドメインマッピング も Host ルーティングを使用しますが、プロトコルマッピングには対応していません。FRP または Cloudflare で別のプロトコルを転送する場合は、それぞれのプラットフォームで個別に設定する必要があり、fn-knock の HTTP Host エントリーポイントは再利用できません。

ルーティングモデル

TCP :2222 -> 192.168.1.20:22
TCP :3306 -> 127.0.0.1:3306
UDP :53   -> 127.0.0.1:53

ドメイン名はエントリーポイントのアドレスを名前解決するだけで、プロトコルの振り分けには関与しません。クライアントは nas.example.com:2222 へ接続できますが、最終的に一致するルールはトランスポートプロトコルとポートだけで決まります。

ルール項目

項目	説明
トランスポートプロトコル	TCP と UDP。両方選択でき、保存後は 2 つのルールに分割される
外部ポート	クライアントが接続するポート。範囲は 1-65535
コメント	用途が似たマッピングを区別、検索するための任意の説明
転送先	host:port だけを指定し、http:// やパスは付けない
認証を必須にする	接続前に、送信元 IP に基づいて fn-knock の認証状態を確認

同じポートに TCP と UDP のルールを 1 つずつ作成できます。たとえば 53/tcp と 53/udp は共存できますが、同じプロトコルと同じポートのルールは重複できません。

転送先には、fn-knock の実行環境から到達できる必要があります。Docker 内の 127.0.0.1 はコンテナ自身を指すため、ホストまたは LAN 内の転送先にはコンテナから到達可能なアドレスを使用してください。

一覧検索では、プロトコル、外部ポート、コメント、転送先、認証状態が対象になります。コメントは一覧から直接変更できます。プロトコル、ポート、転送先、認証状態はマッピング編集画面から変更します。

認証では送信元 IP と認証情報のスコープを確認

SSH、MySQL、Redis などのクライアントは、fn-knock のログインページを開きません。認証を必須にする を有効にした場合は、次の順序で使用します。

1. ブラウザーで fn-knock の Web エントリーポイントを開き、ログインを完了します。
2. システム設定 → セッション → ログイン後の IP アクセス許可 が無効でなければ、ログイン処理によって現在のグローバル IP にプロトコルアクセス許可が作成されます。無効な場合は、その IP / CIDR を手動で追加します。
3. その後、プロトコルクライアントから同じグローバル IP を使って外部ポートへ接続します。

認証情報が 全範囲 の場合、プロトコルアクセス許可は認証が有効なすべてのプロトコルマッピングで使用できます。カスタム範囲 の場合は、認証 → 権限 で正確な TCP/UDP + 外部ポート を選択してください。現在の送信元 IP は選択したマッピングにだけ許可され、未選択のプロトコルまたはポートは拒否されます。認証情報の範囲を変更すると、既存セッションのプロトコルアクセス許可も同期されます。

グローバル IP が変わった場合、アクセス許可が期限切れになった場合、ログイン後の IP アクセス許可が無効な場合、またはクライアントが別のネットワークを使用した場合、接続は直ちに拒否されます。再度ログインするか、手動のアクセス許可を更新してください。ブラウザー Cookie が TCP / UDP 接続と一緒に送信されることはなく、プロトコル用エントリーポイントは送信元 IP、プロトコル、外部ポートを確認します。手動の IP / CIDR 許可は独立した許可経路です。セッションと IP の変更についてはセッション・送信元 IP 許可・IP 変更、認証方式とカスタム範囲については認証、セッション、サービススコープを参照してください。

プロトコルクライアントにはブラウザー Cookie がないため、ゲートウェイは現在のセッションで確認された送信元 IP をプロトコルアクセス許可へ関連付けます。セッションが有効な間、その現在の送信元 IP はプロトコルアクセス許可の有効期間全体で利用できます。モバイルネットワークの変動で追加された IP は、設定した移動ウィンドウ内でだけ有効です。セッションまたはプロトコルアクセス許可が期限切れになると接続は拒否され、過去にログインしたという理由だけで古い IP が永続的に残ることはありません。

認証を必須にする を無効にすると、そのリッスンポートは認証なしで転送されます。転送先サービス側の SSH 鍵、データベースパスワード、TLS、最小権限の設定は引き続き必要です。

local_exempt

認証サービスは、ゲートウェイが識別したループバック、プライベートネットワーク、リンクローカルの送信元を local_exempt に分類します。これらの送信元から認証が有効なプロトコルマッピングへ接続する場合も、LAN 内からのアクセスとして扱われ、事前の Web ログインは不要です。

そのため、次の点に注意してください。

• LAN 内から接続できても、インターネット側の認証が機能している証明にはなりません。
• ポートの前段に NAT またはプロキシがある場合、ゲートウェイからプロキシのプライベートアドレスが見えていないか確認してください。
• インターネット側のテストには実際の外部ネットワークを使用し、セッションに記録された送信元 IP も確認してください。

保存、同期、ファイアウォール

作成、編集、削除、コメントの変更は順番に保存されるため、連続した操作が互いに上書きすることはありません。リスナーに影響するルール変更ではゲートウェイが更新され、対応するデプロイ環境ではポート許可も同期されます。コメントは管理と検索だけに使用され、転送には影響しません。ゲートウェイと同期 は設定全体を明示的に再送信する操作で、通常は変更のたびに実行する必要はありません。

プラットフォームごとの制限は次のとおりです。

• FNOS ネイティブ FPK、およびホスト上で root 権限を利用できる OpenWrt は、ファイアウォールの自動管理が有効な場合にプロトコル用ポートを同期できます。
• Docker はホストに新しいポートを公開せず、ホストのファイアウォールも変更しません。コンテナの起動設定で固定ポートを明示的に公開し、ホストとルーターのルールを手動で設定してください。実行中の Compose に対して管理画面でポートを追加するだけでは、インターネットへ公開できません。
• ゲートウェイの実行環境を独自に管理する場合も、ポート許可はシステム管理者の責任です。fn-knock がホストのファイアウォールを変更すると想定しないでください。

プラットフォームがポートを自動許可するかどうかに関係なく、ルーターのポート転送、クラウドセキュリティグループ、上流ネットワークのポリシーでもそのポートを許可する必要があります。

検証とトラブルシューティング

1. 現在のモードがインターネットから直接到達するサブドメインモードで、機能スイッチも有効なことを確認します。
2. プロトコルと外部ポートがクライアントの設定と一致しているか確認します。
3. fn-knock の実行環境から転送先へ直接接続します。
4. コンテナのポート公開、ホストのファイアウォール、ルーターの転送、クラウドセキュリティグループを確認します。
5. 認証が有効な場合は、ブラウザーログインとプロトコルクライアントが同じグローバル IP を使用し、ログイン後の IP アクセス許可が有効で、カスタム認証情報に現在のプロトコルと外部ポートが含まれていることを確認します。
6. 保存後もリッスンしていない場合は ゲートウェイと同期 をクリックし、状態とログを確認します。

関連する機能スイッチについては、システム設定とメンテナンスを参照してください。