Wake-on-LAN oer VPN wurket net? De broadcast komt der nea troch

De tunnel stiet en dielen antwurdzje, dochs bliuwt de masine sliepe. It magic packet moat op it eigen segmint fan it doel stjoerd wurde, set dêr dus in helper del.

Jo sette de kantoarmasine te sliepen, skilje fan hûs út de VPN oan, en hy bliuwt út. De tunnel stiet, bestânsdielen antwurdzje, en de wake-on-LAN-side fan de router meldt dat er it fersyk stjoerd hat. Elk sichtber sinjaal seit dat it netwurk goed is, en krekt dêrom is dit gefal betiizjend: it frame dat de masine wekker meitsje soe, berikt nea it segmint dêr't er op sit.

De symptomen wize op it subnet, net op de tunnel

Ping mislearret foar de sliepende host, en dat part is normaal. In masine yn standby hat gjin rinnende IP-stack, kin dus gjin ARP of ICMP beantwurdzje, en gjin inkelde tunnelkonfiguraasje feroaret dat. De nuttige test is oft in twadde masine op itselde LAN wekker wurdt, en oft de wake-side fan de router wurket foar in host dy't dêrop oansletten is.

Sadree't de test yn itselde segmint slagget, sit de flater yn 'e omfang. De stjoerder dy't jo brûke, libbet op de VPN-interface, en it pakket dat er bout is in broadcast foar de lokale link, dus it giet de ferkearde interface út of hielendal nearne hinne. De tunnel is net stikken; hy ferfiert it ferkearde soarte ferkear. Sykje út hokker interface de stjoerder kiest foardat jo ien routerynstelling feroarje.

In magic packet is in frame, gjin tsjinst

De payload begjint mei in fêste kop fan seis 0xFF-bytes, dan it hardwareadres fan 'e doalkaart sechstjin kear, dan in opsjoneel SecureOn-wachtwurd fan fjouwer bytes. Stjoerders stopje dat meastal yn UDP nei poart 7 of poart 9, mar it poartnûmer is in konvinsje tusken stjoerder en kaart, gjin listener dêr't jo mei ferbine kinne. Der lústeret neat, en der antwurdet neat.

Wat de masine wekker makket, is de netwurkinterface, dy't in lyts part fan 'e skeakelingen ûnder spanning hâldt fan 'e standby-rail wylst de rest fan it systeem út is. Dêrom moat de ynstelling sawol in folslein krêstferlies as in sliep oerlibje: in board dat by it útskeakeljen de standby-spanning falle lit, hat gjin kaart mear oer om wat te ûntfangen.

Wêrom in routearre tunnel it net leverje kin

In routearre VPN-interface is in punt-nei-punt-IP-keppeling tusken twa tunneladressen. Hy bestiet om pakketten nei de peer te dragen, en dêrom wurkje ping, SSH en bestânsdielen der normaal trochhinne. In broadcast-frame is net oan dy peer adressearre, en it beheinde broadcastadres wurdt troch in router net samar trochstjoerd.

It trochstjoeren fan in subnetrjochte broadcast is in bewuste routerkwaliteit dy't de measte standertkonfiguraasjes útsette, en sels dan levert it by dat subnet en net by in spesifike sliepende kaart. In sliepende host kin ek gjin ARP beantwurdzje, dus in router dy't it doeladres foar it trochstjoeren oplosse wol, lit it frame falle wylst er wachtet op in antwurd dat nea komt. In statyske bining makket dat part klear en lit it broadcast-omfangprobleem ûnoantaast. Twa aparte beheiningen dus, en it iene oplosse docht neat foar it oare.

Trije pleatsingen dy't de kaart echt berikke

Elke wurkbere opstelling set it frame op it segmint fan it doel, en se ferskille yn hoefolle fan it netwurk se fersteure:

  1. Set in apparaat dat altyd oan is op it doelsegmint. In router, NAS of lytse Linux-doaze dy't oan bliuwt, kin it frame lokaal stjoere sadree't jo him troch de tunnel berikke, en oan de VPN feroaret neat.
  2. Lit de router it frame sels stjoere. In protte firmware biedt in wake-side dy't fan 'e LAN-bridge ôf stjoert, wat wurket salang it doel op dy bridge sit en net efter in twadde router.
  3. Bregje de lokaasjes mei in TAP-tunnel as broadcasts echt oerkruise moatte. Dat foeget twa broadcast-domeinen gear, mei broadcast-stoarmen, ien adresplan en elk ûntdekkingsprotokol dat beide lokaasjes tagelyk sjocht.

De earste opsje is de foarkarsopsje foar ien masine. De tredde is in netwurkûntwerpbeslút mei trochgeande kosten, behannelje him dus as sadanich en net as in flugge repaasje foar ien buroblêd.

Skriuw op hokker helper it frame stjoert en op hokker bridge of VLAN er sit. In helper dy't op 'e ferkearde interface stjoert, leveret in perfekte opname en in masine dy't nea wekker wurdt, en dy kombinaasje kostet in middei.

Kontrolearje it stjoeren foardat jo de klant de skuld jouwe

Kontrolearje earst de doalkaart, want gjin stjoerder kin in kaart wekker meitsje dy't net wapene is. It kommando hjirûnder lêst de stipe en aktuele wake-modi, wêrby't in aktuele wearde fan g betsjut dat magic packet oan stiet:

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

Run de opname op de helper wylst it stjoeren bart, en lês him yn stee fan sukses oan te nimmen. In frame dat de goede bridge mei de broadcast-bestimmings-MAC ferlit, is it iennige bewiis dat it stjoeren wurke; is de opname leech, dan hat de stjoerder in oare interface keazen en is de rest fan 'e test sinleas. In stjoerder dy't in rûch frame bout yn stee fan in UDP-datagram, past net by dat filter, dus kontrolearje hokker foarm jo ark brûkt foardat jo konkludearje dat der neat stjoerd is.

Op Windows is de lykweardige kaartkontrôle powercfg /devicequery wake_armed, dy't de apparaten listet dy't it systeem wekker meitsje meie. In netwurkadapter dy't yn dy list ûntbrekt, negearret elk pakket dat derhinne stjoerd wurdt, hoe korrekt it frame op 'e tried der ek útsjocht.

Befêstigje dan it wekker wurden sels en de neisoarch. In masine dy't oangiet mar by namme ûnberikber bliuwt, hat in statysk adres en in DNS-record nedich, want broadcast-nammresolúsje sil de tunnel noch altyd net oerkruise. Draadloas wekker meitsje is in aparte en folle minder betroubere mooglikheid as de bedrade ferzje, dus test it op itselde segmint foardat de VPN der hielendal oan te pas komt. Skriuw de interfacename en de helper-host yn it ticket, want de folgjende flater giet meastentiids oer deselde twa feiten.

Relatearre artikelen