Wake-on-LAN parece una función sencilla. Mandas un paquete mágico, la tarjeta de red lo escucha, la placa despierta y el servidor arranca. Fin.
Eso es verdad en la misma medida en que “hacer backups” es copiar una carpeta. Técnicamente sí. En la práctica, en cuanto lo metes en un homelab real, aparecen los matices que no salen en la guía rápida.
Yo ya publiqué una guía básica de Wake-on-LAN para encender un servidor remoto. Esa parte sigue siendo válida: BIOS, tarjeta de red, ethtool, MAC y paquete mágico. Pero el uso interesante empieza después. El punto no es despertar una máquina desde el sofá una vez. El punto es integrar WoL en una arquitectura donde algunos nodos duermen, otros quedan siempre encendidos, Home Assistant puede actuar como mando doméstico y Tailscale permite entrar desde fuera sin abrir puertos absurdos.
Ahí Wake-on-LAN deja de ser un truco y se convierte en una pieza de diseño.
Para qué lo uso de verdad#
En casa no todos los equipos tienen que estar encendidos todo el día. Hay servicios que uso a diario y no quiero que dependan de encender nada. DNS, VPN, Home Assistant, monitorización básica, backups programados y alguna pieza de almacenamiento entran en esa categoría. Si eso cae, molesta.
Luego están las máquinas de laboratorio. Mini PCs para pruebas, nodos de Kubernetes que no necesito siempre, servidores con más consumo, equipos para transcodificación puntual, VMs pesadas que solo levanto cuando voy a tocar algo. Esas máquinas pueden dormir.
Wake-on-LAN encaja justo ahí. Me permite apagar capacidad que no necesito sin convertir cada arranque en una visita al cuarto de servidores. No es alta disponibilidad. No es magia. Es comodidad operativa con ahorro pequeño, pero constante.
El ahorro depende muchísimo del hardware. Un mini PC moderno puede bajar de 6 a 12 W en reposo, así que apagarlo quizá no cambia la factura de forma dramática. Un servidor más grande, un NAS secundario o una máquina con varios discos sí puede notarse más. Para mí la decisión no es solo electricidad. También es calor, ruido, desgaste y orden mental. Si algo no aporta nada durante 20 horas al día, prefiero que esté apagado.
La trampa es apagar demasiado. Si para consultar una foto, abrir un documento o encender una luz tengo que despertar media infraestructura, el diseño es malo. WoL sirve para laboratorio y cargas no urgentes. No debería ser el cimiento de servicios familiares críticos.
El diseño que me parece sensato#
Mi esquema ideal tiene tres capas.
La primera capa está siempre encendida. Aquí pondría router, switch, DNS básico, Home Assistant si controla cosas reales, un nodo pequeño para Tailscale y quizá un NAS principal si hay servicios que lo necesitan. Esta capa tiene que sobrevivir a mi entusiasmo nocturno. No vive en el nodo donde pruebo cosas raras.
La segunda capa duerme y despierta bajo demanda. Aquí entran nodos de cálculo, laboratorio, máquinas de pruebas, servidores de backups secundarios o equipos que solo necesito para tareas concretas. Tienen WoL bien configurado y una IP reservada por DHCP para no jugar a adivinar quién es quién.
La tercera capa son las automatizaciones que piden el arranque. Puede ser Home Assistant, un pequeño script, un botón en el móvil, una tarea desde otro servidor o incluso un flujo de automatización. La clave es que esta capa no dependa de la máquina que quiere despertar. Parece obvio, pero es el típico error que uno comete cuando va rápido.
Si el único sitio desde el que puedes mandar el paquete mágico es el servidor que está apagado, enhorabuena, has inventado una puerta con el pomo por dentro.
Tailscale cambia el problema, no el paquete#
Wake-on-LAN no viaja por internet como una petición HTTPS normal. El paquete mágico suele ser broadcast en la red local o un paquete UDP dirigido de forma muy concreta. Muchos routers lo bloquean, muchas VPN no reenvían broadcast y cruzar subredes puede ser una pequeña fiesta.
Por eso Tailscale no “hace WoL” por sí solo. Lo que hace es darte acceso seguro a un equipo dentro de casa que sí puede mandar el paquete en la LAN correcta.
El patrón que más me gusta es este:
- Dejo un nodo pequeño siempre encendido.
- Ese nodo está en Tailscale.
- Desde fuera me conecto a ese nodo o llamo a un servicio pequeño en ese nodo.
- El nodo envía el paquete WoL dentro de la red local.
- El servidor grande despierta.
Así no abro puertos en el router, no intento hacer broadcast desde internet y no convierto WoL en una exposición rara. Tailscale sirve como camino de administración. El magic packet se queda donde pertenece: dentro de casa.
También puedes usar un subnet router si quieres entrar a una red interna desde fuera. Eso ayuda para administrar, pero no siempre basta para WoL. Depende de cómo esté hecha la red, de si el paquete llega a la VLAN adecuada y de cómo responde el switch. Para despertar máquinas, prefiero que el emisor esté físicamente o lógicamente dentro de la misma red que el equipo dormido.
Mi recomendación: no diseñes WoL remoto como “mando un paquete desde cualquier sitio del mundo”. Diséñalo como “entro de forma segura en casa y un equipo de casa despierta al otro”. Es menos épico y funciona mejor.
Home Assistant como mando cómodo#
Home Assistant es un candidato muy natural para integrar Wake-on-LAN. Está siempre encendido en muchas casas, tiene una interfaz cómoda, permite botones, automatizaciones y escenas, y evita que tengas que acordarte de una MAC a las once de la noche.
La integración básica de Wake-on-LAN en Home Assistant permite crear switches para equipos. Pulsas un interruptor y Home Assistant manda el paquete. Eso ya es útil.
Pero yo no lo dejaría solo como “botón de encender”. Añadiría contexto.
Por ejemplo, un botón para despertar el servidor de laboratorio puede:
- Enviar el paquete WoL.
- Esperar unos segundos.
- Comprobar si responde por ping.
- Avisar si no ha arrancado.
- Mostrar el estado como disponible o apagado.
Esto evita el típico gesto de pulsar tres veces porque no sabes si hizo algo. También convierte un fallo silencioso en algo diagnosticable. Si Home Assistant manda el paquete pero la máquina no responde, ya sabes que el problema está en BIOS, NIC, corriente, switch, VLAN o sistema operativo. Si Home Assistant ni siquiera puede mandar el paquete, el problema está antes.
El detalle importante: Home Assistant no debería depender del servidor que despierta. Si Home Assistant vive en el mismo nodo que apagas para ahorrar, la idea se cae sola. Para domótica y mandos de casa, prefiero una VM o equipo estable que no participe en el laboratorio más agresivo.
VLANs y el punto donde WoL se vuelve antipático#
Wake-on-LAN dentro de una LAN plana suele ser fácil. En cuanto metes VLANs, switches gestionables, firewalls y redes separadas, cambia el tono.
El paquete mágico puede mandarse como broadcast a la red donde está el equipo o como unicast a una dirección concreta. El problema es que un equipo apagado no siempre conserva una entrada ARP útil, y muchos routers no reenvían broadcast entre redes. Eso está bien desde el punto de vista de seguridad. Desde el punto de vista de “quiero encender el cacharro”, molesta.
Hay varias formas de resolverlo.
La más simple es poner el emisor de WoL en la misma VLAN que los equipos que quieres despertar. Si tienes un mini servidor siempre encendido en esa red, se acabó el drama.
Otra opción es permitir directed broadcast de forma controlada en el router o firewall. No me encanta como primera opción porque depende mucho del equipo de red y abre una puerta que conviene entender bien.
También puedes mantener una máquina pequeña por cada segmento importante. Suena excesivo, pero en homelabs con redes separadas puede ser más limpio que llenar el firewall de excepciones raras.
Lo que no haría es romper la segmentación de red solo para que WoL sea cómodo. Si separaste laboratorio, IoT y servicios domésticos por una razón, no metas un agujero enorme porque te da pereza dejar un emisor dentro de cada zona.
Lo que reviso cuando no despierta#
Cuando WoL falla, casi siempre cae en una de estas categorías.
Primero, BIOS o firmware. Algunas placas tienen varias opciones relacionadas: Wake-on-LAN, wake from PCIe, power on by LAN, ErP, deep sleep y estados S3 o S5. Si ErP está activo, puede cortar la energía mínima que necesita la tarjeta de red. Si el equipo está apagado de verdad o la fuente corta corriente, tampoco hay milagro.
Segundo, sistema operativo. En Linux revisaría si la interfaz conserva Wake-on: g tras reiniciar. En Windows miraría las opciones de energía del adaptador, el inicio rápido y el permiso de “Wake on Magic Packet”. Windows puede ser especialmente creativo aquí.
Tercero, cable y switch. WoL por WiFi suele ser mala idea. Quiero ethernet. También quiero ver actividad en el puerto del switch cuando la máquina está apagada. Si el puerto queda completamente muerto, la tarjeta quizá no está alimentada.
Cuarto, MAC equivocada. Parece tonto. Pasa. Equipos con varias NICs, adaptadores USB, bridges, VMs y documentación vieja son una receta perfecta para mandar el paquete al sitio equivocado.
Quinto, red equivocada. Si mandas broadcast a una subred donde no está el equipo, no va a pasar nada. Si estás en Tailscale y esperas que el broadcast cruce como si fuese una LAN tradicional, probablemente tampoco.
Sexto, expectativas raras. WoL despierta una máquina. No garantiza que Proxmox, Docker, servicios, discos externos y dependencias estén listos al mismo segundo. Para automatizaciones reales conviene separar “he mandado el arranque” de “el servicio ya está disponible”.
Mi prueba mínima es aburrida, que suele ser buena señal. Desde una máquina en la misma red, mando el paquete. Si funciona, subo un nivel y lo intento desde Home Assistant. Si funciona, lo pruebo desde fuera usando Tailscale como camino hasta el emisor local. Si algo falla, sé exactamente en qué tramo se rompió.
No todo debe poder encenderlo cualquiera#
WoL no tiene autenticación. El paquete mágico no pregunta quién eres. Si alguien puede mandar paquetes en la red adecuada y conoce la MAC, puede intentar despertar la máquina. En casa esto no suele ser un drama enorme, pero conviene no tratarlo como si fuese una API segura.
Por eso no publicaría un endpoint de WoL a internet sin una capa seria delante. Si quiero un botón remoto, que esté detrás de Tailscale, detrás de Home Assistant con usuario, o detrás de una automatización autenticada. Nada de “curl público que despierta mi servidor”.
También separaría permisos en Home Assistant. Un botón para encender el servidor de laboratorio no tiene por qué estar en el panel familiar. Si alguien en casa necesita despertar un NAS de fotos, quizá sí. Si es un nodo de pruebas, mejor que no.
La seguridad aquí es simple: el mando para encender infraestructura debería estar tan protegido como cualquier otro mando de administración. Que el riesgo parezca menor no significa que tenga que estar tirado.
Automatizar apagado y encendido sin hacerse trampas#
La tentación después de montar WoL es automatizarlo todo. Si hay demanda, enciendo. Si no hay demanda, apago. Suena precioso hasta que un servicio tarda en arrancar, un usuario entra justo durante el apagado o una tarea de backup se queda a medias.
Yo automatizaría el encendido con más alegría que el apagado.
Encender bajo demanda suele ser poco peligroso. Como mucho, tarda o falla. Apagar de forma automática puede cortar procesos, romper expectativas o dejar un trabajo sin terminar. Para apagar, prefiero condiciones claras: sin usuarios, sin tareas en marcha, fuera de horario, backup terminado y aviso si algo no cuadra.
En un homelab pequeño, muchas veces basta con un botón de “modo laboratorio”. Lo pulsas y despierta nodos, espera a que estén disponibles y quizá arranca unas VMs. Luego otro botón o una rutina manual los apaga cuando terminas. No todo necesita ser autónomo. A veces la mejor automatización es reducir cinco pasos a uno, no eliminar el criterio humano.
Cuándo no usaría Wake-on-LAN#
No usaría WoL para servicios que la familia espera que estén siempre disponibles. Fotos principales, domótica, DNS, internet, documentos importantes o cualquier cosa que alguien no técnico vaya a usar sin avisar. Si tiene que estar, que esté.
No lo usaría para equipos con hardware que no despierta de forma fiable. Hay placas que prometen WoL y luego fallan según el estado de apagado, el adaptador o la versión de BIOS. Si tengo que cruzar los dedos, no lo meto en una rutina importante.
No lo usaría para ahorrar cantidades ridículas a costa de complejidad. Si un equipo consume 7 W y apagarlo me obliga a montar media arquitectura, igual estoy optimizando por deporte. Ya bastante deporte hacemos peleando con DNS.
Y no lo usaría como sustituto de una política clara de servicios. Si algo no se usa nunca, quizá no necesita WoL. Quizá necesita desaparecer.
Mi configuración ideal#
Para un homelab doméstico con varios equipos, me gusta esta configuración:
- Un nodo pequeño siempre encendido.
- Tailscale en ese nodo para acceso remoto.
- Home Assistant o un panel interno como mando cómodo.
- Reservas DHCP para todos los equipos que puedan dormir.
- MACs documentadas con nombre humano.
- Emisor WoL dentro de la red correcta.
- Comprobación de estado después de enviar el paquete.
- Botones separados para familia y administración.
- Apagado más conservador que encendido.
Con eso WoL deja de ser una colección de comandos y empieza a ser una función útil del homelab.
Mi conclusión#
Wake-on-LAN merece la pena cuando lo tratas como parte de la arquitectura, no como un truco aislado. En la misma LAN es fácil. Desde fuera de casa, con VLANs, Tailscale y automatizaciones, hay que pensar un poco más.
Mi patrón favorito es mantener un nodo pequeño siempre encendido, entrar por Tailscale y mandar el paquete desde dentro de la red local. Home Assistant puede ponerle una interfaz cómoda y añadir comprobaciones para que no sea un botón ciego. Las VLANs se respetan, los permisos se limitan y los servicios críticos no dependen de que alguien despierte un servidor a tiempo.
Eso es lo que diferencia un homelab cómodo de una maqueta preciosa que solo funciona cuando estás delante.
Wake-on-LAN no debería hacer que tu casa parezca más complicada. Debería permitirte apagar lo que sobra y encenderlo cuando toca, sin levantarte, sin abrir puertos y sin convertir cada arranque en una pequeña sesión de espiritismo de red.