Wake-on-LAN преку VPN не работи? Емитувањето никогаш не преминува

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