Wake-on-LAN преко VPN-а не ради? Емитовање никада не прелази

Тунел је успостављен и дељења одговарају, али рачунар остаје успаван. Magic packet мора се емитовати у сегменту саме мете, зато тамо поставите помоћника.

Успавате канцеларијски рачунар, бирате VPN од куће, а он остаје искључен. Тунел је успостављен, дељења датотека одговарају, а страница wake-on-LAN рутера извештава да је послала захтев. Сваки видљиви сигнал каже да је мрежа у реду, и управо зато је овај случај збуњујућ: оквир који би пробудио рачунар никада не стиже до сегмента на коме се налази.

Симптоми упућују на подмрежу, не на тунел

Пинг према успаваном хосту не успева, и тај део је нормалан. Рачунар у стању приправности нема покренут IP стек, па не може да одговори на ARP ни ICMP, и никаква конфигурација тунела то не мења. Користан тест је да ли се буди други рачунар у истом LAN-у и да ли страница wake самог рутера ради за хост који је на њега прикључен.

Када тест у истом сегменту прође, квар је у домету. Пошиљалац који користите живи на интерфејсу VPN-а, а пакет који саставља је емитовање за локалну везу, па излази кроз погрешан интерфејс или никуда. Тунел није покварен; преноси погрешну врсту саобраћаја. Откријте који интерфејс пошиљалац бира пре него што промените и једну поставку рутера.

Magic packet је оквир, а не услуга

Корисни терет почиње фиксним заглављем од шест бајтова 0xFF, затим адреса хардвера циљне картице поновљена шеснаест пута, затим необавезна лозинка SecureOn од четири бајта. Пошиљаоци то обично пакују у UDP на порт 7 или порт 9, али број порта је конвенција између пошиљаоца и картице, а не услуга која слуша и на коју можете да се повежете. Ништа не слуша и ништа не одговара.

Оно што буди рачунар јесте мрежни интерфејс, који одржава мали део кола напајаним из приправне шине док је остатак система искључен. Зато поставка мора да преживи и потпуни губитак напајања и успављивање: матична плоча која при искључивању одсече приправно напајање нема више картице која би нешто примила.

Зашто усмерени тунел то не може да достави

Усмерени интерфејс VPN-а је IP веза од тачке до тачке између две адресе тунела. Постоји да преноси пакете адресиране на партнера, и зато се пинг, SSH и дељења датотека кроз њега понашају нормално. Оквир емитовања није адресиран на тог партнера, а ограничена адреса емитовања никада се не прослеђује рутером сам по себи.

Прослеђивање емитовања усмереног на подмрежу намерна је могућност рутера коју већина подразумеваних конфигурација искључује, а и тада се доставља тој подмрежи, а не одређеној успаваној картици. Успавани хост такође не може да одговори на ARP, па рутер који пре прослеђивања покушава да разреши циљну адресу одбацује оквир док чека одговор који никада неће доћи. Статички унос повезивања решава тај део и оставља проблем домета емитовања нетакнутим. Два одвојена ограничења, дакле, и уклањање једног ништа не чини за друго.

Три смештаја који заиста стижу до картице

Сваки изводљив распоред ставља оквир у сегмент мете, а разликују се по томе колико ремете мрежу:

  1. Поставите уређај који је стално укључен у циљни сегмент. Рутер, NAS или мала Linux кутија која остаје напајана може да емитује оквир локално чим до ње дођете кроз тунел, и ништа се у VPN-у не мења.
  2. Пустите рутер да сам емитује оквир. Многи фирмвери нуде страницу wake која шаље са LAN моста, што ради док мета седи на том мосту, а не иза другог рутера.
  3. Премостите локације тунелом типа TAP када емитовања заиста морају да пређу. То спаја две домене емитовања, доноси олује емитовања, један план адресирања и сваки протокол откривања који види обе локације одједном.

Прва је опција коју треба преферирати за један рачунар. Трећа је одлука о дизајну мреже са сталним трошком, па је тако и третирајте, а не као брзу поправку за један рачунар.

Запишите који помоћник емитује оквир и на ком мосту или VLAN-у седи. Помоћник који емитује на погрешном интерфејсу даје савршен снимак и рачунар који се никада не пробуди, а та комбинација стоји једно поподне.

Проверите слање пре него што оптужите клијента

Најпре проверите циљну картицу, јер ниједан пошиљалац не може да пробуди картицу која није наоружана. Наредба у наставку чита подржане и тренутне режиме wake, где тренутна вредност 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. Запишите назив интерфејса и хост помоћника у захтев, јер се следећи квар обично тиче истих двеју чињеница.

Повезани чланци