Wake-on-LAN over VPN virker ikke? Broadcastet når aldrig frem

Du sætter kontormaskinen i dvale, ringer VPN op hjemmefra, og den bliver slukket. Tunnelen er oppe, filstier svarer, og routerens wake-on-LAN-side rapporterer, at den har sendt anmodningen. Hvert synligt signal siger, at netværket er i orden, og netop derfor er denne sag forvirrende: det frame, der ville vække maskinen, når aldrig det segment, den står på.

Symptomerne peger på subnettet, ikke på tunnelen

Ping fejler for den sovende vært, og den del er normal. En maskine i standby har ingen kørende IP-stak, kan altså ikke svare på ARP eller ICMP, og ingen tunnelkonfiguration ændrer det. Den nyttige test er, om en anden maskine på samme LAN vågner, og om routerens egen wake-side virker for en vært, der er sat til den.

Når testen i samme segment lykkes, ligger fejlen i rækkevidden. Afsenderen, du bruger, lever på VPN-interfacet, og den pakke, den bygger, er et broadcast til det lokale link, så den går ud af det forkerte interface eller ingen steder hen. Tunnelen er ikke i stykker; den bærer den forkerte slags trafik. Find ud af, hvilket interface afsenderen vælger, før du ændrer en enkelt routerindstilling.

Et magic packet er et frame, ikke en tjeneste

Nyttelasten begynder med et fast header på seks 0xFF-bytes, derefter målkortets hardwareadresse seksten gange, derefter en valgfri SecureOn-adgangskode på fire bytes. Afsendere pakker det normalt i UDP til port 7 eller port 9, men portnummeret er en konvention mellem afsender og kort, ikke en listener, du kan forbinde til. Intet lytter, og intet svarer.

Det, der vækker maskinen, er netværksinterfacet, som holder en lille smule kredsløb strømført fra standby-skinnen, mens resten af systemet er slukket. Derfor skal indstillingen overleve både et fuldt strømtab og en dvale: et bundkort, der dropper standby-strøm ved nedlukning, har ikke noget kort tilbage til at modtage noget.

Hvorfor en routet tunnel ikke kan levere det

Et routet VPN-interface er et punkt-til-punkt-IP-link mellem to tunneladresser. Det findes for at bære pakker adresseret til peer'en, og derfor opfører ping, SSH og filstier sig normalt gennem det. Et broadcast-frame er ikke adresseret til den peer, og den begrænsede broadcast-adresse videresendes ikke bare af en router.

Videresendelse af et subnet-rettet broadcast er en bevidst routerevne, som de fleste standardkonfigurationer slår fra, og selv da leverer det til det subnet og ikke til et bestemt sovende kort. En sovende vært kan heller ikke svare på ARP, så en router, der prøver at opløse måladdressen før videresendelse, dropper framet, mens den venter på et svar, der aldrig kommer. En statisk binding løser den del og lader broadcast-rækkevidde-problemet urørt. To separate begrænsninger altså, og at fjerne den ene gør intet for den anden.

Tre placeringer, der faktisk når kortet

Enhver brugbar opsætning sætter framet på målets segment, og de adskiller sig i, hvor meget af netværket de forstyrrer:

1. Sæt en enhed, der altid er tændt, på målsegmentet. En router, NAS eller lille Linux-boks, der bliver tændt, kan sende framet lokalt, når du først når den gennem tunnelen, og intet ved VPN'en ændres.
2. Lad routeren sende framet selv. Mange firmware tilbyder en wake-side, der sender fra LAN-broen, hvilket virker, så længe målet sidder på den bro og ikke bag en anden router.
3. Forbind stederne med en TAP-tunnel, når broadcasts virkelig skal krydse. Det smelter to broadcast-domæner sammen med broadcast-storme, én adresseplan og enhver discovery-protokol, der ser begge steder på én gang.

Den første mulighed er den, man bør foretrække til en enkelt maskine. Den tredje er en netværksdesignbeslutning med løbende omkostninger, så behandl den som sådan og ikke som en hurtig løsning på én desktop.

Notér, hvilken hjælper der sender framet, og hvilken bro eller VLAN den sidder på. En hjælper, der sender på det forkerte interface, giver en perfekt optagelse og en maskine, der aldrig vågner, og den kombination koster en eftermiddag.

Bekræft afsendelsen, før du bebrejder klienten

Tjek målkortet først, for ingen afsender kan vække et kort, der ikke er armert. Kommandoen nedenfor læser de understøttede og aktuelle wake-tilstande, hvor en aktuel værdi på g betyder, at magic packet er aktiveret:

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

Kør optagelsen på hjælperen, mens afsendelsen sker, og læs den i stedet for at antage succes. Et frame, der forlader den rigtige bro med broadcast-destinations-MAC'en, er det eneste bevis på, at afsendelsen virkede; er optagelsen tom, valgte afsenderen et andet interface, og resten af testen er meningsløs. En afsender, der bygger et rå frame i stedet for et UDP-datagram, matcher ikke det filter, så tjek, hvilken form dit værktøj bruger, før du konkluderer, at intet blev sendt.

På Windows er den tilsvarende kortkontrol powercfg /devicequery wake_armed, som lister de enheder, der må vække systemet. En netværksadapter, der mangler på den liste, ignorerer enhver pakke, der sendes til den, hvor korrekt framet end ser ud på ledningen.

Bekræft derefter selve vækningen og opfølgningen. En maskine, der tænder, men forbliver uopnåelig på navn, har brug for en statisk adresse og en DNS-post, for broadcast-navneopløsning krydser stadig ikke tunnelen. Trådløs vækning er en separat og langt mindre pålidelig evne end den kablede version, så test den på samme segment, før VPN'en overhovedet kommer ind i billedet. Skriv interfacenavnet og hjælperens vært i billetten, for den næste fejl handler som regel om de samme to fakta.