Wake-on-LAN over VPN verkar ikkje? Broadcastet når aldri fram

Du legg kontormaskinen i dvale, ringjer VPN heimanfrå, og han blir ståande av. Tunnelen er oppe, fildelingar svarar, og wake-on-LAN-sida til ruteren melder at han har sendt førespurnaden. Kvart synleg signal seier at nettet er i orden, og nettopp difor er denne saka forvirrande: ramma som skulle vekkje maskinen, når aldri segmentet han står på.

Symptoma peikar på subnettet, ikkje på tunnelen

Ping feilar for den sovande verten, og den delen er normal. Ei maskin i standby har ingen køyrande IP-stack, kan altså ikkje svare på ARP eller ICMP, og ingen tunnelkonfigurasjon endrar det. Den nyttige testen er om ei anna maskin på same LAN vaknar, og om eigen wake-side på ruteren verkar for ein vert som er kopla til han.

Når testen i same segment lukkast, ligg feilen i rekkevidda. Avsendaren du brukar, lever på VPN-grensesnittet, og pakken han byggjer er eit broadcast for den lokale lenkja, så han går ut av feil grensesnitt eller ingen stad i det heile. Tunnelen er ikkje øydelagd; han ber feil slag trafikk. Finn ut kva grensesnitt avsendaren vel før du endrar éi einaste ruterinnstilling.

Eit magic packet er ei ramme, ikkje ei teneste

Nyttelasten byrjar med eit fast header på seks 0xFF-byte, deretter maskinvareadressa til målkortet seksten gonger, deretter eit valfritt SecureOn-passord på fire byte. Avsendarar pakkar dette vanlegvis i UDP til port 7 eller port 9, men portnummeret er ein konvensjon mellom avsendar og kort, ikkje ein lyttar du kan kople til. Ingenting lyttar, og ingenting svarar.

Det som vekkjer maskinen, er nettverksgrensesnittet, som held ein liten mengd krinsar straumforsynte frå standby-skina medan resten av systemet er av. Difor må innstillinga overleve både eit fullt straumtap og ein dvale: eit hovudkort som slepp standby-straumen ved nedstenging, har ikkje noko kort att til å ta imot noko.

Kvifor ein ruta tunnel ikkje kan levere det

Eit ruta VPN-grensesnitt er ei punkt-til-punkt-IP-lenkje mellom to tunneladresser. Det finst for å bere pakkar adresserte til peeren, og difor oppfører ping, SSH og fildelingar seg normalt gjennom det. Ei broadcast-ramme er ikkje adressert til den peeren, og den avgrensa broadcast-adressa blir ikkje utan vidare vidaresend av ein ruter.

Vidaresending av eit subnettretta broadcast er ein medviten ruterfunksjon som dei fleste standardkonfigurasjonar slår av, og sjølv då leverer det til det subnettet og ikkje til eit bestemt sovande kort. Ein sovande vert kan heller ikkje svare på ARP, så ein ruter som prøver å slå opp måladdressa før vidaresending, slepp ramma medan han ventar på eit svar som aldri kjem. Ei statisk binding løyser den delen og lèt broadcast-rekkevidde-problemet vere urørt. To separate avgrensingar altså, og å fjerne den eine gjer ingenting for den andre.

Tre plasseringar som faktisk når kortet

Kvar brukbar ordning set ramma på segmentet til målet, og dei skil seg i kor mykje av nettet dei forstyrrar:

1. Set ein eining som alltid er på, i målsegmentet. Ein ruter, NAS eller liten Linux-boks som blir ståande på, kan sende ramma lokalt når du først når han gjennom tunnelen, og ingenting ved VPN-en blir endra.
2. Lat ruteren sende ramma sjølv. Mange fastvareversjonar tilbyr ei wake-side som sender frå LAN-brua, noko som verkar så lenge målet sit på den brua og ikkje bak ein andre ruter.
3. Brua stadene med ein TAP-tunnel når broadcasts verkeleg må krysse. Det slår saman to broadcast-domene, med broadcast-stormar, éin adresseplan og kvar oppdagingsprotokoll som ser begge stadene samstundes.

Det første alternativet er det ein bør føretrekkje for éi maskin. Det tredje er eit nettverksdesignvedtak med løpande kostnad, så handsam det som det og ikkje som ei snøgg løysing for ein stasjonær maskin.

Noter kva hjelpar som sender ramma, og kva bru eller VLAN han sit på. Ein hjelpar som sender på feil grensesnitt, gir eit perfekt opptak og ei maskin som aldri vaknar, og den kombinasjonen kostar ein ettermiddag.

Stadfest sendinga før du klandrar klienten

Sjekk målkortet først, for ingen avsendar kan vekkje eit kort som ikkje er armert. Kommandoen nedanfor les dei støtta og gjeldande wake-modusane, der ein gjeldande 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

Køyr opptaket på hjelparen medan sendinga skjer, og les det i staden for å anta suksess. Ei ramme som forlèt rett bru med broadcast-mål-MAC-en, er det einaste beviset på at sendinga virka; er opptaket tomt, valde avsendaren eit anna grensesnitt, og resten av testen er meiningslaus. Ein avsendar som byggjer ei rå ramme i staden for eit UDP-datagram, passar ikkje på det filteret, så sjekk kva form verktøyet ditt brukar før du konkluderer med at ingenting vart sendt.

På Windows er den tilsvarande kortkontrollen powercfg /devicequery wake_armed, som listar einingane som får vekkje systemet. Ein nettverksadapter som manglar i den lista, overser kvar pakke som blir send til han, uansett kor korrekt ramma ser ut på leidningen.

Stadfest deretter sjølve vekkinga og oppfølginga. Ei maskin som startar, men blir verande utilgjengeleg på namn, treng ei statisk adresse og ein DNS-post, fordi broadcast-namneoppslag framleis ikkje kryssar tunnelen. Trådlaus vekking er ein eigen og langt mindre påliteleg funksjon enn den kabelbundne versjonen, så test han på same segment før VPN-en i det heile kjem inn i biletet. Skriv grensesnittnamnet og verten til hjelparen i saka, sidan den neste feilen vanlegvis handlar om dei same to fakta.