Wake-on-LAN cez VPN nefunguje? Broadcast sa nikdy neprenesie

Uspíte kancelársky stroj, z domu vytočíte VPN, a on zostane vypnutý. Tunel beží, súborové priečinky odpovedajú a stránka wake-on-LAN routera hlási, že požiadavku odoslala. Každý viditeľný signál hovorí, že sieť je v poriadku, a práve preto je tento prípad mätúci: rámec, ktorý by stroj zobudil, sa nikdy nedostane do segmentu, kde stroj sedí.

Príznaky ukazujú na podsiet, nie na tunel

Ping na spiaceho hostiteľa zlyhá a tá časť je normálna. Stroj v pohotovostnom režime nemá bežiaci IP zásobník, takže nemôže odpovedať na ARP ani ICMP, a žiadna konfigurácia tunela to nezmení. Užitočný test je, či sa zobudí druhý stroj v tej istej LAN a či stránka wake samotného routera funguje pre hostiteľa, ktorý je doň zapojený.

Keď test v tom istom segmente prejde, závada je v dosahu. Odosielateľ, ktorý používate, žije na rozhraní VPN, a paket, ktorý zostavuje, je broadcast pre lokálne spojenie, takže vychádza nesprávnym rozhraním alebo vôbec. Tunel nie je pokazený; prenáša nesprávny druh prevádzky. Zistite, ktoré rozhranie odosielateľ vyberá, skôr než zmeníte jediné nastavenie routera.

Magic packet je rámec, nie služba

Užitočné zaťaženie začína pevnou hlavičkou šiestich bajtov 0xFF, potom adresa hardvéru cieľovej karty opakovaná šestnásťkrát, potom voliteľné heslo SecureOn o štyroch bajtoch. Odosielatelia to zvyčajne balia do UDP na port 7 alebo port 9, ale číslo portu je konvencia medzi odosielateľom a kartou, nie načúvajúca služba, ku ktorej sa pripojíte. Nič nepočúva a nič neodpovedá.

To, čo stroj zobúdza, je sieťové rozhranie, ktoré udržuje malú časť obvodov napájanú z pohotovostnej vetvy, kým zvyšok systému je vypnutý. Preto nastavenie musí prežiť úplný výpadok napájania aj spánok: doska, ktorá pri vypnutí odreže pohotovostné napájanie, už nemá kartu, ktorá by niečo prijala.

Prečo to smerovaný tunel nedoručí

Smerované rozhranie VPN je IP spojenie bod-bod medzi dvoma adresami tunela. Existuje preto, aby prenášalo pakety adresované protistrane, a preto sa cez neho ping, SSH aj súborové priečinky správajú normálne. Broadcastový rámec nie je adresovaný tej protistrane a obmedzená broadcastová adresa sa routerom nikdy automaticky nepreposiela.

Preposielanie broadcastu smerovaného do podsiete je zámerná schopnosť routera, ktorú väčšina predvolených konfigurácií vypína, a aj vtedy doručuje do tej podsiete, nie konkrétnej spiacej karte. Spiaci hostiteľ tiež nemôže odpovedať na ARP, takže router, ktorý sa pred preposlaním snaží preložiť cieľovú adresu, rámec zahodí, kým čaká na odpoveď, ktorá nikdy nepríde. Statická položka väzby opraví tú časť a problém dosahu broadcastu nechá nedotknutý. Dve oddelené obmedzenia, teda, a odstránenie jedného pre druhé nič neurobí.

Tri umiestnenia, ktoré kartu skutočne zasiahnu

Každé funkčné usporiadanie umiestni rámec do segmentu cieľa a líšia sa tým, ako veľmi rušia sieť:

1. Postavte do cieľového segmentu zariadenie, ktoré je vždy zapnuté. Router, NAS alebo malá krabica s Linuxom, ktorá zostane napájaná, môže rámec vyslať lokálne, len čo sa k nej tunelom dostanete, a na VPN sa nič nemení.
2. Nechajte rámec vyslať samotný router. Mnoho firmvérov ponúka stránku wake, ktorá odosiela z mosta LAN, čo funguje, kým cieľ sedí na tom moste a nie za druhým routerom.
3. Prepojte lokality mostom s tunelom typu TAP, keď broadcasty naozaj musia prechádzať. To zlúči dve broadcastové domény, prinesie broadcastové búrky, jediný plán adresovania a každý protokol zisťovania vidí obe lokality naraz.

Prvá možnosť je tá, ktorú je pre jediný stroj vhodné uprednostniť. Tretia je rozhodnutie o návrhu siete s trvalými nákladmi, takže ju berte ako také, a nie ako rýchlu opravu pre jeden počítač.

Poznamenajte, ktorý pomocník rámec odosiela a na ktorom moste alebo VLAN sedí. Pomocník, ktorý vysiela na nesprávnom rozhraní, dá dokonalý záznam a stroj, ktorý sa nikdy nezobudí, a tá kombinácia stojí popoludnie.

Overte odoslanie, skôr než obviníte klienta

Skontrolujte najprv cieľovú kartu, pretože žiadny odosielateľ nezobudí kartu, ktorá nie je vyzbrojená. Príkaz nižšie číta podporované a aktuálne režimy wake, kde aktuálna hodnota g znamená, že magic packet je zapnutý:

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

Spustite záznam na pomocníkovi počas odosielania a prečítajte ho, namiesto toho, aby ste predpokladali úspech. Rámec, ktorý opúšťa správny most s broadcastovou cieľovou MAC, je jediný dôkaz, že odoslanie fungovalo; ak je záznam prázdny, odosielateľ zvolil iné rozhranie a zvyšok testu nič neznamená. Odosielateľ, ktorý stavia surový rámec namiesto UDP datagramu, tomuto filtru nezodpovedá, preto skontrolujte, akú formu váš nástroj používa, kým usúdite, že sa nič neodoslalo.

Vo Windows je zodpovedajúca kontrola karty powercfg /devicequery wake_armed, ktoré vypisuje zariadenia smúce prebúdzať systém. Sieťový adaptér chýbajúci v tom zozname bude ignorovať každý paket, ktorý mu príde, nech rámec na drôte vyzerá akokoľvek správne.

Potom potvrďte samotné prebudenie a nasledujúce kroky. Stroj, ktorý sa zapne, ale zostane nedostupný podľa mena, potrebuje statickú adresu a záznam DNS, pretože preklad mien broadcastom tunelom stále neprechádza. Bezdrôtové prebúdzanie je samostatná a oveľa menej spoľahlivá schopnosť než drôtová verzia, preto ju otestujte v tom istom segmente, kým do veci vôbec zapojíte VPN. Napíšte do tiketu názov rozhrania a hostiteľa pomocníka, pretože nasledujúca závada sa zvyčajne týka tých istých dvoch faktov.