VPN 経由の Wake-on-LAN が動かない？ ブロードキャストは決して越えない

トンネルは上がり、共有は応答するのに、マシンは眠ったままです。magic packet はターゲット自身のセグメントで送出する必要があるため、そこにヘルパーを置きます。

オフィスのマシンをスリープさせ、自宅から VPN に接続しても、そのまま電源が入りません。トンネルは上がり、ファイル共有は応答し、ルーターの wake-on-LAN ページは要求を送ったと報告します。見える信号はどれもネットワークが正常だと言っており、だからこそこの件は混乱します：マシンを起こすはずのフレームが、そのマシンがいるセグメントに決して届かないのです。

症状はトンネルではなくサブネットを指している

眠っているホストへの ping は失敗しますが、そこは正常です。スタンバイ中のマシンには動いている IP スタックがないので、ARP にも ICMP にも応答できず、トンネルの設定をどう変えてもそれは変わりません。有効なのは、同じ LAN の二台目が起きるかどうか、ルーター自身の起動ページがそこにつながったホストに対して機能するかどうかです。

同じセグメントでのテストが通れば、問題はスコープにあります。使っている送信側は VPN インターフェース上にあり、それが組み立てるパケットはローカルリンク向けのブロードキャストなので、間違ったインターフェースから出るか、まったく出ません。トンネルは壊れておらず、誤った種類のトラフィックを運んでいるだけです。ルーターの設定を一つ変える前に、送信側がどのインターフェースを選ぶのかを突き止めてください。

magic packet はフレームであり、サービスではない

ペイロードは六バイトの固定ヘッダー 0xFF で始まり、続いて対象カードのハードウェアアドレスが十六回繰り返され、最後に任意の四バイトの SecureOn パスワードが付きます。送信側はふつう UDP に包んでポート 7 かポート 9 に送りますが、ポート番号は送信側とカードの間の取り決めであって、接続できるリスナーではありません。待ち受けているものはなく、応答するものもありません。

マシンを起こすのはネットワークインターフェースで、システムの残りが切れている間もスタンバイ用のレールから少量の回路に給電し続けます。だからこの設定は、完全な停電にもスリープにも耐えなければなりません：電源を切るときにスタンバイ電源を落とすボードには、受け取るカードが残っていないのです。

ルーティングされたトンネルが届けられない理由

ルーティングされた VPN インターフェースは、二つのトンネルアドレス間のポイントツーポイント IP リンクです。相手宛のパケットを運ぶために存在するので、ping も SSH もファイル共有もその上を普通に通ります。ブロードキャストフレームはその相手宛ではなく、限定ブロードキャストアドレスはルーターが当然のようには転送しません。

サブネット向けブロードキャストの転送はルーターの意図的な機能で、ほとんどの既定設定では切られており、仮に有効でもそのサブネットに届くだけで、特定の眠っているカードには届きません。眠っているホストは ARP にも応答できないため、転送の前に宛先アドレスを解決しようとするルーターは、決して来ない応答を待つ間にフレームを捨てます。静的な結び付けエントリがその部分を直し、ブロードキャストのスコープ問題はそのまま残ります。つまり二つの別個の制約であり、片方を解消してももう片方には何の効果もありません。

実際にカードへ届く三つの配置

どの実用的な構成でもフレームを対象のセグメントに置きますが、ネットワークをどれだけ乱すかが異なります：

  1. 対象セグメントに常時電源の機器を置きます。通電したままのルーター、NAS、小さな Linux ボックスなら、トンネル経由で到達した時点でフレームをローカルに送出でき、VPN 側は何も変わりません。
  2. ルーター自身にフレームを出させます。多くのファームウェアには LAN ブリッジから送る起動ページがあり、対象がそのブリッジ上にあり、二台目のルーターの背後でなければ機能します。
  3. ブロードキャストが本当に越えなければならない場合は、TAP 方式のトンネルで拠点をブリッジします。これは二つのブロードキャストドメインを統合するので、ブロードキャストストーム、単一のアドレス設計、両拠点を同時に見る検出プロトコルが付いてきます。

一台のマシンなら最初の選択肢が適しています。三つ目は恒久的なコストを伴うネットワーク設計の判断なので、そう扱うべきで、一台のデスクトップ向けの即席の修正ではありません。

どのヘルパーがフレームを出し、どのブリッジや VLAN にいるのかを記録します。間違ったインターフェースから出すヘルパーは完璧なキャプチャと決して起きないマシンをもたらし、その組み合わせは半日を無駄にします。

クライアントを責める前に送出を確認する

準備されていないカードはどの送信側でも起こせませんから、まず対象カードを確認します。次のコマンドは対応している起動モードと現在のモードを読み、現在の値が g なら magic packet が有効です：

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

送信の間にヘルパーでキャプチャを実行し、成功したと決めつけずに読んでください。正しいブリッジからブロードキャスト宛先 MAC で出ていくフレームだけが、送信が機能した証拠です；キャプチャが空なら送信側は別のインターフェースを選んでおり、残りのテストは無意味です。UDP データグラムではなく生のフレームを組み立てる送信側はこのフィルターに合わないので、何も送られていないと結論する前に、使っているツールがどちらの形式かを確認してください。

Windows では同等のカード確認が powercfg /devicequery wake_armed で、システムを起動できるデバイスを一覧します。この一覧にないネットワークアダプターは、ケーブル上でフレームがどれほど正しく見えても、届いたパケットをすべて無視します。

そのうえで起動そのものと後続を確認します。電源は入るのに名前で到達できないマシンには固定アドレスと DNS レコードが必要で、ブロードキャストによる名前解決はやはりトンネルを越えません。無線の起動は有線版とは別で信頼性がはるかに低いため、VPN を絡める前に同じセグメントで試してください。インターフェース名とヘルパーのホストをチケットに書き留めておきます：次の不具合もたいてい同じ二つの事実に絡むからです。

関連記事