通过 VPN 唤醒沉睡的家用电脑：数据包从哪里来

你连上了，路由器也回应了，台式机却依旧黑着。隧道没有问题；本该唤醒机器的数据包从未到达机器监听的那一段网络。从路由器往回逐段排查，就能看出它死在哪里。

三台设备各有分工。把它们混为一谈，正是唤醒尝试无限循环的常见原因。

从远端客户端出发，沿着路径排查

从酒店网络你连到家庭路由器，它是整个图景中唯一常开的端点。你在笔记本上键入的唤醒请求变成普通的隧道流量，被送往你指定的任何目的地。这个目的地决定了后面的一切。

如果你把它发到家庭路由器的 LAN 地址、magic packet 端口上，路由器可能收下数据报，却永远不会向家庭网段发出帧，因为那里没有任何东西在监听那个端口。如果你在隧道内部广播它，它会停在隧道接口。被路由的隧道 并不是家庭布线的第 2 层延伸。逐跳走完这条路径，死胡同就显而易见了。

决定性的检查需要远端一条命令、家庭端一条命令。发出请求，然后在家庭网段上观察帧。

把发送方移到家庭网段上

一旦你通过隧道完成认证，路由器自己就能完成唤醒。OpenWrt 记录了一项在设备上运行并本地发出帧的 Wake-on-LAN 服务，这正是所需的形态：外部远端认证，内部本地广播。

这种安排也让唤醒功能远离公网。没有任何新东西暴露到互联网，因为触发器走的是你早已信任的 VPN。另一种做法是用端口转发提供唤醒服务，用一点便利换来了一个任何人都能探测的公网端点。

这个循环依赖值得直说。装在台式机上的 VPN 客户端无法唤醒这台台式机，因为客户端进程需要机器正在运行。把远端入口放在路由器或其他常开设备上，让台式机只做目标。

在责怪隧道之前，先确认目标

这一部分由硬件决定，而不是 VPN，而且电源状态先决定它。网卡必须支持唤醒，固件必须在睡眠中保持网卡供电，操作系统必须配置为允许这样做。挂起的机器与已关机的机器是两种不同情况，两者又都不同于在墙边切断电源的机器。先把状态弄清楚，再往下走清单。

从真正会接收帧的那块网卡上读取硬件地址。同时有以太网和 Wi-Fi 的台式机通常有两个地址，而其中只有一个可能具备唤醒能力。无线唤醒是另一项能力，有自己的固件要求，所以以太网唤醒能用，并不能说明 Wi-Fi 唤醒如何。

先证明本地路径。从同一台交换机上的另一台设备发出 magic packet，看机器是否起来。如果失败，再多隧道调试也没用，故障在固件、网卡设置或电源状态上。

恢复之后，连接你真正想要的服务

唤醒不等于远程访问。机器恢复之后，仍然要启动服务、取得地址，并接受你真正需要的会话。在断定唤醒失败之前，给它时间走到那一步。

# remote side: trigger the wake through the already-authenticated tunnel
ssh [email protected] 'wol -i br-lan 3c:7a:8f:2b:11:04'

# home side: is the target answering on the LAN?
ping -c 3 10.10.0.42
arp -n 10.10.0.42

arp 那一行才是有用的。条目从未完成变成真实的硬件地址，说明机器恢复了并作出了应答；始终无法解析的请求，指向的是唤醒这一步，而不是你想连上的服务。

在笔记里把阶段分开：唤醒、启动、服务。第二阶段失败，从聊天窗口看和第一阶段失败一模一样，只有本地证据能把它们区分开。