¿Wake-on-LAN por VPN no funciona? La difusión nunca cruza

Pones a dormir el equipo de la oficina, marcas el VPN desde casa, y sigue apagado. El túnel está levantado, los recursos compartidos responden, y la página wake-on-LAN del router informa de que envió la petición. Cada señal visible dice que la red está bien, y por eso mismo este caso desconcierta: la trama que despertaría la máquina nunca llega al segmento donde vive.

Los síntomas apuntan a la subred, no al túnel

El ping falla contra el host dormido, y esa parte es normal. Un equipo en suspensión no tiene pila IP en marcha, así que no puede responder a ARP ni a ICMP, y ninguna configuración del túnel cambia eso. La prueba útil es si se despierta un segundo equipo en la misma LAN, y si la página de wake del propio router funciona para un host conectado a él.

Cuando la prueba en el mismo segmento sale bien, el fallo es de alcance. El emisor que usas vive en la interfaz del VPN, y el paquete que construye es una difusión para el enlace local, así que sale por la interfaz equivocada o no sale. El túnel no está roto; está llevando el tipo equivocado de tráfico. Averigua qué interfaz elige el emisor antes de cambiar un solo ajuste del router.

Un magic packet es una trama, no un servicio

La carga útil empieza con una cabecera fija de seis bytes 0xFF, luego la dirección hardware de la tarjeta destino repetida dieciséis veces, luego una contraseña SecureOn opcional de cuatro bytes. Los emisores suelen envolverla en UDP hacia el puerto 7 o el puerto 9, pero el número de puerto es una convención compartida entre emisor y tarjeta, no un servicio escuchando al que conectarse. Nada escucha, y nada responde.

Lo que despierta a la máquina es la interfaz de red, que mantiene una pequeña cantidad de circuitería alimentada desde el rail de espera mientras el resto del sistema está apagado. Por eso el ajuste tiene que sobrevivir a un corte de corriente completo y también a la suspensión: una placa que corta la alimentación de espera al apagarse ya no tiene tarjeta que reciba nada.

Por qué un túnel enrutado no puede entregarlo

Una interfaz VPN enrutada es un enlace IP punto a punto entre dos direcciones de túnel. Existe para llevar paquetes dirigidos al par, y por eso ping, SSH y los recursos compartidos se comportan con normalidad a través de ella. Una trama de difusión no va dirigida a ese par, y la dirección de difusión limitada nunca se reenvía por rutina en un router.

Reenviar una difusión dirigida a una subred es una capacidad deliberada del router que la mayoría de las configuraciones por defecto desactivan, e incluso entonces entrega a esa subred y no a una tarjeta dormida concreta. Un host dormido tampoco puede responder a ARP, así que un router que intenta resolver la dirección destino antes de reenviar descarta la trama mientras espera una respuesta que nunca llegará. Una entrada de enlace estática arregla esa parte y deja intacto el problema de alcance de la difusión. Dos restricciones distintas, pues, y quitar una no hace nada por la otra.

Tres ubicaciones que sí llegan a la tarjeta

Toda disposición viable pone la trama en el segmento del destino, y difieren en cuánto perturban la red:

1. Pon un dispositivo siempre encendido en el segmento destino. Un router, un NAS o una pequeña caja Linux que siga alimentada puede emitir la trama localmente en cuanto la alcanzas por el túnel, y nada del VPN cambia.
2. Deja que el router emita la trama. Muchos firmwares ofrecen una página de wake que envía desde el puente LAN, lo que funciona mientras el destino esté en ese puente y no detrás de un segundo router.
3. Puentea los sitios con un túnel de tipo TAP cuando las difusiones tengan que cruzar de verdad. Eso fusiona dos dominios de difusión, con tormentas de difusión, un único plan de direccionamiento y cada protocolo de descubrimiento viendo ambos sitios a la vez.

La primera opción es la preferible para una sola máquina. La tercera es una decisión de diseño de red con coste permanente, así que trátala como tal y no como un arreglo rápido para un escritorio.

Anota qué ayudante emite la trama y en qué puente o VLAN está. Un ayudante que emite en la interfaz equivocada produce una captura perfecta y una máquina que nunca despierta, y esa combinación cuesta una tarde.

Verifica el envío antes de culpar al cliente

Comprueba primero la tarjeta destino, porque ningún emisor puede despertar una tarjeta que no está armada. El comando de abajo lee los modos de wake admitidos y el actual, donde un valor actual de g significa que el magic packet está activado:

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

Ejecuta la captura en el ayudante mientras ocurre el envío, y léela en vez de dar el éxito por hecho. Una trama que sale del puente correcto con la MAC de difusión es la única prueba de que el envío funcionó; si la captura está vacía, el emisor eligió otra interfaz y el resto de la prueba no significa nada. Un emisor que construye una trama cruda en lugar de un datagrama UDP no encaja en ese filtro, así que mira qué forma usa tu herramienta antes de concluir que no se envió nada.

En Windows la comprobación equivalente de la tarjeta es powercfg /devicequery wake_armed, que lista los dispositivos autorizados a despertar el sistema. Un adaptador de red que falte en esa lista ignorará cada paquete que se le envíe, por muy correcta que se vea la trama en el cable.

Luego confirma el propio despertar y el seguimiento. Un equipo que arranca pero sigue inalcanzable por nombre necesita una dirección estática y un registro DNS, porque la resolución de nombres por difusión tampoco cruza el túnel. El despertar inalámbrico es una capacidad aparte y mucho menos fiable que la versión por cable, así que pruébalo en el mismo segmento antes de meter el VPN en el asunto. Apunta en el ticket el nombre de la interfaz y el host del ayudante, porque el siguiente fallo suele ir de los mismos dos datos.