Wake-on-LAN oor VPN werk nie? Die uitsending steek nooit oor nie

Jy sit die kantoorrekenaar aan die slaap, skakel van die huis af na die VPN in, en hy bly af. Die tonnel is op, lêerdelings antwoord, en die router se wake-on-LAN-blad meld dat hy die versoek gestuur het. Elke sigbare teken sê die netwerk is reg, en juis daarom is hierdie een verwarrend: die raam wat die masjien sou wakker maak, bereik nooit die segment waarop hy sit nie.

Die simptome wys na die subnet, nie die tonnel nie

Ping misluk vir die slapende gasheer, en daardie deel is normaal. 'n Masjien in bystand het geen lopende IP-stapel nie, kan dus nie ARP of ICMP antwoord nie, en geen mate van tonnelkonfigurasie verander dit nie. Die nuttige toets is of 'n tweede masjien op dieselfde LAN wakker word, en of die router se eie wake-blad werk vir 'n gasheer wat daarop ingeprop is.

Sodra die toets binne dieselfde segment slaag, lê die fout in die omvang. Die sender wat jy gebruik, woon op die VPN-koppelvlak, en die pakket wat hy bou is 'n uitsending vir die plaaslike skakel, so dit gaan uit die verkeerde koppelvlak of glad nêrens heen nie. Die tonnel is nie stukkend nie; hy dra die verkeerde soort verkeer. Vind uit watter koppelvlak die sender kies voordat jy 'n enkele routerinstelling verander.

Die towerpakket is 'n raam, nie 'n diens nie

Die vrag begin met 'n vaste kop van ses 0xFF-grepe, dan die teikenkaart se hardeware-adres sestien keer herhaal, dan 'n opsionele SecureOn-wagwoord van vier grepe. Sendings stop dit gewoonlik in UDP na poort 7 of poort 9, maar die poortnommer is 'n konvensie tussen sender en kaart, nie 'n luisteraar waarmee jy kan koppel nie. Niks luister nie, en niks antwoord nie.

Wat die masjien wakker maak, is die netwerkkoppelvlak, wat 'n klein bietjie stroombane van die bystand-rail af onder spanning hou terwyl die res van die stelsel af is. Daarom moet die instelling 'n volle kragverlies sowel as 'n slaap oorleef: 'n bord wat bystandkrag by afskakeling laat val, het geen kaart oor om iets te ontvang nie.

Waarom 'n gerouteerde tonnel dit nie kan aflewer nie

'n Gerouteerde VPN-koppelvlak is 'n punt-tot-punt-IP-skakel tussen twee tonneladresse. Dit bestaan om pakkette na die eweknie te dra, en daarom werk ping, SSH en lêerdelings normaal daaroor. 'n Uitsendingsraam is nie aan daardie eweknie geadresseer nie, en die beperkte uitsendingsadres word nie sommer deur 'n router aangestuur nie.

Om 'n subnetgerigte uitsending aan te stuur is 'n doelbewuste routervermoë wat die meeste standaardkonfigurasies afskakel, en selfs dan lewer dit aan daardie subnet en nie aan 'n spesifieke slapende kaart nie. 'n Slapende gasheer kan ook nie ARP antwoord nie, so 'n router wat die teikenadres voor aansturing wil oplos, laat die raam val terwyl hy wag vir 'n antwoord wat nooit kom nie. 'n Statiese bindinginskrywing maak daardie deel reg en laat die uitsendingsomvang-probleem onaangeraak. Twee aparte beperkings dus, en die een oplos doen niks vir die ander nie.

Drie plasings wat die kaart werklik bereik

Elke werkbare reëling sit die raam op die teiken se segment, en hulle verskil in hoeveel van die netwerk hulle versteur:

1. Plaas 'n toestel wat altyd aan is op die teikensegment. 'n Router, NAS of klein Linux-boks wat aan bly, kan die raam plaaslik uitstuur sodra jy hom deur die tonnel bereik, en niks aan die VPN verander nie.
2. Laat die router die raam self uitstuur. Baie firmware bied 'n wake-blad wat van die LAN-brug af stuur, wat werk solank die teiken op daardie brug sit en nie agter 'n tweede router nie.
3. Brug die terreine met 'n TAP-tonnel wanneer uitsendings werklik moet oorkruis. Dit voeg twee uitsendingsdomeine saam, wat uitsendingsstorms, een adresplan en elke ontdekkingsprotokol bring wat albei terreine gelyktydig sien.

Die eerste opsie is die een om vir 'n enkele masjien te verkies. Die derde is 'n netwerkontwerpbesluit met deurlopende koste, so behandel dit as sodanig en nie as 'n vinnige regmaak vir een lessenaar nie.

Teken op watter helper die raam stuur en op watter brug of VLAN hy sit. 'n Helper wat op die verkeerde koppelvlak uitstuur, lewer 'n perfekte opname en 'n masjien wat nooit wakker word nie, en daardie kombinasie mors 'n middag.

Verifieer die stuur voordat jy die kliënt blameer

Kontroleer eers die teikenkaart, want geen sender kan 'n kaart wakker maak wat nie gewapen is nie. Die opdrag hieronder lees die ondersteunde en huidige wake-modusse, waar 'n huidige waarde van g beteken die towerpakket is geaktiveer:

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

Voer die opname op die helper uit terwyl die stuur gebeur, en lees dit eerder as om sukses aan te neem. 'n Raam wat die regte brug met die uitsendingsbestemming-MAC verlaat, is die enigste bewys dat die stuur gewerk het; as die opname leeg is, het die sender 'n ander koppelvlak gekies en die res van die toets is betekenisloos. 'n Sender wat 'n rou raam bou eerder as 'n UDP-datagram, pas nie by daardie filter nie, so kyk watter vorm jou gereedskap gebruik voordat jy aflei dat niks gestuur is nie.

Op Windows is die ekwivalent kaartkontrole powercfg /devicequery wake_armed, wat die toestelle lys wat die stelsel mag wakker maak. 'n Netwerkadapter wat uit daardie lys ontbreek, ignoreer elke pakket wat daarheen gestuur word, hoe korrek die raam ook op die draad lyk.

Bevestig dan die wakkerword self en die opvolging. 'n Masjien wat aanskakel maar per naam onbereikbaar bly, het 'n statiese adres en 'n DNS-rekord nodig, want uitsendingsnaamresolusie sal steeds nie die tonnel oorsteek nie. Draadlose wakker maak is 'n aparte en veel minder betroubare vermoë as die bedrade weergawe, so toets dit op dieselfde segment voordat die VPN hoegenaamd betrokke raak. Skryf die koppelvlaknaam en die helper-gasheer in die kaartjie, want die volgende fout gaan gewoonlik oor dieselfde twee feite.