なぜWake-on-LANはローカルでは動作するのに、家庭用VPN経由では動作しないのですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Does Wake-on-LAN Work Locally but Fail Over a Home VPN? - Zima Store Online

Wake-on-LANは、マジックパケットがスリープ中のデバイスのローカルイーサネットセグメントに届かない場合、VPN経由では失敗します。

ホームネットワークでは、WireGuard、OpenVPN、Tailscale、または他のトンネルを通じて接続された電話やノートパソコンは、ルーティングされたIPサービスにアクセスできますが、自動的にLANのブロードキャストドメインに参加しません。したがって、正しい診断はローカルのウェイクパスを確認し、VPNクライアントが送信するものをキャプチャし、ブロードキャストの配信がどこで停止するかを特定し、認証されていないUDPポートをインターネットに開く代わりに、安全なローカルリレーまたはルーター支援の方法を選択することです。

VPNをテストする前にローカルのウェイクパスを再確認する

同じイーサネットまたはWi-Fi LAN上の別のデバイスから、リモートで使用する予定の正確なMACアドレスと電源状態を使ってターゲットを起動します。スリープ、休止状態、シャットダウンはそれぞれ別々にテストしてください。ハードウェアのサポートはそれぞれ異なる場合があります。

実用的なホームラボガイドでは、Wake-on-LANをブロードキャストマジックパケットとして説明しており、電源が切られたインターフェースがMACアドレスで認識します。ローカルで成功すれば、そのセグメント上でファームウェア、NIC、ケーブル、低電力リスニング状態が機能していることが証明されます。

ターゲットのMAC、VLAN、サブネット、対応するスリープ状態、通常のウェイク遅延を記録してください。ローカルでのウェイクが不安定な場合は、VPNリレーが信頼性のないターゲットを修復できないため、まずBIOS、ドライバー、電源管理、スイッチポート、スタンバイ電源を修正してください。

VPNクライアントが正しい宛先に送信しているか確認する

VPN経由で接続し、Wake-on-LANアプリの宛先アドレス、UDPポート、インターフェース、サブネットマスクを確認します。多くのアプリは、リモートのホームLANのブロードキャストアドレスではなく、デバイスの現在のVPNインターフェースのブロードキャストアドレスをデフォルトにしています。

VPN特有の手順では、パケットはリモートLANのブロードキャストアドレスに向けられる必要があり、トンネルのエンドポイントだけではありません。MACペイロードは正しくても、IP宛先がルーターの誤った側にパケットを配置している場合があります。

VPNゲートウェイでトラフィックをキャプチャし、UDPデータグラムが届くかどうかを確認してください。まったく届かない場合は、VPNクライアントのルートまたはアプリの宛先を修正し、スリーピングホストの古いIPにユニキャストで届く場合はARPとリレーの動作を確認してください。

ブロードキャストをドロップするレイヤー3の境界を特定する

ほとんどのVPNはサブネット間でパケットをルーティングしますが、Wake-on-LANは通常、宛先セグメント上のレイヤー2ブロードキャストとして配信されます。ルーターは無差別な転送がセキュリティや増幅リスクを生むため、指向性ブロードキャストの転送を拒否することが一般的です。

OPNsenseのディスカッションでは、核心的な不一致をまとめています：WoLはレイヤー2のブロードキャストであるのに対し、ファイアウォールとトンネルはレイヤー3で動作します。これが、ウェイクパケットが失敗してもVPN経由で通常のping、SMB、ダッシュボードアクセスが機能する理由です。

VPNインターフェースとホームLANインターフェースの両方でキャプチャしてください。パケットがファイアウォールに入るがLANに出ない場合、スリーピングPCを何度も変更せず、ローカルでパケットを生成できるリレー、ルーター機能、または常時稼働のホームデバイスを選択してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

インターネットからUDPを転送する代わりにローカルリレーをテストする

ルーター、小型サーバー、Home Assistantホスト、または他のNASなど、ホームLAN内の常時稼働デバイスからウェイクコマンドを実行します。そのローカルコマンドは認証されたVPN接続を通じてトリガーします。

ブロードキャスト転送のガイドでは、ローカルWoLリレーをよく推奨しています。リレーはルーティングされたリクエストを受け取り、正しいインターフェースで必要なLANブロードキャストを作成できるためです。

ローカルリレーがデバイスを起動できる場合、VPNを認証境界として維持し、リレー動作のみを信頼できるユーザーに公開してください。ルーターのブロードキャスト動作や悪用リスクを十分に理解していない限り、UDP 7または9への公開ポートフォワーディングは避けてください。

ユニキャストウェイクが一時的にしか機能しない場合はARP状態を確認する

一部のルーターは、MACがARPまたは隣接テーブルに残っている間、ターゲットの最後のIPにユニキャストマジックパケットを送信できます。この方法はシャットダウン直後は機能しますが、そのエントリーが期限切れになると失敗します。

この動作は、リモートウェイクテストがマシンがスリープした直後は成功し、数時間後に失敗する理由を説明します。ルーターは古い隣接エントリーが有効な間だけ宛先MACを知っており、スリーピングホストは新しいARP要求に応答できません。

ルーターが安全にサポートし、NASやPCが安定した予約IPを保持している場合のみ静的隣接エントリーを使用してください。そうでなければ、設計が期限切れのキャッシュに依存しないように、ローカルリレーによるブロードキャストを優先してください。

VPNの到達性とは別にウェイクの成功を検証する

マジックパケットは通常、応答を返しません。送信後は、スイッチのリンク状態、ローカルリレーのログ、スマートプラグの読み取り、または起動後に開始されるサービスへの遅延接続試行で電源状態を確認してください。

ZimaSpaceのVPNとポートフォワーディングの比較は、安全なリモートアクセス経路とマシンを起動するブロードキャスト機構を分離するのに役立ちます。

修復は、同じVPNクライアントがローカルリレーをトリガーでき、ターゲットが意図した低電力状態から起動し、期待されるサービスが一貫した遅延後に到達可能になるときに完了します。マシンは起動するがサービスが到達不能な場合は、起動時のネットワーク、ファイアウォール、DNS、VPNルーティングを別途トラブルシュートしてください。