Wake-on-LAN per VPN no funciona? La difusió no travessa mai

Poses a dormir l'equip de l'oficina, marques el VPN des de casa, i continua apagat. El túnel està aixecat, els recursos compartits responen, i la pàgina wake-on-LAN del router informa que ha enviat la petició. Cada senyal visible diu que la xarxa va bé, i justament per això aquest cas desconcerta: la trama que despertaria la màquina no arriba mai al segment on viu.

Els símptomes apunten a la subxarxa, no al túnel

El ping falla contra l'amfitrió adormit, i aquesta part és normal. Una màquina en suspensió no té pila IP en marxa, així que no pot respondre a ARP ni a ICMP, i cap configuració del túnel no ho canvia. La prova útil és si es desperta un segon equip a la mateixa LAN, i si la pàgina de wake del mateix router funciona per a un amfitrió connectat a ell.

Quan la prova al mateix segment surt bé, la fallada és d'abast. L'emissor que uses viu a la interfície del VPN, i el paquet que construeix és una difusió per a l'enllaç local, així que surt per la interfície equivocada o no surt. El túnel no està trencat; està portant el tipus equivocat de tràfic. Esbrina quina interfície tria l'emissor abans de canviar un sol ajust del router.

Un magic packet és una trama, no un servei

La càrrega útil comença amb una capçalera fixa de sis bytes 0xFF, després l'adreça de maquinari de la targeta de destí repetida setze vegades, després una contrasenya SecureOn opcional de quatre bytes. Els emissors solen embolcallar-ho en UDP cap al port 7 o el port 9, però el número de port és una convenció compartida entre emissor i targeta, no un servei a l'escolta al qual connectar-se. No hi ha res escoltant, i res no respon.

El que desperta la màquina és la interfície de xarxa, que manté una petita quantitat de circuits alimentats des del rail d'espera mentre la resta del sistema està apagat. Per això l'ajust ha de sobreviure tant a un tall de corrent complet com a la suspensió: una placa que talla l'alimentació d'espera en apagar-se ja no té targeta per rebre res.

Per què un túnel encaminat no ho pot lliurar

Una interfície VPN encaminada és un enllaç IP punt a punt entre dues adreces de túnel. Existeix per portar paquets adreçats al par, i per això ping, SSH i els recursos compartits es comporten amb normalitat a través seu. Una trama de difusió no va adreçada a aquest par, i l'adreça de difusió limitada no es reenvia mai d'ofici en un router.

Reenviar una difusió dirigida a una subxarxa és una capacitat deliberada del router que la majoria de configuracions per defecte desactiven, i fins i tot llavors lliura a aquesta subxarxa i no a una targeta adormida concreta. Un amfitrió adormit tampoc no pot respondre a ARP, així que un router que intenta resoldre l'adreça de destí abans de reenviar descarta la trama mentre espera una resposta que no arribarà mai. Una entrada d'enllaç estàtica arregla aquesta part i deixa intacte el problema d'abast de la difusió. Dues restriccions diferents, doncs, i treure'n una no fa res per l'altra.

Tres ubicacions que sí que arriben a la targeta

Qualsevol disposició viable posa la trama al segment del destí, i es diferencien en quant pertorben la xarxa:

1. Posa un dispositiu sempre encès al segment de destí. Un router, un NAS o una petita caixa Linux que es mantingui alimentada pot emetre la trama localment tan bon punt l'atans pel túnel, i res del VPN no canvia.
2. Deixa que el router emeti la trama ell mateix. Molts firmwares ofereixen una pàgina de wake que envia des del pont LAN, cosa que funciona mentre el destí sigui en aquest pont i no darrere d'un segon router.
3. Ponteja els llocs amb un túnel de tipus TAP quan les difusions hagin de travessar de debò. Això fusiona dos dominis de difusió, amb tempestes de difusió, un únic pla d'adreçament i cada protocol de descobriment veient tots dos llocs alhora.

La primera opció és la preferible per a una sola màquina. La tercera és una decisió de disseny de xarxa amb cost permanent, així que tracta-la com a tal i no com una solució ràpida per a un sol escriptori.

Anota quin auxiliar emet la trama i en quin pont o VLAN és. Un auxiliar que emet a la interfície equivocada produeix una captura perfecta i una màquina que no es desperta mai, i aquesta combinació costa una tarda.

Verifica l'enviament abans de culpar el client

Comprova primer la targeta de destí, perquè cap emissor no pot despertar una targeta que no està armada. L'ordre de sota llegeix els modes de wake admesos i l'actual, on un valor actual de g significa que el magic packet està 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

Executa la captura a l'auxiliar mentre passa l'enviament, i llegeix-la en lloc de donar l'èxit per fet. Una trama que surt del pont correcte amb la MAC de difusió és l'única prova que l'enviament ha funcionat; si la captura és buida, l'emissor ha triat una altra interfície i la resta de la prova no vol dir res. Un emissor que construeix una trama crua en lloc d'un datagrama UDP no encaixa en aquest filtre, així que mira quina forma fa servir la teva eina abans de concloure que no s'ha enviat res.

A Windows la comprovació equivalent de la targeta és powercfg /devicequery wake_armed, que llista els dispositius autoritzats a despertar el sistema. Un adaptador de xarxa que falti en aquesta llista ignorarà cada paquet que se li enviï, per correcta que sembli la trama al cable.

Després confirma el despertar mateix i el seguiment. Una màquina que arrenca però continua inabastable pel nom necessita una adreça estàtica i un registre DNS, perquè la resolució de noms per difusió continua sense travessar el túnel. El despertar sense fil és una capacitat a part i molt menys fiable que la versió per cable, així que prova-la al mateix segment abans de ficar-hi el VPN. Escriu el nom de la interfície i l'amfitrió de l'auxiliar a l'incident, perquè la fallada següent sol anar dels mateixos dos fets.