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. Запишіть у заявку ім'я інтерфейсу і хост помічника, бо наступна несправність зазвичай стосується тих самих двох фактів.