Wake-on-LAN（リモート起動）
Wake-on-LAN は、LAN に Magic Packet を送信して、電源オフまたはスリープ中のデバイスを起動します。fn-knock はローカルネットワークへ直接ブロードキャストできるほか、別の fn-knock の内蔵 Relay を使って異なるネットワークへ送信できます。ログイン済みユーザーは、ゲートウェイポータルから簡易起動ページを開くこともできます。
Wake-on-LAN は起動信号を送るだけで、デバイス自体の電源管理を置き換えるものではありません。対象のマザーボード、ネットワークアダプター、ファームウェア、OS で WOL を有効にし、シャットダウン後もアダプターへ給電されている必要があります。
機能を有効にする
システム設定 → 機能 → Wake-on-LAN を有効にします。保存するとサイドバーに Wake-on-LAN が表示され、デバイスのオンライン確認、内蔵 Relay、設定済みの外部プラットフォーム接続が開始されます。無効にするとこれらの実行タスクとメニューは停止しますが、デバイス、Relay、外部プラットフォームの設定は削除されません。
最初に同じ LAN 上の 1 台で直接起動を確認してください。その後でネットワーク間 Relay や外部プラットフォームを設定すると、デバイス側で WOL が有効になっていない問題を切り分けやすくなります。
ローカルデバイスを追加する
Wake-on-LAN → デバイス を開き、手動で追加するか デバイスを検出 を使用します。
- 既定では、fn-knock が検出した直結 IPv4 ネットワークをスキャンします。範囲を指定する場合はスキャン設定を開き、1 つ以上の CIDR を入力します。
- 実際に応答し、近隣テーブルから MAC アドレスを解決できたデバイスだけが表示されます。スリープ中、ICMP を拒否している、またはスイッチの近隣テーブルから消えたデバイスは表示されないことがあります。
- デバイスを選択し、名前を確認して一括追加します。検出時にはデバイス IP と、そのネットワークの directed broadcast アドレスも設定されます。
手動追加の主な項目は次のとおりです。
| 項目 | 用途 |
|---|---|
名前 | 管理画面、ポータル、イベントに表示されるデバイス名 |
MAC アドレス | Magic Packet の対象。大文字のコロン区切り形式で保存 |
デバイス IP アドレス | オンライン確認に使用。Magic Packet の唯一の宛先ではない |
起動経路 | ローカルデバイスは直接ブロードキャスト、別ネットワークはペアリング済み Relay を選択 |
ブロードキャストアドレス | ローカル起動で使用。空欄の場合は検出したローカルインターフェースへブロードキャスト |
有効 | 無効なデバイスは設定に残るが、管理画面、ポータル、外部プラットフォームから起動不可 |
起動 の成功はブロードキャストが送信処理へ渡されたことだけを示し、デバイスの起動完了を保証しません。同じデバイスには短いクールダウンがあり、連続操作でパケットを送り続けることはありません。
オンライン状態の判定
有効なデバイスは約 1 分ごとに確認されます。作成または編集後は直ちに確認され、起動要求後にも少し待って 2 回再確認されるため、起動を押した瞬間にオンラインへ変わるわけではありません。
オンライン：プローブへ応答し、応答元アドレスが対象 MAC と一致した状態。オフライン：プローブは完了したが対象が見つからなかった状態。確認待ち：未確認、タイムアウト、Relay が利用不可、またはアドレスを確認できない状態。
DHCP で IP が変わった場合、fn-knock は近隣テーブルから観測アドレスを更新できます。確認待ち を電源オフの証拠と解釈しないでください。コンテナネットワーク、ICMP ポリシー、VLAN 間ルーティング、システム権限によっても結果が不確定になります。
ゲートウェイポータルから起動する
WOL を有効にすると、システム設定 → ゲートウェイ → ポータル に Wake-on-LAN ショートカットを表示 が現れ、既定で有効になります。Wake-on-LAN ページ右上の設定からも変更できます。ログイン済みユーザーが開く内蔵 /__wol__ ページには、有効なデバイスの名前と簡易状態だけが表示され、MAC、デバイス IP、ブロードキャストアドレス、Relay、内部エラーは公開されません。
この入口には、次のすべてが必要です。
- WOL 機能が有効であること。
- ポータルで WOL 表示が許可されていること。
- ブラウザーに有効なログインセッションがあること。
- ログイン資格情報のサービス範囲に内蔵 WOL ページが含まれること。
すべての範囲 では自動的に含まれます。カスタム範囲 の場合は 認証設定 → 権限 で 内蔵 Wake-on-LAN ページ を選択します。ショートカットを非表示にしてもデバイスは削除されず、管理者、Relay、外部プラットフォームからの起動には影響しませんが、公開認証 API から内蔵ページを操作することはできなくなります。
ネットワーク間 Relay
対象が現在の fn-knock と同じブロードキャストドメインにない場合は、対象ネットワークにも fn-knock を配置してペアリングします。
- 制御側で
Wake-on-LAN → ネットワーク間を開き、リモートネットワークを追加から対象側 fn-knock へ到達できる IP を入力します。既定の UDP ポートは40009です。 - 保存後、
FNW1.で始まる一度だけ表示されるペアリングコードをすぐにコピーします。 - 対象側で
Wake-on-LAN → Relay 受信を開き、コードを貼り付けて有効にします。 - 制御側へ戻って
接続テストを行い、対象デバイスの起動経路にこの Relay を選びます。
2 台の fn-knock 間には、サイト間 VPN、管理されたポート転送、その他の信頼できるネットワークなど、ルーティング可能な UDP 経路が必要です。ルーターとホストファイアウォールで Relay の UDP ポートを許可してください。Docker では UDP ポートを明示的に公開し、コンテナから対象 LAN へブロードキャストできることも確認します。
ペアリングコードには事前共有鍵が含まれるため、信頼できる経路でのみ渡してください。Relay の要求と ACK には署名、時刻範囲、リプレイ保護が適用されます。許可する送信元 CIDR で制御側アドレスをさらに限定できますが、PSK の代わりにはなりません。コードを再生成すると古い鍵は直ちに無効になり、対象側へ新しいコードを貼り直す必要があります。両側の時計が大きくずれている場合も要求は拒否されます。
高度なリッスンアドレス、ブロードキャスト先、送信元 CIDR は、自動検出が VLAN、コンテナ、複数インターフェース構成に合わない場合だけ変更してください。ブロードキャスト先は最低 1 件必要で、通常は対象ネットワークの directed broadcast アドレスと UDP 9 を使用します。
Blinker と Bemfa
デバイスを編集し、外部プラットフォーム連携 で 1 つのプロバイダーを選びます。1 台につき 1 プラットフォームだけ有効にでき、接続中、接続済み、再接続中、資格情報なし、異常の各状態が表示されます。
Blinker（点灯科技）
Blinker アプリで独立ネットワークデバイスを作成し、デバイスキーを fn-knock に入力します。switch コンポーネントを連携 を有効にすると、on は起動を実行し、off は現在のオンライン状態だけを返してシャットダウンはしません。状態照会には fn-knock が最後に検出した状態を返します。
Bemfa（巴法云）
Bemfa の秘密鍵と購読トピックを入力します。トピックに使えるのは英数字とアンダースコアだけです。音声プラットフォームの検出が必要な場合は Bemfa の規約に従って 001 または 006 で終わる名前を使用します。
onを受信するとデバイスを起動します。offではシャットダウンせず、現在の状態を{トピック}/upに公開します。- オンライン状態が変化した場合も、上りトピックへ
onまたはoffを同期します。
Mi Home と XiaoAI に連携する
Blinker または Bemfa を設定し、デバイスが接続済みであることを確認したら、次の手順を行います。
- Mi Home アプリを開き、
マイページ → サードパーティプラットフォームに接続に進みます。 巴法（Bemfa）または点灯（Blinker）を検索し、fn-knock の対象デバイスに設定したものと同じプラットフォームを選んで、画面の案内に従って追加します。- アカウントを認証してデバイスを同期すると、Mi Home アプリから起動したり、XiaoAI に電源オンや起動を指示したりできます。
Mi Home と XiaoAI の操作は、選択したプラットフォーム経由で送信されます。オン操作は on に対応して WOL を実行します。オフ操作では対象デバイスをリモートシャットダウンせず、前述の規則に従って現在の状態を返すか同期するだけです。
どちらも fn-knock からプロバイダーの HTTPS および MQTT TLS サービスへ接続できる必要があります。デバイスキー、秘密鍵、トピック、それらを含むスクリーンショットを公開しないでください。プラットフォームのコマンドはゲートウェイポータル画面を経由しないため、信頼できる利用者だけにアカウントとデバイス権限を付与します。
イベント、バックアップ、移行
起動処理ごとに Wake-on-LAN 完了 イベントが作成され、対象、配信経路、実行元（管理者、ポータル、Blinker、Bemfa）、結果、遅延が記録されます。イベントセンターで通知ルールを作成できます。このイベントはブロードキャスト処理の結果であり、デバイスの起動完了ではありません。後続のオンライン状態も確認してください。
デバイス、Relay、機密でない連携設定はアプリ設定に含まれます。Relay PSK、Blinker デバイスキー、Bemfa 秘密鍵は現在のインストールに結び付いた暗号化資格情報ディレクトリに保存され、.knock バックアップには含まれません。移行または復元後は Relay を再ペアリングし、外部資格情報を再入力して、ブロードキャストアドレス、デバイス IP、UDP ポート、ファイアウォールを再確認します。
トラブルシューティングの順序
- 対象の BIOS/UEFI、アダプタードライバー、OS で WOL を有効にし、同じ LAN の別ツールから先にテストします。
- MAC を確認し、完全シャットダウン後もネットワークポートへ給電されているか確認します。
- 直接起動では directed broadcast アドレスを確認します。Docker ではネットワークモード、UDP ブロードキャスト到達性、ホストファイアウォールを優先して調べます。
- 別ネットワークでは Relay の接続を先にテストし、UDP
40009（または設定値）、ルーティング、送信元 CIDR、両側の時計、ペアリングを確認します。 - ブロードキャスト成功後も起動しない場合は、繰り返し送信するのではなく、対象、スイッチ、ブロードキャスト経路を調べます。
- 確認待ちのままなら、デバイス IP、ICMP、近隣テーブル、VLAN 間ルーティング、Relay の状態確認を調べます。
- ポータルに入口がなければ、機能スイッチ、ショートカット表示、資格情報のサービス範囲を確認します。
- 外部プラットフォームが反応しなければ、接続状態と最新エラー、外向き HTTPS/MQTT TLS、資格情報、トピックを確認して再保存します。