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. Запішыце ў заяўку імя інтэрфейса і хост памочніка, бо наступная непаладка звычайна датычыцца тых самых двух фактаў.