Пробуждение спящего домашнего ПК через VPN: откуда приходит пакет

Вы подключаетесь, роутер отвечает, а настольный компьютер остаётся тёмным. Туннель в порядке; пакет, который должен был разбудить машину, так и не дошёл до сегмента, где машина слушает. Если пройти путь от роутера назад, видно, где он умирает.

Три устройства имеют три задачи. Их смешение — обычная причина того, что попытка пробуждения крутится бесконечно.

Начните с удалённого клиента и пройдите по пути

Из гостиничной сети вы подключаетесь к домашнему роутеру, единственной постоянно работающей конечной точке на картинке. Запрос на пробуждение, набранный на ноутбуке, становится обычным трафиком туннеля, адресованным любому указанному вами назначению. Это назначение решает всё последующее.

Если вы отправили его на LAN-адрес домашнего роутера на порт magic packet, роутер может принять датаграмму и никогда не выдать кадр в домашний сегмент, потому что там ничто не слушает этот порт. Если вы широковещательно рассылаете его внутри туннеля, он останавливается на интерфейсе туннеля. Маршрутизируемый туннель не является расширением уровня 2 домашней проводки. Пройдите путь шаг за шагом, и тупик становится очевидным.

Проверка, которая это решает, требует одной команды с удалённой стороны и одной с домашней. Отправьте запрос, затем наблюдайте за домашним сегментом в поисках кадра.

Переместите отправителя в домашний сегмент

Роутер может выполнить пробуждение сам, как только вы аутентифицируетесь через туннель. OpenWrt документирует службу Wake-on-LAN, которая работает на устройстве и выдаёт кадр локально, и это именно нужная форма: удалённая аутентификация снаружи, локальная рассылка внутри.

Такая схема также держит функцию пробуждения подальше от публичного интернета. Ничего нового не выставляется в интернет, потому что триггер идёт по VPN, которому вы уже доверяете. Альтернатива — служба пробуждения с перенаправленным портом — меняет небольшое удобство на обращённую в интернет конечную точку, которую может проверить кто угодно.

Циклическую зависимость стоит назвать прямо. VPN-клиент, установленный на настольном компьютере, не может разбудить этот компьютер, потому что процессу клиента нужна работающая машина. Держите удалённую точку входа на роутере или другом всегда включённом устройстве, а настольный компьютер пусть будет только целью.

Подтвердите цель, прежде чем винить туннель

Эту часть решает аппаратное обеспечение, а не VPN, и состояние питания решает её первым. Адаптер должен поддерживать пробуждение, прошивка должна оставлять адаптер под питанием во сне, а операционная система должна быть настроена это разрешать. Приостановленная машина — другой случай, чем выключенная, и оба отличаются от машины, у которой питание отключено у стены. Разберитесь с этим состоянием, прежде чем проходить остальной список.

Считайте аппаратный адрес с адаптера, который действительно примет кадр. У настольного компьютера с Ethernet и Wi-Fi часто два адреса, и только один из них может уметь пробуждать. Беспроводное пробуждение — отдельная возможность со своими требованиями к прошивке, поэтому работающее пробуждение через Ethernet ничего не говорит о пробуждении через 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 — полезная. Запись, которая меняется с неполной на настоящий аппаратный адрес, означает, что машина продолжила работу и ответила; запрос, который так и не разрешается, указывает обратно на шаг пробуждения, а не на службу, к которой вы пытались попасть.

Разделяйте этапы в заметках: пробуждение, загрузка, служба. Сбой на втором этапе из окна чата выглядит так же, как сбой на первом, и различить их может только локальное свидетельство.