VPN 経由の Wake-on-LAN が動かない?ARP エントリを修正する
マジックパケットはトンネルを越えますが、ルーターの ARP エントリが期限切れになると破棄されます。三つの配送経路を比較し、MAC アドレスを恒久的に固定しましょう。
シャットダウン直後に起動パケットを送れば PC は戻ってきますが、翌朝に同じコマンドを実行しても何も起きません。VPN の設定は何も変わっておらず、ポート転送も正しいアドレスを指したままです。違いは時間です。ルーターの近隣テーブルがスリープ中のマシンを忘れてしまい、フレームに載せる MAC アドレスがなくなっているのです。トンネルではなく、この期限切れが VPN 経由の Wake-on-LAN の失敗の大半を説明します。
最初の起動は成功し、次は失敗する
ルーターは近隣テーブルで宛先を調べて、プライベートアドレスへフレームを転送します。マシンが動いている間は ARP に応答するため、対応関係は新しいままです。電源が切れると誰も応答しなくなり、数分でエントリが古くなり、そのアドレス宛の後続のフレームは IP とポート転送が有効なままでも破棄されます。
パターンを見れば、どの失敗なのか分かります。 まったく起動しない場合は配送の問題です:ポートが違う、宛先が違う、あるいは LAN に届く前にパケットを捨てるファイアウォールがある、といったケースです。一度だけ成功して何時間も失敗する場合は近隣エントリの問題です。DHCP リースが変わるまで成功する場合はアドレッシングの問題で、予約で解決できます。
ARP に触る前に、アドレスが安定していることを確認してください。リース切れでスリープ中のマシンが新しいアドレスを取ると、古いアドレスに固定した近隣エントリは恒久的かつ無用になります。まず DHCP 予約を設定して、再起動後もアドレスが残るようにしましょう。
マジックパケットがネットワークに求めるもの
ペイロードは単純です。六個の 0xFF バイトの後に宛先 MAC アドレスを 十六回繰り返した 102 バイトで、通常は UDP ポート 9 に送られます。フラットな LAN ではブロードキャストとして流れ、すべてのポートが受け取り、電源の切れたネットワークカードが自分のアドレスを認識します。
VPN を越えると、パケットはプライベートアドレス宛のユニキャスト、またはサブネット宛のディレクテッドブロードキャストとしてルーターに届きます。ユニキャストの場合、ルーターはフレームを LAN に載せる前に宛先を MAC アドレスへ解決する必要があり、ホストが眠っている間はまさにその解決が失敗します。
ツールによっては 9 ではなくポート 7 に送り、一部の機器は既定でディレクテッドブロードキャストを遮断します。これは配送の失敗であり ARP の失敗ではないので、近隣テーブルを変える前に宛先とポートを確認してください。
眠っているホストへの 三つの経路
フレームを LAN に載せる実用的な方法は 三つあり、正しい選択は自分が何を制御できるかで決まります。
| Method | What it needs | Where it breaks |
|---|---|---|
| Subnet-directed broadcast | A wake tool that accepts a broadcast address and a router that forwards it | Broadcast filtering, or a tool that only takes a MAC |
| Helper on the LAN | An always-on host such as the VPN server | No suitable host, or the host cannot reach the target VLAN |
| Permanent neighbour entry | Router shell access and the target MAC | NIC replacement or address change |
常時稼働のホストがあるならそれを選びましょう。リンク上でブロードキャストするため、ルーター側の例外設定が不要です。ルーターがすでに許可していて起動ツールがアドレスを受け付けるなら、ディレクテッドブロードキャストを選びます。どちらも使えず、ルーターでコマンドを実行できるなら静的エントリを選びます。
これらは排他的ではありません。恒久エントリはユニキャスト経路もスリープを越えられるようにし、VPN クライアントが特定のアドレスにしか送れない場合に役立ちます。
近隣エントリを恒久的にする
Linux シェルを備えたルーターなら、一つのコマンドで対応関係を固定できます。ここに示す値は例の LAN のものなので、自分の値に置き換えてください:
ip neigh replace 192.168.50.23 lladdr 3c:7c:3f:12:9a:4e dev br0 nud permanent
ip neigh show dev br0 | grep 192.168.50.23この nud permanent という状態は ARP のタイムアウトを越えてエントリを保持し、マシンが切れている間も転送に使います。二つ目のコマンドはエントリの存在を証明し、それが属するインターフェースを示します。ゲストブリッジや VLAN を分けているルーターではこれが重要です。
ファームウェアが用意する任意のフックで再起動後も残しましょう:/jffs/scripts でのスクリプト、ゲートウェイとして動く Linux サーバーの systemd oneshot ユニット、Neighbor= stanza(systemd-networkd)、あるいは /etc/ethers を読むローカルツールのエントリです。シェルに入力したコマンドは次の再起動で消えるので、動いていた修正が止まったように見える最もよくある理由がこれです。
外から試し、削除する時期を知る
マシンをスリープさせ、少なくとも 十分待ちます。動的なエントリが期限切れになるのに十分な時間です。次に VPN クライアントから起動要求を送り、ルーターの両側を観察します:
tcpdump -ni tun0 udp port 9
tcpdump -ni br0 ether proto 0x0806 or udp port 9最初のキャプチャでパケットがトンネルから届いたことが分かり、二つ目でルーターが LAN にフレームを載せたことが分かります。正しいマジックパケットは MAC が繰り返された 102 バイトとして現れるので、宛先だけでなく長さも確認してください。フレームが LAN ブリッジを出ているのにマシンが起動しないなら、残る問題はデバイス側です。高速スタートアップ、ディープスリープ、あるいはネットワークカードへの給電を切る BIOS 設定などです。
ネットワークカードを交換したらエントリを削除し、マシンを別のアドレスへ移したら更新してください。恒久的な対応付けは意図的な例外であり、誰も覚えていない例外こそ、将来のノート PC が引退したデスクトップ宛のフレームを受け取る原因になります。