Ĉu Wake-on-LAN tra VPN ne funkcias? La dissendo neniam transiras

Vi dormigas la oficejan maŝinon, kunvokas la VPN de hejme, kaj ĝi restas malŝaltita. La tunelo estas aktiva, dosieraj kunhavigoj respondas, kaj la wake-on-LAN-paĝo de la enkursigilo raportas, ke ĝi sendis la peton. Ĉiu videbla signo diras, ke la reto estas bona, kaj ĝuste tial ĉi tiu kazo konfuzas: la kadro, kiu vekus la maŝinon, neniam atingas la segmenton, kie ĝi troviĝas.

La simptomoj montras al la subreto, ne al la tunelo

Ping malsukcesas por la dormanta gastiganto, kaj tiu parto estas normala. Maŝino en standby ne havas funkciantan IP-stakon, do ĝi ne povas respondi al ARP aŭ ICMP, kaj neniu tunela agordo tion ŝanĝas. La utila testo estas, ĉu dua maŝino en la sama LAN vekiĝas, kaj ĉu la wake-paĝo de la enkursigilo mem funkcias por gastiganto konektita al ĝi.

Post kiam la testo en la sama segmento sukcesas, la fiasko temas pri atingo. La sendanto, kiun vi uzas, loĝas sur la VPN-interfaco, kaj la paketo, kiun ĝi konstruas, estas dissendo por la loka ligo, do ĝi eliras per la malĝusta interfaco aŭ tute ne. La tunelo ne estas rompita; ĝi portas la malĝustan specon de trafiko. Trovu, kiun interfacon la sendanto elektas, antaŭ ol ŝanĝi ununuran enkursigilan agordon.

Magic packet estas kadro, ne servo

La utilaĵo komenciĝas per fiksa kaplinio de ses bajtoj 0xFF, poste la aparatar-adreso de la cela karteto ripetita dek ses fojojn, poste laŭvola SecureOn-pasvorto de kvar bajtoj. Sendantoj kutime envolvas tion en UDP al pordo 7 aŭ pordo 9, sed la porda numero estas konvencio komuna inter sendanto kaj karteto, ne servanto, al kiu vi povas konektiĝi. Nenio aŭskultas, kaj nenio respondas.

Tio, kio vekas la maŝinon, estas la retinterfaco, kiu tenas malgrandan kvanton da cirkvitoj nutrataj el la standby-relo, dum la resto de la sistemo estas malŝaltita. Tial la agordo devas postvivi kaj plenan perdon de elektro kaj dormon: ĉeftabulo, kiu forigas la standby-nutradon ĉe malŝalto, ne plu havas karteton, kiu ion ricevu.

Kial enkursigita tunelo ne povas transdoni ĝin

Enkursigita VPN-interfaco estas punkto-al-punkto IP-ligo inter du tunelaj adresoj. Ĝi ekzistas por porti paketojn adresitajn al la kunulo, kaj tial ping, SSH kaj dosieraj kunhavigoj kondutas normale tra ĝi. Dissenda kadro ne estas adresita al tiu kunulo, kaj la limigita dissenda adreso neniam estas plusendata de enkursigilo kiel afero de kutimo.

Plusendi subretan dissendon estas intenca kapablo de la enkursigilo, kiun plej multaj defaŭltaj agordoj malŝaltas, kaj eĉ tiam ĝi liveras al tiu subreto, ne al specifa dormanta karteto. Dormanta gastiganto ankaŭ ne povas respondi al ARP, do enkursigilo, kiu provas solvi la celan adreson antaŭ plusendo, faligas la kadron dum ĝi atendas respondon, kiu neniam venos. Statika liga ero riparas tiun parton kaj lasas la dissendan atingoproblemon netuŝita. Du apartaj limigoj, do, kaj forigi unu faras nenion por la alia.

Tri lokigoj, kiuj efektive atingas la karteton

Ĉiu farebla aranĝo metas la kadron sur la segmenton de la celo, kaj ili diferencas laŭ tio, kiom ili perturbas la reton:

1. Metu ĉiam ŝaltitan aparaton sur la celan segmenton. Enkursigilo, NAS aŭ malgranda Linux-skatolo, kiu restas nutrata, povas elsendi la kadron loke, tuj kiam vi atingas ĝin tra la tunelo, kaj nenio pri la VPN ŝanĝiĝas.
2. Lasu la enkursigilon mem elsendi la kadron. Multaj firmvaroj proponas wake-paĝon, kiu sendas el la LAN-ponto, kaj tio funkcias tiel longe, kiel la celo sidas sur tiu ponto kaj ne malantaŭ dua enkursigilo.
3. Pontu la sidejojn per TAP-speca tunelo, kiam dissendoj vere devas transiri. Tio kunigas du dissendajn domajnojn, kun dissendaj ŝtormoj, unu adresa plano kaj ĉiu malkovra protokolo vidanta ambaŭ sidejojn samtempe.

La unua opcio estas la preferinda por unu maŝino. La tria estas reta dezajn-decizo kun daŭra kosto, do traktu ĝin kiel tian kaj ne kiel rapidan riparon por unu labortabla komputilo.

Notu, kiu helpanto elsendas la kadron kaj sur kiu ponto aŭ VLAN ĝi sidas. Helpanto, kiu elsendas sur la malĝusta interfaco, produktas perfektan kaptaĵon kaj maŝinon, kiu neniam vekiĝas, kaj tiu kombinaĵo kostas posttagmezon.

Kontrolu la sendon antaŭ ol kulpigi la klienton

Kontrolu unue la celan karteton, ĉar neniu sendanto povas veki karteton, kiu ne estas armigita. La suba komando legas la subtenatajn kaj aktualajn wake-reĝimojn, kie aktuala valoro de g signifas, ke magic packet estas ŝaltita:

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

Rulu la kaptaĵon sur la helpanto dum la sendo okazas, kaj legu ĝin anstataŭ supozi sukceson. Kadro, kiu forlasas la ĝustan ponton kun la dissenda cela MAC, estas la sola pruvo, ke la sendo funkciis; se la kaptaĵo estas malplena, la sendanto elektis alian interfacon kaj la resto de la testo estas sensignifa. Sendanto, kiu konstruas krudan kadron anstataŭ UDP-datagramo, ne kongruas kun tiu filtrilo, do kontrolu, kiun formon via ilo uzas, antaŭ ol konkludi, ke nenio estis sendita.

En Windows la ekvivalenta karteta kontrolo estas powercfg /devicequery wake_armed, kiu listigas la aparatojn rajtigitajn veki la sistemon. Reta adaptilo mankanta en tiu listo ignoros ĉiun paketon senditan al ĝi, kiel ajn ĝusta la kadro aspektas sur la drato.

Poste konfirmu la vekon mem kaj la sekvaĵon. Maŝino, kiu ŝaltiĝas sed restas neatingebla laŭ nomo, bezonas statikan adreson kaj DNS-eron, ĉar dissenda nomsolvado ankoraŭ ne transiras la tunelon. Sendrata veko estas aparta kaj multe malpli fidinda kapablo ol la drata versio, do testu ĝin sur la sama segmento antaŭ ol ĝenerale enmiksi la VPN-on. Skribu la interfacan nomon kaj la helpantan gastiganton en la tiketon, ĉar la sekva fiasko kutime temas pri la samaj du faktoj.