Wake-on-LAN prin VPN nu funcționează? Difuziunea nu trece niciodată

Pui mașina de la birou în repaus, formezi VPN-ul de acasă, și rămâne oprită. Tunelul este ridicat, partajările de fișiere răspund, iar pagina wake-on-LAN a routerului raportează că a trimis cererea. Fiecare semnal vizibil spune că rețeaua este în regulă, și exact de aceea acest caz încurcă: cadrul care ar trezi mașina nu ajunge niciodată în segmentul în care se află.

Simptomele arată spre subrețea, nu spre tunel

Pingul eșuează pentru gazda adormită, și acea parte este normală. O mașină în standby nu are un stivă IP activă, deci nu poate răspunde la ARP sau ICMP, iar nicio configurație de tunel nu schimbă asta. Testul util este dacă se trezește o a doua mașină din aceeași LAN, și dacă pagina de wake a routerului funcționează pentru o gazdă conectată la el.

Odată ce testul din același segment trece, defecțiunea ține de anvergură. Emițătorul pe care îl folosești trăiește pe interfața VPN, iar pachetul pe care îl construiește este o difuziune pentru legătura locală, așa că iese pe interfața greșită sau deloc. Tunelul nu este stricat; transportă tipul greșit de trafic. Află ce interfață alege emițătorul înainte de a schimba o singură setare a routerului.

Un magic packet este un cadru, nu un serviciu

Sarcina utilă începe cu un antet fix de șase octeți 0xFF, apoi adresa de hardware a plăcii țintă repetată de șaisprezece ori, apoi o parolă SecureOn opțională de patru octeți. Emițătorii o împachetează de obicei în UDP către portul 7 sau portul 9, dar numărul de port este o convenție partajată între emițător și placă, nu un serviciu în ascultare la care te poți conecta. Nimic nu ascultă și nimic nu răspunde.

Ce trezește mașina este interfața de rețea, care ține o mică parte din circuite alimentată din șina de standby în timp ce restul sistemului este oprit. De aceea setarea trebuie să supraviețuiască atât unei căderi totale de curent, cât și repausului: o placă de bază care taie alimentarea de standby la oprire nu mai are nicio placă care să primească ceva.

De ce un tunel rutat nu îl poate livra

O interfață VPN rutată este o legătură IP punct-la-punct între două adrese de tunel. Ea există pentru a transporta pachete adresate partenerului, motiv pentru care ping, SSH și partajările de fișiere se comportă normal prin ea. Un cadru de difuziune nu este adresat acelui partener, iar adresa de difuziune limitată nu este niciodată redirecționată din oficiu de un router.

Redirecționarea unei difuziuni orientate spre subrețea este o capacitate deliberată a routerului pe care majoritatea configurațiilor implicite o dezactivează, și chiar și atunci livrează către acea subrețea, nu către o anumită placă adormită. O gazdă adormită nu poate răspunde nici la ARP, așa că un router care încearcă să rezolve adresa țintă înainte de redirecționare aruncă cadrul în timp ce așteaptă un răspuns care nu va veni niciodată. O intrare de legare statică rezolvă acea parte și lasă neatinsă problema de anvergură a difuziunii. Două restricții separate, așadar, iar înlăturarea uneia nu face nimic pentru cealaltă.

Trei plasări care ajung chiar la placă

Orice aranjament viabil pune cadrul în segmentul țintei, iar ele diferă prin cât de mult deranjează rețeaua:

1. Pune un dispozitiv mereu pornit în segmentul țintă. Un router, un NAS sau o cutie Linux mică ce rămâne alimentată poate emite cadrul local de îndată ce ajungi la ea prin tunel, iar nimic din VPN nu se schimbă.
2. Lasă routerul să emită cadrul el însuși. Multe firmware-uri oferă o pagină de wake care trimite din puntea LAN, ceea ce funcționează atâta timp cât ținta stă pe acea punte și nu în spatele unui al doilea router.
3. Puntează amplasamentele cu un tunel de tip TAP atunci când difuziunile chiar trebuie să traverseze. Asta unește două domenii de difuziune, cu furtuni de difuziune, un singur plan de adresare și fiecare protocol de descoperire văzând ambele amplasamente deodată.

Prima opțiune este cea de preferat pentru o singură mașină. A treia este o decizie de proiectare a rețelei cu cost permanent, așa că tratați-o ca atare și nu ca pe o reparație rapidă pentru un singur desktop.

Notează ce ajutor emite cadrul și pe ce punte sau VLAN stă. Un ajutor care emite pe interfața greșită produce o captură perfectă și o mașină care nu se trezește niciodată, iar combinația aceea costă o după-amiază.

Verifică trimiterea înainte de a da vina pe client

Verifică mai întâi placa țintă, fiindcă niciun emițător nu poate trezi o placă ce nu este armată. Comanda de mai jos citește modurile de wake acceptate și pe cel curent, unde o valoare curentă de g înseamnă că magic packet este activat:

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

Rulează captura pe ajutor în timp ce are loc trimiterea, și citește-o în loc să presupui succesul. Un cadru care părăsește puntea corectă cu MAC-ul de difuziune este singura dovadă că trimiterea a funcționat; dacă captura este goală, emițătorul a ales altă interfață, iar restul testului nu înseamnă nimic. Un emițător care construiește un cadru brut în loc de un datagramă UDP nu se potrivește cu filtrul acela, așa că verifică ce formă folosește unealta ta înainte de a concluziona că nu s-a trimis nimic.

În Windows, verificarea echivalentă a plăcii este powercfg /devicequery wake_armed, care listează dispozitivele permise să trezească sistemul. Un adaptor de rețea absent din listă va ignora fiecare pachet trimis către el, oricât de corect ar arăta cadrul pe cablu.

Apoi confirmă trezirea în sine și continuarea. O mașină care pornește dar rămâne inaccesibilă după nume are nevoie de o adresă statică și de o înregistrare DNS, fiindcă rezolvarea numelor prin difuziune tot nu traversează tunelul. Trezirea wireless este o capacitate separată și mult mai puțin fiabilă decât versiunea cu cablu, așa că testeaz-o în același segment înainte de a implica VPN-ul. Notează numele interfeței și gazda ajutorului în tichet, fiindcă următoarea defecțiune implică de obicei aceleași două fapte.