本文へ移動

認証・セッション・サービススコープ

fn-knock の認証はゲートウェイの背後にあるサービスを保護するためのもので、Docker や OpenWrt の管理パネル用パスワードとは異なります。前者は利用者がゲートウェイを通過できるかを決め、後者は管理画面の入口だけを保護します。

1 回のログインで行われること

ローカル以外の送信元から保護対象サービスへアクセスすると、通常は次の手順で処理されます。

  1. ゲートウェイがマッピングルールに基づいて、そのサービスに認証が必要かを判断します。送信元に有効な IP 許可があるか、現在の Host に高度な認証の一時アクセス許可があるかも確認します。
  2. 他に許可される経路がなければ、ログインページで有効になっているボット対策認証を実行します。
  3. 選択中のログインモードで本人確認を完了します。
  4. セッションを作成し、セッション設定に基づいて現在の IP へアクセス許可を付与するか決めます。
  5. Host または保護対象のプロトコルマッピングへアクセスするときに、その認証情報のサービススコープを確認します。

LAN、ループバック、その他のプライベートネットワークからのアクセスはデフォルトでローカル例外となり、上記のフローをすべて通るわけではありません。認証情報のサービススコープによる制限も適用されません。公開側の検証には、実際の外部ネットワークを使用してください。

ログイン後のリダイレクトが停止した場合

認証ページが、戻り先として現在の認証ページ自身を検出した場合、同じ戻り先へのリダイレクトが繰り返された場合、または戻り先のアドレスが安全でない場合は、自動リダイレクトを停止して案内を表示します。このとき認証ページを何度も再読み込みしないでください。元のサービス用 Host に戻ってアクセスをやり直し、認証用 Host、ルートドメインと Cookie の適用範囲、アクセスプロトコル、前段のプロキシが渡す HostX-Forwarded-HostX-Forwarded-Proto の順に確認します。エッジプラットフォームでは、ログインやリダイレクトのレスポンスをキャッシュしないでください。

ログインモード

モード利用できる方式向いている用途
TOTP ログインモードTOTP。紐付け済みの場合はパスキー、QQ、その他の外部アカウントも利用可能個人利用、ハードウェアまたは生体認証で素早くログインしたい場合
パスワードログインモードユーザー名とパスワード複数人で利用し、個別のアカウントが必要な場合

2 つのモードは 認証 で切り替えます。切り替える前に、必要なパスワードまたは TOTP が用意されているかシステムが確認します。切り替え後、無効になった方式で作成されたセッションでは再ログインが必要です。

切り替え操作では、アカウント名、権限、紐付け先の TOTP が同期されます。繰り返し実行してもアカウントが重複して作成されることはなく、設定済みのパスワードがリセットされたり、クイックログインの紐付けが複製されたりすることもありません。パスワードログインモードへ切り替える前に、同期対象となる各アカウントへパスワードを設定する必要があります。TOTP ログインモードへ戻す前には、各アカウントを現在も存在する TOTP に紐付けてください。切り替えを確定すると、無効になったログイン方式で作成されたセッションは破棄されます。

切り替え先失効するセッション
パスワードログインモードTOTP、パスキー、OIDC のセッション
TOTP ログインモードパスワードログインのセッション

認証情報と権限の関係

  • TOTP は名前を付けられる本人確認用の認証情報で、アクセスできるサブドメインとプロトコルマッピングを制限できます。紐付けられたパスキー、QQ、その他の OIDC ログインも同じスコープを継承します。
  • パスワードログインモードのアカウントにも、同様にサービススコープを設定できます。
  • サービススコープを カスタム範囲 にすると、権限画面には保護対象のサブドメイン、組み込みの選択ページ、認証が有効な TCP / UDP プロトコルマッピングが個別に表示されます。何も選ばない場合、その認証情報では保護対象の入口へ一切アクセスできません。組み込みの選択ページ /__select__ も個別に選択してください。
  • ログインを必須にする Host でも、手動で追加した有効な送信元の IP 許可があれば、独立した経路としてアクセスを許可できます。ログイン後に自動作成される IP 許可でも、通常は同じ送信元から引き続きアクセスできます。ただし、自動許可によって、ブラウザーが持つ認証情報のサービススコープ拒否が上書きされることはありません。利用できる送信元の IP 許可がないときに、ゲートウェイはセッションと認証情報のスコープを使って判定を続けます。
  • ログイン後の IP 自動許可は システム設定 → セッション で制御します。これは送信元 IP を許可する経路であり、認証情報のスコープを制御する機能ではありません。手動の IP 許可リストが広すぎると、その送信元はブラウザーでログインしなくても保護対象 Host へ直接アクセスできる可能性があります。
  • サービススコープを制限したログイン認証情報では、任意の Host または元のポートを開ける共通の IP 自動許可は作成されません。送信元 IP によってスコープが拡大されるのを防ぐためです。制限付き TOTP、それに紐付くパスキー / OIDC、サービススコープを制限したパスワードログイン用アカウントが該当します。これらは、直接接続モードで自動許可を得るための認証情報には適していません。
  • 例外として、カスタム範囲には個別のプロトコルマッピングを選択できます。ログイン後の IP アクセス許可が無効でなければ、システムは選択した正確な TCP/UDP + 外部ポート と現在の送信元 IP にだけ、セッション設定に沿った期間のアクセス許可を作成します。未選択のプロトコルマッピングは開かれず、共通 IP 許可リストにもなりません。

管理パネルのパスワードはゲートウェイのログインとは別

Docker や OpenWrt などのデプロイでは、最初に管理パネルのパスワード設定を求められます。このパスワードが保護するのは 7991 の管理入口です。利用者がゲートウェイ配下のサービスへログインするためのアカウントにはならず、TOTP やパスワードログインの代わりにもなりません。

管理パネル専用のパスワードを使うプラットフォームで、fn-knock 管理パネルをサブドメインマッピングに追加すると、認証情報の一覧に 管理パネル 権限が表示されます。特定の TOTP またはアカウントにこの権限を付けると、その認証情報で保護されたサブドメインから管理パネルへアクセスした際に、管理パネルのパスワードを再入力せずに済みます。元の 7991 ポートが公開されることはなく、選択していないサービス用 Host への権限が追加されることもありません。

認証情報のインポートとエクスポート

認証 → その他の操作 → 認証情報のインポート/エクスポート は、現在のログインモードに応じて動作します。

現在のモードエクスポートされる内容
TOTPTOTP secret、名前、権限
パスワードログインアカウント、パスワードハッシュ、権限、紐付けられた TOTP secret

インポートファイルは JSON 形式で、管理画面での上限は 512 KB です。インポート時には認識できるレコードがマージされ、同じ ID、同じユーザー名、同じ secret、またはファイル内の重複項目はスキップされます。パスキーや外部アカウントの紐付けは復元されません。エクスポート内容だけでログインできるため、.knock システムバックアップと同じ水準で保護してください。

高度な認証はログイン方式ではない

サブドメインの高度な認証は、リクエストが送信元、パス、Header、Query、HTTP メソッドのルールに一致したとき、現在の Host だけに有効な一時アクセス許可を発行します。システムのログインセッションやログイン後の IP 許可は作成されず、TOTP、パスキー、OIDC、パスワードログインのサービススコープを継承または変更することもありません。

これは独立した許可経路です。現在のブラウザーセッションのサービススコープにその Host が含まれていなくても、リクエストが高度な認証ルールを満たせば、現在の Host への一時的なアクセス権を取得できます。そのため、既存の認証情報に「もう 1 段階の制限を追加する」目的では使用しないでください。認証情報の範囲を狭めたい場合は、その認証情報自体のサービススコープを変更します。ルールの設定については、サブドメインの高度な認証を参照してください。

推奨する設定順序

  1. 主に使用するログイン方式を 1 つ設定し、予備の認証情報を少なくとも 1 つ用意します。
  2. アクセスを分離したい利用者や端末ごとに、独立した認証情報を作成します。
  3. 各認証情報に、アクセスを許可するサブドメインの範囲を設定します。
  4. その後、よく使う端末にパスキー、QQ、またはその他の外部アカウントログインを紐付けます。
  5. 最後に、セッションの有効期間、ログイン状態を保持、ログイン後の IP 許可ポリシーを調整します。

QQ コミュニティ:1081609274