¿Por qué Wake-on-LAN funciona localmente pero falla a través de una VPN doméstica?

Wake-on-LAN falla a través de una VPN cuando el paquete mágico nunca llega al segmento Ethernet local del dispositivo en reposo.

En una red doméstica, un teléfono o portátil conectado mediante WireGuard, OpenVPN, Tailscale u otro túnel puede acceder a servicios IP enrutados sin unirse automáticamente al dominio de broadcast de la LAN. Por lo tanto, el diagnóstico correcto es probar la ruta local de activación, capturar lo que envía el cliente VPN, identificar dónde se detiene la entrega del broadcast y luego elegir un método seguro de retransmisión local o asistido por router en lugar de abrir un puerto UDP no autenticado a internet.

Reconfirma la Ruta Local de Activación Antes de Probar la VPN

Despierta el objetivo desde otro dispositivo en la misma LAN Ethernet o Wi-Fi usando la dirección MAC exacta y el estado de energía que esperas usar remotamente. Prueba el modo de suspensión, hibernación y apagado por separado porque el soporte de hardware puede variar entre ellos.

Una guía práctica para laboratorios domésticos describe Wake-on-LAN como un paquete mágico broadcast que la interfaz apagada reconoce por la dirección MAC. El éxito local prueba que el firmware, la NIC, el cable y el estado de escucha de bajo consumo funcionan en ese segmento.

Registra la MAC del objetivo, VLAN, subred, estado de suspensión soportado y el retraso normal de activación. Si la activación local es inconsistente, primero corrige BIOS, controlador, gestión de energía, puerto del switch o alimentación en espera porque un relé VPN no puede reparar un objetivo que no escucha de forma fiable.

Verifica Si el Cliente VPN Envía al Destino Correcto

Conéctate a través de la VPN e inspecciona la dirección de destino, puerto UDP, interfaz y máscara de subred de la aplicación Wake-on-LAN. Muchas aplicaciones usan por defecto la dirección broadcast de la interfaz VPN actual del dispositivo en lugar de la dirección broadcast de la LAN remota.

Un tutorial específico para VPN señala que el paquete aún debe dirigirse hacia la dirección broadcast de la LAN remota y no solo al punto final del túnel. La carga MAC puede ser correcta mientras que el destino IP coloca el paquete en el lado equivocado del router.

Captura el tráfico en la puerta de enlace VPN y observa si el datagrama UDP llega. Si nunca aparece, corrige la ruta del cliente VPN o el destino de la aplicación; si llega como unicast a la IP antigua del host en reposo, continúa revisando el comportamiento ARP y del relé.

Encuentra el Límite de Capa 3 Que Bloquea el Broadcast

La mayoría de las VPN enrutan paquetes entre subredes, mientras que Wake-on-LAN normalmente se entrega como un broadcast de Capa 2 en el segmento de destino. Los routers comúnmente se niegan a reenviar broadcasts dirigidos porque el reenvío indiscriminado crea riesgos de seguridad y amplificación.

Una discusión en OPNsense resume la incompatibilidad principal: WoL es un broadcast de Capa 2 mientras que el firewall y el túnel operan en Capa 3. Por eso el ping normal, SMB y acceso al panel pueden funcionar a través de la VPN aunque el paquete de activación falle.

Captura en ambas interfaces, la VPN y la LAN doméstica. Si el paquete entra al firewall pero nunca sale por la LAN, no sigas cambiando el PC en reposo; elige un relé, función del router o dispositivo doméstico siempre activo que pueda originar el paquete localmente.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prueba un Relé Local en Lugar de Reenviar UDP Desde Internet

Ejecuta el comando de activación desde un dispositivo siempre encendido dentro de la LAN doméstica, como el router, un pequeño servidor, host de Home Assistant u otro NAS. Dispara ese comando local a través de la conexión VPN autenticada.

Las guías de reenvío de broadcast suelen ofrecer un relé WoL local porque el relé puede recibir una solicitud enrutada y crear el broadcast LAN requerido en la interfaz correcta.

Si el relé local despierta el dispositivo, mantén la VPN como límite de autenticación y expón solo la acción del relé a usuarios confiables. Evita el reenvío público de puertos a UDP 7 o 9 a menos que comprendas completamente el comportamiento de broadcast del router y el riesgo de abuso.

Revisa el Estado ARP Cuando la Activación Unicast Funciona Solo Temporalmente

Algunos routers pueden enviar un paquete mágico unicast a la última IP del objetivo mientras la MAC permanece en la tabla ARP o de vecinos. El método puede funcionar poco después del apagado y luego fallar cuando esa entrada expira.

Este comportamiento explica por qué una prueba de activación remota puede tener éxito inmediatamente después de que la máquina entra en reposo pero fallar horas después. El router conoce la MAC de destino solo mientras la entrada de vecino obsoleta está disponible; el host en reposo no puede responder a una nueva solicitud ARP.

Usa una entrada de vecino estática solo cuando el router lo soporte de forma segura y el NAS o PC mantenga una IP reservada estable. De lo contrario, prefiere un broadcast generado por un relé local para que el diseño no dependa de una caché que expira.

Verifica el Éxito de la Activación Separadamente de la Conectividad VPN

Un paquete mágico normalmente no devuelve un acuse de recibo. Después de enviarlo, verifica el estado de energía mediante el estado del enlace del switch, un registro del relé local, la lectura de un enchufe inteligente o un intento de conexión retrasado a un servicio que arranca tras el inicio.

La comparación de ZimaSpace entre rutas VPN y reenvío de puertos ayuda a separar el camino seguro de acceso remoto del mecanismo de broadcast que despierta la máquina.

La reparación está completa solo cuando el mismo cliente VPN puede activar un relé local, el objetivo se despierta desde el estado de bajo consumo previsto y el servicio esperado se vuelve accesible tras un retraso consistente. Si la máquina se despierta pero el servicio sigue inaccesible, soluciona problemas de red en el arranque, firewall, DNS o enrutamiento VPN como un problema separado.