Wake-on-LAN no Proxmox: como verificar suporte e configurar de forma persistente

Em ambientes de laboratório, homelab ou até em infraestrutura de produção com política de economia de energia, o Wake-on-LAN (WoL) é um recurso simples, mas frequentemente mal configurado ou mal compreendido. Neste artigo, vamos cobrir o processo completo: como verificar se sua NIC realmente suporta WoL, como habilitar, como persistir a configuração após reboot no Debian/Proxmox, e os detalhes de hardware que costumam causar dor de cabeça — especialmente em placas genéricas.

O que é o Wake-on-LAN, na prática

Wake-on-LAN é um mecanismo que permite ligar uma máquina remotamente através do envio de um pacote especial pela rede, chamado magic packet. Esse pacote é bem simples na estrutura: 6 bytes FF seguidos do endereço MAC de destino repetido 16 vezes.

O ponto importante é que, quando a máquina está desligada, ela não tem stack de rede ativa — sem IP, sem ARP, sem roteamento. A única coisa "viva" é a placa de rede, que mantém uma pequena quantidade de energia auxiliar (standby power) justamente para escutar o tráfego bruto de camada 2 (Ethernet) em busca desse padrão de bytes. Ao reconhecer o padrão com o MAC correspondente, a NIC sinaliza a placa-mãe para iniciar o boot.

Isso explica por que o comando de disparo usa o endereço de broadcast da rede (ex: 192.168.11.255) em vez do IP da máquina-alvo: sem stack de rede ativa, não há como endereçar a máquina via unicast/ARP. O broadcast garante que o frame chegue fisicamente a todas as portas do domínio de broadcast, e apenas a NIC com o MAC correto (e WoL habilitado) reage. Para as demais máquinas ligadas, o pacote é simplesmente descartado — não representa nenhum risco ou efeito colateral.

Passo 1 — Verificar suporte real na NIC

Um erro comum é tentar identificar suporte a WoL via dmidecode -t system, olhando o campo Wake-up Type. Esse campo não indica capacidade de WoL — ele mostra apenas o que causou o último boot da máquina (power switch, PCI, etc). A fonte correta de verdade é o ethtool, direto na interface de rede.

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

Saída esperada:

Supports Wake-on: pumbg
Wake-on: d

Cada letra em Supports Wake-on representa um modo suportado pela NIC/driver:

Se a letra g não aparecer em Supports Wake-on, pare por aqui: a combinação NIC + driver não suporta magic packet, e não há configuração de software que resolva isso.

Passo 2 — Habilitar o WoL

Com suporte confirmado, habilite temporariamente:

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

Essa mudança não sobrevive a reboot por padrão — é necessário persistir de duas formas complementares.

Passo 3 — Persistir a configuração

Via /etc/network/interfaces (ifupdown2)

No Proxmox, a interface de rede geralmente é gerenciada via /etc/network/interfaces, mesmo com o arquivo trazendo o aviso de "autogenerated". Esse aviso se refere a não mover interfaces gerenciadas pelo PVE para arquivos externos via source-directory — editar diretamente o bloco da interface física é seguro e é a forma recomendada.

Localize o bloco da sua interface física (não a bridge vmbrX — o WoL precisa ser aplicado na interface física real):

auto eth0
iface eth0 inet manual

E adicione a diretiva post-up, respeitando a indentação por tab (não espaço) para manter consistência com o restante do arquivo:

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

Aplique sem derrubar a rede ativa:

ifreload -a

Via regra udev (camada de redundância)

Como reforço — cobrindo cenários em que o módulo de rede sobe antes do ifupdown2 processar as diretivas —, crie também uma regra 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== para o nome real da sua interface e confirme o path do ethtool com which ethtool (no Debian 13/trixie, com usr-merge, /sbin é apenas um symlink para /usr/sbin, então ambos funcionam, mas é bom usar o caminho absoluto real).

Passo 4 — Validar persistência

Reinicie a máquina:

reboot

Após o boot, sem rodar nada manualmente, confira:

ethtool eth0 | grep Wake-on

Se aparecer Wake-on: g sozinho, a persistência está funcionando corretamente.

Passo 5 — Configuração na BIOS/UEFI

Esse é o ponto que mais gera confusão, especialmente em placas OEM genéricas (kits de placas chinesas com chipsets Intel recondicionados são um exemplo comum). Mesmo com o sistema operacional configurado corretamente, o WoL pode simplesmente não funcionar se a BIOS não cooperar. Verifique:

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

• ErP/EuP Ready: se habilitado, geralmente desativa o WoL, pois corta a energia de standby da NIC para reduzir consumo em modo desligado. Desative essa opção.

• Suporte a S3 vs S5: algumas placas mais simples só mantêm energia auxiliar suficiente para WoL saindo de suspensão (S3), não de desligamento total (S5). Isso é uma limitação de hardware, não de configuração — vale testar os dois cenários para entender o comportamento real da sua placa.

Passo 6 — Testar o disparo

De outra máquina na mesma rede:

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

Substitua o IP de broadcast pela sua faixa de rede e o MAC pelo endereço real da interface (cat /sys/class/net/eth0/address).

Desligue a máquina de forma completa antes do teste:

shutdown -h now

Atenção: em algumas versões recentes do systemd, é possível que o comando retorne um erro relacionado a D-Bus (Refusing activation, D-Bus is shutting down) mesmo com o desligamento já em andamento — trata-se de uma race condition entre o comando e o systemd-logind encerrando o barramento D-Bus durante o próprio processo de shutdown. Se isso acontecer, não execute novos comandos: verifique via ping de outra máquina se o host realmente desligou antes de assumir que algo falhou.

Pegadinhas frequentes

• Bridge/bond no Proxmox: se a interface física estiver atrás de uma vmbrX, o WoL deve ser configurado na interface física (eth0), não na bridge. A bridge não interfere na captura do magic packet, que ocorre em nível de hardware da NIC.

• NICs Realtek genéricas: têm suporte a WoL inconsistente entre variantes do mesmo chip. Mesmo com o driver reportando pumbg, algumas placas simplesmente não têm a trilha de alimentação auxiliar (VCC standby) roteada corretamente até o chip — nesse caso, é uma limitação física, sem solução via software.

• Switch com port security agressivo: alguns switches gerenciados derrubam portas sem link ativo constante, o que pode impedir o magic packet de chegar. Confirme que o switch mantém a porta ativa mesmo com o host desligado.

• WoL entre VLANs/subredes diferentes: o broadcast usado no WoL não atravessa roteadores por padrão. Para acordar uma máquina em outra subnet, é necessário suporte a directed broadcast no roteador, ou algum host na mesma rede física atuando como proxy do pacote.

Conclusão

Wake-on-LAN é um recurso simples de configurar, mas com múltiplas camadas que precisam estar alinhadas: suporte do driver/NIC, persistência da configuração no SO, cooperação da BIOS/UEFI, e comportamento correto do switch de rede. Testando cada camada isoladamente — começando pelo ethtool, depois persistência, depois BIOS — fica muito mais simples isolar onde está o problema quando o WoL "não funciona".