TCP / UDP ストリームプロキシ
プロトコルマッピング は、SSH、データベース、DNS など HTTP 以外のサービス用に TCP / UDP のリッスンポートを追加します。ドメインの Host や URL パスは読み取らず、外部ポートのバイトストリームを host:port へ転送します。
この機能は、インターネットから直接到達する サブドメインモード を補完するものです。Web サービスには引き続きサブドメインマッピングを使用し、パス互換ルールについてはパスマッピングを参照してください。
マッピング管理のプロトコルタブで TCP / UDP ルールを管理します。表示は現在のモードとプロトコルマッピング機能の有効状態によります。
有効になる条件
プロトコルマッピング は、インターネットから直接到達するサブドメインルーティング専用です。サイドバーには次の場合に表示されます。
システム設定 → モードがサブドメインモードである。システム設定 → 機能 → プロトコルマッピングが有効、または管理が必要な保存済みルールが残っている。
機能スイッチを無効にするとすべてのリスナーが停止しますが、ルールは削除されません。ルールが残っている間は管理入口と無効状態の案内が表示され、修正または削除できます。無効中は「ゲートウェイを同期」を実行できません。再度有効にすると残ったルールのリスナーが復元されます。サブドメインモードから切り替えた場合も機能とリスナーは停止しますが、ルールは保持されます。
リバースプロキシモード → サブドメインマッピング も Host ルーティングを使用しますが、プロトコルマッピングには対応していません。FRP または Cloudflare で別のプロトコルを転送する場合は、それぞれのプラットフォームで個別に設定する必要があり、fn-knock の HTTP Host エントリーポイントは再利用できません。
ルーティングモデル
TCP :2222 -> 192.168.1.20:22
TCP :13306 -> 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 は共存できますが、同じプロトコルと同じポートのルールは重複できません。
外部ポートをローカル機器の同じポートへ転送することはできません。たとえば TCP :3306 -> 127.0.0.1:3306 はローカル転送ループになるため、保存時と有効化時に拒否されます。localhost、ループバック、未指定アドレス、現在のローカルインターフェースアドレスが検査対象です。外部ポートまたは転送先ポートを変更してください。
サービス起動時に同一ポートのローカルループ、他プロセスが使用中の外部ポート、または安全に適用できない実行時エラーを検出すると、プロトコルマッピング全体を自動的に無効化します。これにより一つの不正なルールが管理画面や他のゲートウェイ機能を妨げません。保存済みルールとサイドバー入口は残り、特定できたプロトコル、ポート、Target、元のエラーが表示されます。
問題のルールを修正・削除してから システム設定 → 機能 で再度有効化してください。ポート競合では待ち受け中のプロセスを確認し、ルールを特定できない場合は最近変更したマッピングを順に確認します。未解決のまま同期や再起動を繰り返しても修復されません。
転送先には、fn-knock の実行環境から到達できる必要があります。Docker 内の 127.0.0.1 はコンテナ自身を指すため、ホストまたは LAN 内の転送先にはコンテナから到達可能なアドレスを使用してください。
一覧検索では、プロトコル、外部ポート、コメント、転送先、サービス検出結果、認証状態が対象になります。コメントは一覧から直接変更できます。プロトコル、ポート、転送先、認証状態はマッピング編集画面から変更します。
サービス検出と厳格なプロトコル検証
新しいプロトコルマッピングは保存後も有効のままで、最初は 厳格な検証は無効 と表示されます。保存後、ルールの操作メニューから 検出 を実行してください。システムが転送先へ能動的に接続し、厳格な検証に対応するサービスを高い確度で識別できた場合は、サービス情報を保存して 厳格なプロトコル検証 を有効にします。サービス種類だけを識別できた場合はその情報を保存しますが、厳格な検証は無効のままです。検出の失敗または結果が曖昧な場合も、マッピングは有効のままで、厳格な検証だけが無効になります。
アップストリーム認証により HTTP の検出結果が 401 だけになり、通常の HTTP と WebDAV などを確実に区別できない場合があります。その場合は操作メニューから サービス種類を指定 を選び、転送先で実際に動作しているサービスを確認します。厳格な検証に対応するサービスなら 確認して検証を有効化 を実行でき、識別だけに対応する種類も厳格な検証を無効のまま保存できます。厳格に検証できる種類を誤って選ぶと、正しい接続もプロトコル不一致として拒否されます。手動指定を消去すると厳格な検証は無効になりますが、マッピングは停止しません。
ルールのトランスポート、外部ポート、または転送先を変更すると、以前のサービス識別結果が消去され、厳格な検証は無効になりますが、マッピングは有効のままです。厳格なプロトコルフィルタリングに依存する場合は、新しい転送先を再検出するか、サービス種類を指定してください。検証済みのサービス情報が保持されるのは、この 3 項目を変えず、コメントまたは認証要件だけを編集した場合です。
既存のサービス識別情報がないルールは、旧形式または厳格な検証が無効として表示される場合があります。アプリを更新しただけでサービス種類が自動指定されることはありません。各転送先を確認して 検出 を実行してください。それまでは、厳格な検証を無効にしたまま転送を継続できます。
トラフィック詳細とアクティブ IP
一覧の トラフィック 列は、TCP/UDP + 外部ポート ごとに個別集計されます。詳細を開くと、リアルタイムの受信／送信速度、現在の接続数、累積トラフィック、および直近 15 分、1 時間、6 時間、1 日、7 日の履歴を確認できます。
同じパネルには、最近アクティブだった送信元 IP も表示されます。マッピングページから直接、ブロックリストへの追加、解除、ローカル IP としての登録ができます。これらの操作はグローバルなブロックリストとローカル IP ルールを変更するため、共有ルールを変更する前にグローバルブロックリストを確認してください。
トラフィック履歴はプロトコルゲートウェイが実際に観測したバイト数で、運用とトラブルシューティング向けです。課金用途には使用しないでください。UDP には接続状態がないため、送信元は短い時間だけアクティブとして扱われます。プロセスの再起動やクリーンアップポリシーにより、保持される履歴が短くなる場合もあります。
認証では送信元 IP と認証情報のスコープを確認
SSH、MySQL、Redis などのクライアントは、fn-knock のログインページを開きません。認証を必須にする を有効にした場合は、次の順序で使用します。
- ブラウザーで fn-knock の Web エントリーポイントを開き、ログインを完了します。
システム設定 → セッション → ログイン後の IP アクセス許可が無効でなければ、ログイン処理によって現在のグローバル IP にプロトコルアクセス許可が作成されます。無効な場合は、その IP / CIDR を手動で追加します。- その後、プロトコルクライアントから同じグローバル IP を使って外部ポートへ接続します。
認証情報が 全範囲 の場合、プロトコルアクセス許可は認証が有効なすべてのプロトコルマッピングで使用できます。カスタム範囲 の場合は、認証 → 権限 で正確な TCP/UDP + 外部ポート を選択してください。現在の送信元 IP は選択したマッピングにだけ許可され、未選択のプロトコルまたはポートは拒否されます。認証情報の範囲を変更すると、既存セッションのプロトコルアクセス許可も同期されます。
グローバル IP が変わった場合、アクセス許可が期限切れになった場合、ログイン後の IP アクセス許可が無効な場合、またはクライアントが別のネットワークを使用した場合、接続は直ちに拒否されます。再度ログインするか、手動のアクセス許可を更新してください。ブラウザー Cookie が TCP / UDP 接続と一緒に送信されることはなく、プロトコル用エントリーポイントは送信元 IP、プロトコル、外部ポートを確認します。手動の IP / CIDR 許可は独立した許可経路です。セッションと IP の変更についてはセッション・送信元 IP 許可・IP 変更、認証方式とカスタム範囲については認証、セッション、サービススコープを参照してください。
プロトコルクライアントにはブラウザー Cookie がないため、ゲートウェイは現在のセッションで確認された送信元 IP をプロトコルアクセス許可へ関連付けます。セッションが有効な間、その現在の送信元 IP はプロトコルアクセス許可の有効期間全体で利用できます。モバイルネットワークの変動で追加された IP は、設定した移動ウィンドウ内でだけ有効です。セッションまたはプロトコルアクセス許可が期限切れになると接続は拒否され、過去にログインしたという理由だけで古い IP が永続的に残ることはありません。
認証を必須にする を無効にすると、そのリッスンポートは認証なしで転送されます。転送先サービス側の SSH 鍵、データベースパスワード、TLS、最小権限の設定は引き続き必要です。
指定した送信元のログインを省略する
認証を必須にする が有効なマッピングでは、操作メニューの ログイン省略を設定 から、指定した送信元だけを事前の Web ログインなしで接続させることができます。条件には、完全一致の送信元 IP、CIDR、送信元地域を使用できます。同じグループ内の条件は AND、別のグループ同士は OR です。一致しない送信元は、通常のログイン認証フローで処理されます。
地域条件は保存時に固定 CIDR 集合へコンパイルされ、地域データベースの更新に合わせて自動更新されません。データベース更新後はポリシーを再保存してください。非常に広い CIDR、または否定条件だけで構成された広範なルールは、保存時に再確認が必要です。1 つのマッピングには最大 16 グループ、各グループには最大 16 条件を保存できます。
ログイン省略で省かれるのは fn-knock のログイン確認だけです。サービス検出や厳格なプロトコル検証は引き続き実行され、転送先自身のアカウント、鍵、TLS の代わりにはなりません。認証を必須にする を無効にすると、すべての送信元がもともと直接接続できるため、ログイン省略ポリシーは停止し、ルールは下書きとして保持される場合があります。認証を再度有効にしたら、ポリシーの状態も再確認してください。
全体の公開時間
プロトコルマッピングページで マッピングを追加 の横にあるメニューを開き、有効化または無効化を予約 を選択すると、すべての TCP / UDP ルールに共通する毎日の公開時間を設定できます。時刻は HH:mm 形式で、サーバーのローカル時刻に従って繰り返されます。有効化と無効化の時刻は同じ値にできません。22:00-06:00 のような設定は自動的に日付をまたぎます。
スケジュール停止と機能の無効化は異なる状態です。
- 機能スイッチを無効にすると、すべてのプロトコルリスナーが停止します。
- スケジュール停止中もポートは待ち受けたままですが、新しい TCP 接続は拒否され、UDP パケットは破棄されます。
- 停止時間の前に確立した TCP セッションは強制切断されません。
- 次の公開時刻になると、ゲートウェイを再同期せずに新しい接続を受け付けます。
この実行スケジュールはすべてのプロトコルマッピングへ適用され、ポートごとに異なる時間は設定できません。管理画面はサーバー時刻に基づいて スケジュール公開中 または スケジュール停止中 を表示します。ブラウザーまたはサーバーのタイムゾーンが誤っている場合は表示と実際の公開時間が想定外になるため、先にサーバーの時計とタイムゾーンを修正してください。
local_exempt
認証サービスは、ゲートウェイが識別したループバック、プライベートネットワーク、リンクローカルの送信元を local_exempt に分類します。これらの送信元から認証が有効なプロトコルマッピングへ接続する場合も、LAN 内からのアクセスとして扱われ、事前の Web ログインは不要です。
そのため、次の点に注意してください。
- LAN 内から接続できても、インターネット側の認証が機能している証明にはなりません。
- ポートの前段に NAT またはプロキシがある場合、ゲートウェイからプロキシのプライベートアドレスが見えていないか確認してください。
- インターネット側のテストには実際の外部ネットワークを使用し、セッションに記録された送信元 IP も確認してください。
保存、同期、ファイアウォール
作成、編集、削除、コメントの変更は順番に保存されるため、連続した操作が互いに上書きすることはありません。リスナーに影響するルール変更ではゲートウェイが更新され、対応するデプロイ環境ではポート許可も同期されます。コメントは管理と検索だけに使用され、転送には影響しません。ゲートウェイと同期 は設定全体を明示的に再送信する操作で、通常は変更のたびに実行する必要はありません。
プラットフォームごとの制限は次のとおりです。
- FNOS ネイティブ FPK は、ファイアウォールの自動管理が有効な場合にプロトコル用ポートを同期できます。
- fn-knock は OpenWrt ホストのファイアウォールを管理しません。プロトコルマッピングは引き続き待ち受けできますが、対応ポートは OpenWrt のファイアウォールで管理者が手動許可する必要があります。
- Docker はホストに新しいポートを公開せず、ホストのファイアウォールも変更しません。コンテナの起動設定で固定ポートを明示的に公開し、ホストとルーターのルールを手動で設定してください。実行中の Compose に対して管理画面でポートを追加するだけでは、インターネットへ公開できません。
- ゲートウェイの実行環境を独自に管理する場合も、ポート許可はシステム管理者の責任です。fn-knock がホストのファイアウォールを変更すると想定しないでください。
プラットフォームがポートを自動許可するかどうかに関係なく、ルーターのポート転送、クラウドセキュリティグループ、上流ネットワークのポリシーでもそのポートを許可する必要があります。
検証とトラブルシューティング
- 現在のモードがインターネットから直接到達するサブドメインモードで、機能スイッチも有効なことを確認します。
- プロトコルと外部ポートがクライアントの設定と一致しているか確認します。
- fn-knock の実行環境から転送先へ直接接続します。
- コンテナのポート公開、ホストのファイアウォール、ルーターの転送、クラウドセキュリティグループを確認します。
- 認証が有効な場合は、ブラウザーログインとプロトコルクライアントが同じグローバル IP を使用し、ログイン後の IP アクセス許可が有効で、カスタム認証情報に現在のプロトコルと外部ポートが含まれていることを確認します。
- 現在のサーバー時刻が全体の公開時間内か確認します。スケジュール停止中もスキャンではポートが見えることがありますが、新しいトラフィックは転送されません。
- 起動失敗により自動無効化されたと表示された場合は、ルール修正またはポート解放後に再有効化します。起動エラーが記録されていないのに保存後も待ち受けない場合だけ、
ゲートウェイと同期を実行して状態とログを確認します。
関連する機能スイッチについては、システム設定とメンテナンスを参照してください。