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

Du legger kontormaskinen i dvale, ringer VPN fra hjemmefra, og den blir stående av. Tunnelen er oppe, fildelinger svarer, og ruterens wake-on-LAN-side rapporterer at den sendte forespørselen. Hvert synlige signal sier at nettet er i orden, og nettopp derfor er denne saken forvirrende: rammen som skulle vekke maskinen, når aldri segmentet den står på.

Symptomene peker på subnettet, ikke på tunnelen

Ping feiler for den sovende verten, og den delen er normal. En maskin i standby har ingen kjørende IP-stack, kan altså ikke svare på ARP eller ICMP, og ingen tunnelkonfigurasjon endrer det. Den nyttige testen er om en annen maskin på samme LAN våkner, og om ruterens egen wake-side virker for en vert som er koblet til den.

Når testen i samme segment lykkes, ligger feilen i rekkevidden. Avsenderen du bruker, lever på VPN-grensesnittet, og pakken den bygger er et broadcast for den lokale lenken, så den går ut av feil grensesnitt eller ingen steder i det hele tatt. Tunnelen er ikke ødelagt; den bærer feil slags trafikk. Finn ut hvilket grensesnitt avsenderen velger før du endrer én eneste ruterinnstilling.

Et magic packet er en ramme, ikke en tjeneste

Nyttelasten begynner med et fast header på seks 0xFF-byte, deretter målkortets maskinvareadresse seksten ganger, deretter et valgfritt SecureOn-passord på fire byte. Avsendere pakker dette vanligvis i UDP til port 7 eller port 9, men portnummeret er en konvensjon mellom avsender og kort, ikke en lytter du kan koble til. Ingenting lytter, og ingenting svarer.

Det som vekker maskinen, er nettverksgrensesnittet, som holder en liten mengde kretser strømforsynt fra standby-skinnen mens resten av systemet er av. Derfor må innstillingen overleve både et fullt strømtap og en dvale: et hovedkort som slipper standby-strømmen ved nedstenging, har ikke noe kort igjen til å motta noe.

Hvorfor en rutet tunnel ikke kan levere det

Et rutet VPN-grensesnitt er en punkt-til-punkt-IP-lenke mellom to tunneladresser. Det finnes for å bære pakker adressert til peeren, og derfor oppfører ping, SSH og fildelinger seg normalt gjennom det. En broadcast-ramme er ikke adressert til den peeren, og den begrensede broadcast-adressen videresendes ikke uten videre av en ruter.

Videresending av et subnettrettet broadcast er en bevisst ruterfunksjon som de fleste standardkonfigurasjoner slår av, og selv da leverer det til det subnettet og ikke til et bestemt sovende kort. En sovende vert kan heller ikke svare på ARP, så en ruter som prøver å slå opp måladdressen før videresending, slipper rammen mens den venter på et svar som aldri kommer. En statisk binding løser den delen og lar broadcast-rekkevidde-problemet være urørt. To separate begrensninger altså, og å fjerne den ene gjør ingenting for den andre.

Tre plasseringer som faktisk når kortet

Enhver brukbar ordning setter rammen på målets segment, og de skiller seg i hvor mye av nettet de forstyrrer:

1. Sett en enhet som alltid er på, i målsegmentet. En ruter, NAS eller liten Linux-boks som blir stående på, kan sende rammen lokalt når du først når den gjennom tunnelen, og ingenting ved VPN-en endres.
2. La ruteren sende rammen selv. Mange fastvareversjoner tilbyr en wake-side som sender fra LAN-broen, noe som virker så lenge målet sitter på den broen og ikke bak en andre ruter.
3. Bro stedene med en TAP-tunnel når broadcasts virkelig må krysse. Det slår sammen to broadcast-domener, med broadcast-stormer, én adresseplan og hver oppdagelsesprotokoll som ser begge stedene samtidig.

Det første alternativet er det man bør foretrekke for én maskin. Det tredje er en nettverksdesignbeslutning med løpende kostnad, så behandle det som det og ikke som en rask løsning for én stasjonær maskin.

Noter hvilken hjelper som sender rammen, og hvilken bro eller VLAN den sitter på. En hjelper som sender på feil grensesnitt, gir en perfekt opptak og en maskin som aldri våkner, og den kombinasjonen koster en ettermiddag.

Bekreft sendingen før du klandrer klienten

Sjekk målkortet først, for ingen avsender kan vekke et kort som ikke er armert. Kommandoen nedenfor leser de støttede og gjeldende wake-modusene, der en gjeldende verdi på g betyr at magic packet er slått på:

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

Kjør opptaket på hjelperen mens sendingen skjer, og les det i stedet for å anta suksess. En ramme som forlater riktig bro med broadcast-mål-MAC-en, er det eneste beviset på at sendingen virket; er opptaket tomt, valgte avsenderen et annet grensesnitt, og resten av testen er meningsløs. En avsender som bygger en rå ramme i stedet for et UDP-datagram, passer ikke på det filteret, så sjekk hvilken form verktøyet ditt bruker før du konkluderer med at ingenting ble sendt.

På Windows er den tilsvarende kortkontrollen powercfg /devicequery wake_armed, som lister enhetene som får vekke systemet. En nettverksadapter som mangler i den listen, ignorerer hver pakke som sendes til den, uansett hvor korrekt rammen ser ut på ledningen.

Bekreft deretter selve vekkingen og oppfølgingen. En maskine som starter, men forblir uoppnåelig på navn, trenger en statisk adresse og en DNS-post, fordi broadcast-navneoppslag fortsatt ikke krysser tunnelen. Trådløs vekking er en egen og langt mindre pålitelig funksjon enn den kablede versjonen, så test den på samme segment før VPN-en i det hele tatt kommer inn i bildet. Skriv grensesnittnavnet og hjelperens vert i saken, siden den neste feilen vanligvis handler om de samme to fakta.