Wake-on-LAN přes VPN nefunguje? Broadcast se nikdy nepřenese

Tunel běží a sdílené složky odpovídají, ale stroj zůstává spát. Magic packet se musí vyslat v segmentu samotného cíle, proto tam postav pomocníka.

Uspíte kancelářský stroj, z domova vytočíte VPN, a on zůstane vypnutý. Tunel běží, souborové složky odpovídají a stránka wake-on-LAN routeru hlásí, že požadavek odeslala. Každý viditelný signál říká, že síť je v pořádku, a právě proto je tenhle případ matoucí: rámec, který by stroj probudil, se nikdy nedostane do segmentu, kde stroj sedí.

Příznaky ukazují na podsíť, ne na tunel

Ping na spící hostitel selže a ta část je normální. Stroj v pohotovostním režimu nemá běžící IP zásobník, takže nemůže odpovědět na ARP ani ICMP, a žádná konfigurace tunelu to nezmění. Užitečný test je, jestli se probudí druhý stroj ve stejné LAN a jestli stránka wake samotného routeru funguje pro hostitele, který je do něj zapojený.

Jakmile test ve stejném segmentu projde, závada je v dosahu. Odesílatel, který používáte, žije na rozhraní VPN, a paket, který sestavuje, je broadcast pro lokální spoj, takže vychází špatným rozhraním nebo vůbec. Tunel není rozbitý; přenáší špatný druh provozu. Zjistěte, které rozhraní odesílatel vybírá, než změníte jediné nastavení routeru.

Magic packet je rámec, ne služba

Užitečné zatížení začíná pevnou hlavičkou šesti bajtů 0xFF, pak adresa hardwaru cílové karty opakovaná šestnáctkrát, pak volitelné heslo SecureOn o čtyřech bajtech. Odesílatelé to obvykle balí do UDP na port 7 nebo port 9, ale číslo portu je konvence mezi odesílatelem a kartou, ne naslouchající služba, ke které se připojíte. Nic neposlouchá a nic neodpovídá.

To, co stroj probouzí, je síťové rozhraní, které udržuje malou část obvodů napájenou z pohotovostní větve, zatímco zbytek systému je vypnutý. Proto nastavení musí přežít úplný výpadek napájení i spánek: deska, která při vypnutí odřízne pohotovostní napájení, už nemá kartu, která by něco přijala.

Proč to směrovaný tunel nedoručí

Směrované rozhraní VPN je IP spoj bod-bod mezi dvěma adresami tunelu. Existuje proto, aby přenášelo pakety adresované protějšku, a proto se přes něj ping, SSH i souborové složky chovají normálně. Broadcastový rámec není adresován tomu protějšku a omezená broadcastová adresa se routerem nikdy nepředává automaticky.

Předávání broadcastu směrovaného do podsítě je záměrná schopnost routeru, kterou většina výchozích konfigurací vypíná, a i pak doručuje do té podsítě, ne konkrétní spící kartě. Spící hostitel také nemůže odpovědět na ARP, takže router, který se před předáním snaží přeložit cílovou adresu, rámec zahodí, zatímco čeká na odpověď, která nikdy nepřijde. Statická položka vazby opraví tuhle část a problém dosahu broadcastu nechá nedotčený. Dvě oddělená omezení, tedy, a odstranění jednoho pro druhé nic neudělá.

Tři umístění, která kartu skutečně zasáhnou

Každé funkční uspořádání umístí rámec do segmentu cíle a liší se v tom, jak moc ruší síť:

  1. Postavte do cílového segmentu zařízení, které je vždy zapnuté. Router, NAS nebo malá krabička s Linuxem, která zůstane napájená, může rámec vyslat lokálně, jakmile se k ní tunelem dostanete, a na VPN se nic nemění.
  2. Nechte rámec vyslat samotný router. Mnoho firmwarů nabízí stránku wake, která odesílá z mostu LAN, což funguje, dokud cíl sedí na tom mostu a ne za druhým routerem.
  3. Propojte lokality mostem s tunelem typu TAP, když broadcasty opravdu musí přecházet. To sloučí dvě broadcastové domény, přinese broadcastové bouře, jediný plán adresování a každý protokol zjišťování vidící obě lokality najednou.

První možnost je ta, kterou je pro jediný stroj vhodné upřednostnit. Třetí je rozhodnutí o návrhu sítě s trvalými náklady, takže ho berte jako takové, a ne jako rychlou opravu pro jeden počítač.

Poznamenejte, který pomocník rámec odesílá a na kterém mostu nebo VLAN sedí. Pomocník, který vysílá na špatném rozhraní, dá dokonalý záznam a stroj, který se nikdy neprobudí, a tahle kombinace stojí odpoledne.

Ověřte odeslání, než obviníte klienta

Zkontrolujte nejprve cílovou kartu, protože žádný odesílatel neprobudí kartu, která není vyzbrojená. Příkaz níže čte podporované a aktuální režimy wake, kde aktuální 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

Spusťte záznam na pomocníkovi během odesílání a přečtěte ho, místo abyste předpokládali úspěch. Rámec, který opouští správný most s broadcastovou cílovou MAC, je jediný důkaz, že odeslání fungovalo; je-li záznam prázdný, odesílatel zvolil jiné rozhraní a zbytek testu nic neznamená. Odesílatel, který staví surový rámec místo UDP datagramu, tomuto filtru neodpovídá, proto zkontrolujte, jakou formu váš nástroj používá, než usoudíte, že se nic neodeslalo.

Ve Windows je odpovídající kontrola karty powercfg /devicequery wake_armed, které vypisuje zařízení smějící probouzet systém. Síťový adaptér chybějící v tom seznamu bude ignorovat každý paket, který mu přijde, ať rámec na drátě vypadá jakkoli správně.

Potom potvrďte samotné probuzení a následné kroky. Stroj, který se zapne, ale zůstane nedostupný podle jména, potřebuje statickou adresu a záznam DNS, protože překlad jmen broadcastem tunelem stále neprochází. Bezdrátové probouzení je samostatná a mnohem méně spolehlivá schopnost než drátová verze, proto ji otestujte ve stejném segmentu, než do věci vůbec zapojíte VPN. Napište do tiketu název rozhraní a hostitele pomocníka, protože příští závada se obvykle týká stejných dvou faktů.

Související články