Wake-on-LAN през VPN не работи? Излъчването никога не преминава

Тунелът е вдигнат и споделените папки отговарят, но машината остава заспала. Magic packet трябва да се излъчи в сегмента на самата цел, затова поставете там помощник.

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

Симптомите сочат подмрежата, не тунела

Ping към заспалия хост се проваля и тази част е нормална. Машина в готовност няма работещ IP стек, затова не може да отговори на ARP или ICMP, и никаква конфигурация на тунела не променя това. Полезният тест е дали се събужда втора машина в същата LAN и дали страницата за събуждане на самия рутер работи за хост, включен към него.

Щом тестът в същия сегмент мине, дефектът е в обхвата. Подателят, който използвате, живее на интерфейса на VPN, а пакетът, който строи, е излъчване за локалната връзка, затова излиза през грешния интерфейс или никъде. Тунелът не е счупен; той пренася грешния вид трафик. Открийте кой интерфейс избира подателят, преди да промените дори една настройка на рутера.

Magic packet е кадър, не услуга

Полезният товар започва с фиксирано заглавие от шест байта 0xFF, после адресът на хардуера на целевата карта, повторен шестнадесет пъти, после незадължителна парола SecureOn от четири байта. Подателите обикновено го опаковат в UDP към порт 7 или порт 9, но номерът на порта е конвенция между подател и карта, а не услуга, която слуша и към която можете да се свържете. Нищо не слуша и нищо не отговаря.

Това, което събужда машината, е мрежовият интерфейс, който поддържа малка част от схемите захранени от standby шината, докато останалата част от системата е изключена. Затова настройката трябва да оцелее както при пълна загуба на захранване, така и при сън: дънна платка, която при изключване отрязва standby захранването, няма вече карта, която да получи нещо.

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

Рутиран интерфейс на 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. Запишете името на интерфейса и хоста на помощника в заявката, защото следващият дефект обикновено се отнася до същите две факти.

Подобни статии