Wake-on-LAN через VPN не работает? Широковещательный кадр так и не проходит

Вы усыпляете офисную машину, поднимаете VPN из дома, а она остаётся выключенной. Туннель поднят, файловые ресурсы отвечают, и страница wake-on-LAN на роутере сообщает, что запрос отправлен. Каждый видимый сигнал говорит, что сеть в порядке, и именно поэтому этот случай сбивает с толку: кадр, который разбудил бы машину, никогда не доходит до сегмента, в котором она находится.

Симптомы указывают на подсеть, а не на туннель

Ping до спящего хоста не проходит, и эта часть нормальна. Машина в ждущем режиме не имеет работающего стека IP, поэтому не может ответить ни на ARP, ни на ICMP, и никакая настройка туннеля этого не меняет. Полезная проверка — просыпается ли вторая машина в той же локальной сети и работает ли страница пробуждения самого роутера для подключённого к нему хоста.

Как только проверка в том же сегменте проходит, дело в области действия. Отправитель, которым вы пользуетесь, живёт на интерфейсе 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. Запишите в заявку имя интерфейса и хост помощника, потому что следующая неисправность обычно касается тех же двух фактов.