Wake-on-LAN en Proxmox: cómo verificar el soporte y configurar de forma persistente

En entornos de laboratorio, homelab o incluso en infraestructura de producción con políticas de ahorro de energía, el Wake-on-LAN (WoL) es una función simple, pero a menudo mal configurada o mal entendida. En este artículo, cubriremos el proceso completo: cómo verificar si su NIC realmente soporta WoL, cómo habilitarlo, cómo persistir la configuración después de reiniciar en Debian/Proxmox, y los detalles de hardware que suelen causar dolores de cabeza, especialmente en placas genéricas.

Qué es Wake-on-LAN, en la práctica

Wake-on-LAN es un mecanismo que permite encender una máquina remotamente mediante el envío de un paquete especial por la red, llamado magic packet. Este paquete es bastante simple en su estructura: 6 bytes FF seguidos de la dirección MAC de destino repetida 16 veces.

El punto importante es que, cuando la máquina está apagada, no tiene una pila de red activa — sin IP, sin ARP, sin enrutamiento. Lo único "vivo" es la tarjeta de red, que mantiene una pequeña cantidad de energía auxiliar (standby power) precisamente para escuchar el tráfico bruto de capa 2 (Ethernet) en busca de ese patrón de bytes. Al reconocer el patrón con el MAC correspondiente, la NIC le indica a la placa base que inicie el arranque.

Esto explica por qué el comando de encendido utiliza la dirección de broadcast de la red (ej: 192.168.11.255) en lugar de la IP de la máquina de destino: sin una pila de red activa, no hay forma de direccionar la máquina mediante unicast/ARP. El broadcast garantiza que la trama llegue físicamente a todos los puertos del dominio de broadcast, y solo la NIC con el MAC correcto (y WoL habilitado) reacciona. Para las demás máquinas encendidas, el paquete simplemente se descarta — no representa ningún riesgo ni efecto secundario.

Paso 1: Verificar el soporte real en la NIC

Un error común es intentar identificar el soporte de WoL mediante dmidecode -t system, mirando el campo Wake-up Type. Este campo no indica la capacidad de WoL — solo muestra lo que causó el último arranque de la máquina (interruptor de encendido, PCI, etc). La fuente correcta de verdad es ethtool, directamente en la interfaz de red.

ip a                          # identificar a interface, ex: eth0
ethtool eth0 | grep Wake-on

Salida esperada:

Supports Wake-on: pumbg
Wake-on: d

Cada letra en Supports Wake-on representa un modo soportado por la NIC/driver:

Si la letra g no aparece en Supports Wake-on, deténgase aquí: la combinación NIC + driver no soporta magic packet, y no hay configuración de software que lo resuelva.

Paso 2: Habilitar el WoL

Con el soporte confirmado, habilítelo temporalmente:

ethtool -s eth0 wol g
ethtool eth0 | grep Wake-on   # deve mostrar "Wake-on: g"

Este cambio no sobrevive a un reinicio por defecto — es necesario persistirlo de dos formas complementarias.

Paso 3: Persistir la configuración

Mediante /etc/network/interfaces (ifupdown2)

En Proxmox, la interfaz de red generalmente se gestiona mediante /etc/network/interfaces, incluso cuando el archivo incluye la advertencia de "autogenerated". Esta advertencia se refiere a no mover interfaces gestionadas por PVE a archivos externos mediante source-directory — editar directamente el bloque de la interfaz física es seguro y es la forma recomendada.

Localice el bloque de su interfaz física (no el bridge vmbrX — el WoL debe aplicarse en la interfaz física real):

auto eth0
iface eth0 inet manual

Y agregue la directiva post-up, respetando la indentación con tabulación (no espacios) para mantener la consistencia con el resto del archivo:

auto eth0
iface eth0 inet manual
	post-up /usr/sbin/ethtool -s eth0 wol g

Aplique sin tumbar la red activa:

ifreload -a

Mediante regla udev (capa de redundancia)

Como refuerzo — cubriendo escenarios en los que el módulo de red se levanta antes de que ifupdown2 procese las directivas —, cree también una regla udev:

cat > /etc/udev/rules.d/50-wol.rules <<'EOF'
ACTION=="add", SUBSYSTEM=="net", NAME=="eth0", RUN+="/usr/sbin/ethtool -s eth0 wol g"
EOF

Ajuste NAME== al nombre real de su interfaz y confirme la ruta de ethtool con which ethtool (en Debian 13/trixie, con usr-merge, /sbin es solo un enlace simbólico a /usr/sbin, por lo que ambos funcionan, pero es bueno usar la ruta absoluta real).

Paso 4: Validar la persistencia

Reinicie la máquina:

reboot

Después del arranque, sin ejecutar nada manualmente, compruebe:

ethtool eth0 | grep Wake-on

Si aparece Wake-on: g solo, la persistencia está funcionando correctamente.

Paso 5: Configuración en BIOS/UEFI

Este es el punto que más genera confusión, especialmente en placas OEM genéricas (los kits de placas chinas con chipsets Intel reacondicionados son un ejemplo común). Incluso con el sistema operativo configurado correctamente, el WoL puede simplemente no funcionar si la BIOS no coopera. Verifique:

• Power On by PCI-E/PCI: debe estar habilitado.

• ErP/EuP Ready: si está habilitado, generalmente desactiva el WoL, ya que corta la energía de standby de la NIC para reducir el consumo en modo apagado. Desactive esta opción.

• Soporte de S3 vs S5: algunas placas más simples solo mantienen suficiente energía auxiliar para WoL saliendo de suspensión (S3), no de apagado total (S5). Esto es una limitación de hardware, no de configuración — vale la pena probar ambos escenarios para entender el comportamiento real de su placa.

Paso 6: Probar el disparo

Desde otra máquina en la misma red:

apt install wakeonlan
wakeonlan -i 192.168.11.255 AA:BB:CC:DD:EE:FF

Reemplace la IP de broadcast por su rango de red y el MAC por la dirección real de la interfaz (cat /sys/class/net/eth0/address).

Apague la máquina completamente antes de la prueba:

shutdown -h now

Atención: en algunas versiones recientes de systemd, es posible que el comando devuelva un error relacionado con D-Bus (Refusing activation, D-Bus is shutting down) incluso con el apagado ya en curso — se trata de una condición de carrera entre el comando y systemd-logind que cierra el bus D-Bus durante el propio proceso de apagado. Si esto ocurre, no ejecute nuevos comandos: verifique mediante ping desde otra máquina si el host realmente se apagó antes de asumir que algo falló.

Trampas frecuentes

• Bridge/bond en Proxmox: si la interfaz física está detrás de una vmbrX, el WoL debe configurarse en la interfaz física (eth0), no en el bridge. El bridge no interfiere en la captura del magic packet, que ocurre a nivel de hardware de la NIC.

• NICs Realtek genéricas: tienen un soporte de WoL inconsistente entre variantes del mismo chip. Incluso con el driver reportando pumbg, algunas placas simplemente no tienen la pista de alimentación auxiliar (VCC standby) enrutada correctamente hasta el chip — en ese caso, es una limitación física, sin solución por software.

• Switch con port security agresivo: algunos switches gestionados desactivan puertos sin enlace activo constante, lo que puede impedir que el magic packet llegue. Confirme que el switch mantiene el puerto activo incluso con el host apagado.

• WoL entre VLANs/subredes diferentes: el broadcast utilizado en WoL no atraviesa enrutadores por defecto. Para encender una máquina en otra subred, es necesario soporte de directed broadcast en el enrutador, o algún host en la misma red física actuando como proxy del paquete.

Conclusión

Wake-on-LAN es una función simple de configurar, pero con múltiples capas que deben estar alineadas: soporte del driver/NIC, persistencia de la configuración en el SO, cooperación de la BIOS/UEFI, y comportamiento correcto del switch de red. Probando cada capa de forma aislada — comenzando por ethtool, luego la persistencia, luego la BIOS — resulta mucho más sencillo aislar dónde está el problema cuando el WoL "no funciona".