Imagine deixar um computador desligado em casa ou no escritório e, horas depois, precisar acessá-lo remotamente.

Seria possível ligar esse computador sem apertar fisicamente o botão Power?

Em equipamentos compatíveis, sim.

Uma das tecnologias utilizadas para isso é o Wake-on-LAN, normalmente abreviado como:

WoL

O Wake-on-LAN permite que determinados computadores sejam despertados ou ligados através de um evento recebido pela interface de rede.

O conceito existe há muitos anos, mas continua extremamente útil em redes modernas.

Ele pode ser empregado em:

• computadores domésticos;
• escritórios;
• estações de trabalho;
• servidores;
• laboratórios;
• suporte técnico;
• acesso remoto;
• administração de vários computadores;
• automações.

Porém, configurar Wake-on-LAN corretamente envolve muito mais do que instalar um aplicativo e informar o endereço IP do computador.

Para entender por que WoL funciona em uma máquina e falha completamente em outra, precisamos conhecer vários elementos:

placa-mãe
↓
BIOS/UEFI
↓
placa de rede
↓
driver
↓
Windows
↓
estado de energia
↓
switch/roteador
↓
Magic Packet

E quando queremos acordar um computador pela Internet, entram outras questões:

IP público
NAT
firewall
ARP
broadcast
VPN
roteador

Neste guia completo da VMIA, vamos entender o Wake-on-LAN desde o princípio e avançar até os cenários mais complicados de diagnóstico.

---

O que é Wake-on-LAN?

Wake-on-LAN é uma tecnologia que permite que um dispositivo compatível responda a um padrão específico de dados recebido pela interface de rede mesmo quando o computador não está em seu estado normal de funcionamento.

Em vez de alguém pressionar:

Power

um dispositivo na rede envia uma mensagem específica.

A interface de rede compatível reconhece esse padrão e sinaliza ao hardware que o computador deve acordar.

De maneira simplificada:

computador desligado ou suspenso
↓
placa de rede continua preparada para determinado evento
↓
Magic Packet chega
↓
interface reconhece o padrão
↓
hardware recebe o evento de wake
↓
computador inicia ou retoma

Esse é o princípio básico.

---

Wake-on-LAN não é acesso remoto

Essa diferença é fundamental.

Wake-on-LAN:

acorda ou liga o computador.

Ele não fornece automaticamente acesso à Área de Trabalho.

Depois que o computador inicia, podemos utilizar outra solução, conforme o ambiente, como:

• Área de Trabalho Remota;
• ferramenta corporativa de administração;
• software de acesso remoto;
• VPN;
• compartilhamento de arquivos;
• outros serviços autorizados.

Portanto:

Wake-on-LAN
≠
controle remoto

O WoL resolve a primeira etapa:

máquina está desligada
↓
ligar/acordar

Depois outro serviço assume o acesso.

---

Por que usar Wake-on-LAN?

Um cenário interessante é o acesso remoto.

Imagine um computador que não precisa permanecer ligado 24 horas por dia.

Sem Wake-on-LAN:

PC ligado o tempo todo
↓
consumo de energia
↓
calor
↓
horas de funcionamento

Com uma infraestrutura adequada:

PC desligado
↓
necessidade de acesso
↓
Wake-on-LAN
↓
PC inicia
↓
acesso remoto

Quando o trabalho termina, o computador pode ser desligado novamente por mecanismos apropriados.

---

Wake-on-LAN funciona com o computador totalmente desligado?

A resposta correta é:

depende do hardware, firmware, driver e estado de energia.

Essa é uma das maiores fontes de confusão sobre WoL.

Um computador pode aceitar Wake-on-LAN quando está:

Suspenso

mas não quando está:

Desligado

Outro pode funcionar nos dois estados.

Outro pode perder a capacidade de WoL depois que determinadas opções de economia de energia entram em ação.

Por isso, dizer simplesmente:

“Wake-on-LAN funciona com PC desligado.”

é uma simplificação excessiva.

Precisamos entender os estados de energia.

---

Estados de energia do computador

Historicamente, PCs utilizam estados de energia definidos dentro da arquitetura ACPI.

Podemos encontrar referências a estados como:

S0
S1
S2
S3
S4
S5

Em termos bastante simplificados:

S0 = sistema funcionando
S3 = suspensão tradicional
S4 = hibernação
S5 = desligamento lógico/soft off

Mas computadores modernos podem utilizar modelos diferentes, incluindo Modern Standby, e nem todos os estados clássicos ficam disponíveis em todos os equipamentos.

Para Wake-on-LAN, isso importa muito.

---

WoL a partir de suspensão

Este costuma ser um dos cenários mais favoráveis.

O computador entra em um estado de baixo consumo, mas determinados componentes permanecem preparados para eventos capazes de acordar o sistema.

A placa de rede pode ser um desses componentes.

O processo fica aproximadamente:

PC suspenso
↓
NIC aguardando evento
↓
Magic Packet
↓
wake
↓
Windows retorna

Se o equipamento oferece suporte adequado, o processo pode acontecer rapidamente.

---

WoL a partir de hibernação

Na hibernação, o Windows salva o estado necessário para armazenamento e reduz muito mais o consumo de energia.

A possibilidade de acordar através da rede dependerá da implementação do equipamento e das configurações disponíveis.

Não devemos presumir que:

funciona em suspensão
=
funciona em hibernação

São estados diferentes.

---

WoL a partir de S5

O estado S5 corresponde ao chamado Soft Off em sistemas ACPI tradicionais.

O computador parece desligado, mas determinadas partes da placa-mãe ainda podem receber alimentação enquanto a fonte permanece conectada.

É justamente essa energia residual que pode permitir que uma interface de rede permaneça preparada para um evento de wake em hardware compatível.

Por isso, em alguns desktops, você pode observar LEDs da porta Ethernet ainda acesos depois de desligar o Windows.

Isso pode indicar que a interface ainda recebe alguma alimentação.

Mas:

LED aceso não garante que Wake-on-LAN esteja corretamente habilitado.

É apenas uma pista.

---

Se tirar o computador da tomada, Wake-on-LAN funciona?

Em um PC convencional sem uma fonte de energia alternativa, não.

Se a placa de rede e a placa-mãe não recebem energia, não existe componente ativo para detectar o Magic Packet.

Ou seja:

sem alimentação
↓
NIC sem energia
↓
não recebe Magic Packet
↓
não existe Wake-on-LAN

O mesmo raciocínio vale quando uma régua de energia é desligada fisicamente.

---

Algumas placas-mãe cortam energia da rede quando desligadas

Sim.

Configurações de economia de energia no firmware podem reduzir drasticamente o consumo quando o computador está desligado.

Uma opção frequentemente relacionada a esse comportamento é conhecida em determinados equipamentos como:

ErP

ou variações semelhantes.

Quando habilitada, ela pode limitar a alimentação de determinados dispositivos em estados de desligamento.

O efeito pode ser:

Windows desliga
↓
NIC perde alimentação necessária
↓
Magic Packet não pode ser detectado

Por isso, opções de economia de energia da BIOS/UEFI fazem parte do diagnóstico.

---

O que é o Magic Packet?

O chamado Magic Packet é o elemento mais conhecido do Wake-on-LAN.

Ele contém um padrão específico que inclui o endereço MAC da interface que desejamos despertar.

A estrutura clássica possui:

6 bytes com FF

seguidos por:

16 repetições do endereço MAC do destino

Se o MAC for, por exemplo:

00:11:22:33:44:55

o padrão contém esse endereço repetido várias vezes após a sequência inicial.

É esse padrão que o hardware compatível consegue reconhecer.

---

Por que o Wake-on-LAN usa o endereço MAC?

Quando o computador está desligado, não devemos imaginar que ele funciona como uma máquina Windows completamente ativa respondendo normalmente a:

IP
DHCP
DNS
ping

O mecanismo clássico do Wake-on-LAN identifica a interface pelo endereço MAC inserido no Magic Packet.

Por isso, aplicativos de WoL normalmente pedem:

MAC Address

---

IP e MAC não são a mesma coisa

Exemplo de endereço IPv4:

192.168.1.50

Exemplo de endereço MAC:

00-11-22-33-44-55

O endereço IP pertence à configuração lógica da rede.

O MAC identifica a interface em nível de enlace dentro daquele contexto.

Para construir o Magic Packet, o dado fundamental é o MAC.

---

Como descobrir o MAC no Windows 11?

Abra:

Terminal

ou:

Prompt de Comando

e execute:

ipconfig /all

Procure o adaptador correto.

Você verá algo semelhante a:

Adaptador Ethernet Ethernet:

Endereço Físico. . . . . . . . . : 00-11-22-33-44-55

O:

Endereço Físico

corresponde ao endereço MAC.

---

Get-NetAdapter também mostra o MAC

No PowerShell:

Get-NetAdapter

Podemos obter informações como:

Name
InterfaceDescription
ifIndex
Status
MacAddress
LinkSpeed

Por exemplo:

Name        Status    MacAddress
Ethernet    Up        00-11-22-33-44-55
Wi-Fi       Up        AA-BB-CC-DD-EE-FF

Agora aparece outra pergunta importante:

qual desses MACs devemos utilizar?

---

Use o MAC do adaptador que receberá o Wake-on-LAN

Imagine um notebook com:

Ethernet:
00-11-22-33-44-55

Wi-Fi:
AA-BB-CC-DD-EE-FF

Se o Wake-on-LAN será realizado pela Ethernet, o MAC relevante é o da Ethernet.

Não utilize o MAC do Wi-Fi apenas porque ele aparece primeiro em algum aplicativo.

Cada interface possui sua própria identidade.

---

Wake-on-LAN funciona melhor por cabo Ethernet?

Na prática, o Wake-on-LAN clássico é muito associado à Ethernet.

Quando o computador está desligado, manter a interface Ethernet preparada para receber o Magic Packet é uma implementação comum em hardware compatível.

Por isso, quando queremos uma configuração previsível, normalmente começamos pelo:

Ethernet

---

Wake-on-Wireless-LAN existe?

Sim, existem mecanismos de wake relacionados a redes sem fio, frequentemente chamados de Wake on Wireless LAN ou WoWLAN.

Mas não devemos assumir que qualquer placa Wi-Fi que funciona no Windows também consegue acordar o computador em qualquer estado de energia.

O suporte depende de:

• adaptador;
• driver;
• firmware;
• plataforma;
• estado de energia;
• implementação do fabricante.

Portanto:

Wake-on-LAN por Ethernet

e:

wake via Wi-Fi

não devem ser tratados como exatamente a mesma situação.

---

O Magic Packet usa TCP?

Não necessariamente.

A implementação clássica não depende de uma conexão TCP estabelecida com o computador desligado.

Muitas ferramentas encapsulam o Magic Packet em um datagrama UDP para transportá-lo pela rede.

Portas frequentemente associadas a aplicações de Wake-on-LAN incluem:

UDP 7

e:

UDP 9

Mas isso gera outra confusão.

---

A porta UDP 9 não é o que torna o pacote “mágico”

O que caracteriza o Magic Packet é seu conteúdo/padrão, não simplesmente a porta.

Mandar qualquer dado para:

UDP 9

não acorda automaticamente um computador.

A interface precisa receber o padrão correto contendo o MAC correspondente.

---

Wake-on-LAN dentro da rede local

O cenário mais simples é:

PC A
↓
switch/roteador
↓
PC B desligado

O PC A envia um Magic Packet para a rede.

A placa Ethernet do PC B continua preparada para detectar o padrão.

Quando reconhece seu MAC:

NIC
↓
placa-mãe
↓
wake

O computador inicia.

---

Por que broadcast aparece tanto em Wake-on-LAN?

Quando um computador está desligado há algum tempo, tentar enviar tráfego IP unicast diretamente para ele pode criar dificuldades.

O roteador ou outro dispositivo pode não possuir mais uma associação ARP válida entre:

IP
↔
MAC

do computador desligado.

Uma estratégia comum dentro da LAN é utilizar broadcast.

Por exemplo, em uma rede:

192.168.1.0/24

o broadcast normalmente seria:

192.168.1.255

O pacote pode então alcançar as interfaces naquele domínio de broadcast, e somente a NIC que reconhecer o MAC contido no Magic Packet deve reagir.

---

O que ARP tem a ver com Wake-on-LAN?

Imagine:

PC alvo
IP: 192.168.1.50
MAC: 00-11-22-33-44-55

Enquanto o computador está ligado, o roteador pode aprender:

192.168.1.50
↓
00-11-22-33-44-55

Depois o computador desliga.

Com o tempo, a entrada ARP pode expirar.

Agora o roteador tenta entregar um pacote unicast para:

192.168.1.50

mas precisa descobrir qual MAC possui esse endereço.

O PC está desligado e pode não responder ao ARP normalmente.

A entrega falha.

Isso explica por que algumas configurações funcionam:

logo depois de desligar

mas deixam de funcionar:

horas depois

Esse comportamento é uma pista excelente.

---

Reserva DHCP resolve Wake-on-LAN?

Não diretamente.

Uma reserva DHCP ajuda a manter uma relação previsível:

MAC
→
mesmo endereço IP

Isso é útil para administração da rede.

Mas não significa que a tabela ARP do roteador ficará permanentemente preenchida.

São mecanismos diferentes:

DHCP
≠
ARP

Essa distinção é muito importante quando diagnosticamos WoL.

---

IP fixo também não garante Wake-on-LAN

Configurar:

192.168.1.50

manualmente no Windows não garante que um Magic Packet enviado pela Internet conseguirá alcançar a interface depois que o computador estiver desligado.

Novamente:

IP configurado

e:

entrega do frame até a NIC desligada

são problemas diferentes.

---

Wake-on-LAN exige suporte da placa-mãe?

Para acordar de determinados estados, a plataforma precisa permitir que a interface de rede gere um evento capaz de despertar o sistema.

Em desktops modernos, isso normalmente envolve integração entre:

• placa-mãe;
• controlador de rede;
• firmware;
• sistema operacional.

Em computadores antigos, existiram implementações que utilizavam cabos específicos de WoL entre a placa de rede e a placa-mãe.

Hoje isso normalmente ocorre através da própria arquitetura do hardware.

---

Como saber se o computador suporta Wake-on-LAN?

Não existe um único teste universal que responda tudo.

Devemos verificar três camadas:

1. BIOS/UEFI
2. Adaptador e driver
3. Windows

E depois fazer o teste real.

---

Configurações de Wake-on-LAN na BIOS/UEFI

Os nomes variam bastante entre fabricantes.

Podemos encontrar opções como:

Wake on LAN

Power On By PCI-E

Resume By PCI-E Device

Wake From LAN

PCIe Wake

ou outras variações.

Não existe um nome universal.

---

Por que PCIe aparece em uma opção de Wake-on-LAN?

Porque o controlador de rede pode estar conectado ao sistema através de uma arquitetura PCI Express.

Assim, uma opção que permite:

Wake by PCI-E

pode ser relevante mesmo sem mencionar literalmente “LAN”.

Isso depende da placa-mãe.

Consulte a documentação do equipamento antes de alterar configurações.

---

ErP pode impedir Wake-on-LAN

Como mencionado anteriormente, opções relacionadas a ErP podem reduzir o consumo em estados de desligamento.

Se isso remove a alimentação necessária da interface de rede:

Magic Packet
↓
não existe NIC ativa para reconhecê-lo

O WoL a partir do desligamento deixa de funcionar.

Esse é um dos itens que devem ser verificados quando:

WoL funciona suspenso

mas:

não funciona desligado

---

Depois da BIOS vem o Windows

Mesmo que a placa-mãe suporte Wake-on-LAN, o adaptador e o driver precisam estar configurados corretamente.

Abra:

devmgmt.msc

Depois:

Adaptadores de rede
↓
adaptador Ethernet
↓
Propriedades

Dependendo do driver, podemos encontrar opções nas guias:

Avançado

e:

Gerenciamento de Energia

---

Opções comuns no driver

Os nomes dependem do fabricante.

Podemos encontrar:

Wake on Magic Packet

Wake on Pattern Match

Shutdown Wake-On-Lan

Wake From Shutdown

WOL & Shutdown Link Speed

entre outras.

Nem todos os drivers possuem todas essas opções.

---

Wake on Magic Packet

Quando disponível, esta é uma das configurações mais diretamente relacionadas ao WoL.

Ela permite que o adaptador responda ao padrão do Magic Packet em estados suportados.

Para um cenário de Wake-on-LAN tradicional, normalmente queremos verificar se:

Wake on Magic Packet
=
Enabled

---

Wake on Pattern Match é a mesma coisa?

Não exatamente.

Pattern Match permite que determinados padrões de tráfego possam gerar eventos de wake.

Isso pode incluir comportamentos além do Magic Packet.

Se o objetivo é evitar que o computador acorde por tráfego indesejado, pode ser interessante diferenciar:

Magic Packet

de:

Pattern Match

em vez de habilitar tudo indiscriminadamente.

---

“Permitir que este dispositivo acorde o computador”

Na guia de gerenciamento de energia do adaptador, o Windows pode apresentar:

Permitir que este dispositivo acorde o computador

Essa opção é importante para permitir que a interface participe do mecanismo de wake em estados suportados.

Também pode aparecer:

Permitir apenas um pacote mágico para ativar o computador

Essa segunda configuração ajuda a restringir o wake ao Magic Packet, em vez de permitir que outros eventos de rede acordem o sistema.

---

Como descobrir quais dispositivos podem acordar o Windows?

O comando:

powercfg /devicequery wake_armed

é extremamente útil.

Ele mostra dispositivos atualmente configurados para poder acordar o computador.

Podemos encontrar algo como:

Intel(R) Ethernet Controller
HID Keyboard Device
HID-compliant mouse

Se o adaptador Ethernet aparece, temos uma pista de que está armado para wake.

---

O comando não garante WoL a partir de qualquer estado

Isso é importante.

Encontrar a placa em:

powercfg /devicequery wake_armed

não significa automaticamente:

Wake-on-LAN funcionará em S5

O comando ajuda a analisar a configuração do Windows.

Firmware e hardware continuam relevantes.

---

Como descobrir quem acordou o computador?

Depois de um wake inesperado, execute:

powercfg /lastwake

O Windows pode apresentar informações sobre a origem do último evento de ativação.

Isso é extremamente útil quando o problema é o oposto:

“Meu computador está acordando sozinho.”

---

Wake-on-LAN pode fazer o PC acordar sozinho?

Uma configuração permissiva demais pode permitir que tráfego de rede gere eventos de wake.

Por isso, quando queremos acordar apenas através do Magic Packet, vale verificar se o driver permite restringir o comportamento.

O objetivo é:

Magic Packet correto
↓
acorda

e não:

qualquer atividade de rede
↓
acorda

---

Como verificar estados de suspensão disponíveis?

Execute:

powercfg /a

O comando mostra quais estados de suspensão estão disponíveis no equipamento.

Isso ajuda a entender se o computador utiliza:

• suspensão tradicional;
• hibernação;
• Modern Standby;
• outros estados suportados.

Essa informação pode explicar por que tutoriais feitos para outro computador não produzem o mesmo resultado.

---

Primeiro teste de Wake-on-LAN

Antes de envolver Internet, DDNS, encaminhamento de portas ou VPN, faça o teste mais simples possível:

mesma rede local
+
Ethernet
+
computador suspenso

Se não funcionar nesse cenário, não faz sentido começar configurando o roteador para acesso externo.

O diagnóstico deve evoluir em camadas.

---

Sequência ideal de testes

Comece:

Teste 1
PC suspenso
Magic Packet dentro da LAN

Depois:

Teste 2
PC hibernado
Magic Packet dentro da LAN

Depois, se o hardware suportar:

Teste 3
PC desligado
Magic Packet dentro da LAN

Somente depois:

Teste 4
Wake remoto

Essa ordem permite descobrir exatamente onde a cadeia quebra.

---

Se funciona suspenso, mas não desligado

Essa é uma pista muito valiosa.

Podemos concentrar a investigação em:

• suporte ao estado de desligamento;
• BIOS/UEFI;
• ErP;
• alimentação da NIC;
• opção Shutdown Wake-on-LAN;
• comportamento do driver;
• Inicialização Rápida;
• limitações específicas da plataforma.

Isso é muito mais eficiente do que alterar configurações aleatoriamente.

---

Se nem suspenso funciona

Volte ao básico.

Verifique:

MAC correto?

adaptador correto?

Wake on Magic Packet habilitado?

dispositivo autorizado a acordar?

BIOS/UEFI permite wake?

Magic Packet realmente está chegando?

Essa última pergunta será fundamental na próxima etapa.

---

O primeiro grande princípio do diagnóstico de WoL

Wake-on-LAN não deve ser diagnosticado como uma única função.

Ele é uma cadeia:

aplicativo gera pacote
↓
rede transporta
↓
NIC recebe
↓
NIC reconhece MAC
↓
hardware permite wake
↓
firmware aceita
↓
computador inicia

Se qualquer etapa falhar:

WoL não funciona

O trabalho do diagnóstico é descobrir qual elo da cadeia está quebrado.

Como configurar Wake-on-LAN no Windows 11 e descobrir por que o Magic Packet não funciona

Na primeira parte entendemos que Wake-on-LAN não depende de uma única configuração.

Existe uma cadeia completa:

programa gera Magic Packet
↓
rede transporta
↓
placa de rede recebe
↓
NIC reconhece o padrão
↓
hardware gera evento de wake
↓
BIOS/UEFI permite
↓
computador acorda

Agora vamos transformar essa teoria em uma configuração prática.

O objetivo desta parte é configurar o Wake-on-LAN dentro da rede local e, principalmente, aprender a responder:

O Magic Packet realmente está chegando ao computador?

Essa pergunta separa dois grupos completamente diferentes de problemas.

Se o pacote não chega:

problema de rede

Se o pacote chega corretamente, mas o computador não acorda:

hardware
firmware
driver
estado de energia
configuração da NIC

Essa separação economiza muito tempo.

---

1. Comece pela Ethernet

Para o primeiro teste, utilize preferencialmente uma conexão Ethernet.

Monte o cenário:

Computador A
↓
rede local
↓
roteador/switch
↓
Ethernet
↓
Computador B

O Computador B será o equipamento que desejamos acordar.

Não comece por:

Internet
VPN
DDNS
Port Forwarding
Wi-Fi

Primeiro faça o mecanismo básico funcionar dentro da LAN.

---

2. Descubra o adaptador Ethernet correto

No computador que será acordado, abra o PowerShell e execute:

Get-NetAdapter

Você poderá encontrar algo parecido com:

Name       InterfaceDescription                 Status    MacAddress
----       --------------------                 ------    ----------
Ethernet   Intel(R) Ethernet Controller         Up        00-11-22-33-44-55
Wi-Fi      Intel(R) Wi-Fi 6E Adapter            Up        AA-BB-CC-DD-EE-FF

Para WoL pela Ethernet, anote:

00-11-22-33-44-55

Esse será o MAC utilizado no Magic Packet.

---

3. Confirme com ipconfig /all

Também podemos executar:

ipconfig /all

Procure o adaptador Ethernet.

Exemplo:

Adaptador Ethernet Ethernet:

Descrição. . . . . . . . . . . . : Intel Ethernet Controller
Endereço Físico. . . . . . . . . : 00-11-22-33-44-55
DHCP Habilitado. . . . . . . . . : Sim
Endereço IPv4. . . . . . . . . . : 192.168.1.50

Agora temos:

MAC = 00-11-22-33-44-55
IP = 192.168.1.50

---

4. Não confunda o MAC do Wi-Fi

Se o computador possui:

Ethernet
Wi-Fi
Bluetooth
adaptadores virtuais
VPN

podem existir vários endereços MAC.

Um erro bastante comum é copiar o endereço da interface errada.

Por isso, confirme:

Qual interface permanecerá conectada quando o PC estiver suspenso/desligado?

Para nosso teste:

Ethernet

---

5. Configure a BIOS/UEFI

Reinicie o computador e entre na BIOS/UEFI.

O método varia conforme fabricante.

Procure opções relacionadas a:

Wake on LAN
Power On By PCI-E
Resume By PCI-E
Wake From LAN
PCIe Wake
LAN Wake

O nome exato depende do equipamento.

Habilite apenas a configuração correspondente ao suporte de wake pela interface de rede.

---

6. Verifique ErP

Se encontrar:

ErP

ou opções de economia de energia profunda, leia a descrição apresentada pelo fabricante.

Em alguns equipamentos, habilitar ErP reduz a alimentação disponível em estados de desligamento.

Isso pode impedir WoL a partir de S5.

O sintoma típico é:

WoL suspenso = funciona
WoL desligado = não funciona

Não desative recursos aleatoriamente. Consulte a documentação da placa-mãe ou notebook.

---

7. Salve e volte ao Windows

Depois da configuração do firmware, abra:

devmgmt.msc

Entre em:

Adaptadores de rede

Localize a interface Ethernet correta.

Clique:

Propriedades

---

8. Guia Avançado

Dependendo do driver, procure opções como:

Wake on Magic Packet

Shutdown Wake-On-Lan

Wake From Shutdown

Wake on Pattern Match

Os nomes e opções disponíveis dependem completamente do adaptador e do driver.

---

9. Habilite Wake on Magic Packet

Quando disponível:

Wake on Magic Packet
=
Enabled

Essa é a configuração diretamente associada ao Magic Packet.

---

10. E Wake on Pattern Match?

Se nosso objetivo é acordar exclusivamente através do Magic Packet, não precisamos necessariamente permitir qualquer padrão capaz de gerar wake.

Em alguns cenários, deixar Pattern Match habilitado pode contribuir para:

“Meu computador acorda sozinho.”

Por isso, diferencie:

Magic Packet

de:

outros padrões de rede

A disponibilidade dessas opções varia conforme o driver.

---

11. Abra Gerenciamento de Energia

Nas propriedades do adaptador, procure:

Gerenciamento de Energia

Quando disponível, encontramos opções como:

Permitir que este dispositivo acorde o computador

e:

Permitir apenas um pacote mágico para ativar o computador

Para WoL baseado em Magic Packet, essas opções são especialmente relevantes.

---

12. Confira com powercfg

Abra um Terminal com privilégios administrativos.

Execute:

powercfg /devicequery wake_armed

Esse comando lista os dispositivos atualmente habilitados para acordar o computador.

Podemos encontrar:

Intel(R) Ethernet Controller
HID Keyboard Device

Se o adaptador Ethernet estiver na lista, temos uma confirmação adicional da configuração de wake no Windows.

---

13. Descubra todos os dispositivos capazes de wake

Também podemos explorar consultas relacionadas a dispositivos com capacidade de wake através do powercfg.

Isso ajuda a diferenciar:

hardware possui capacidade

de:

dispositivo está atualmente armado para wake

Essa diferença é importante durante o diagnóstico.

---

14. powercfg /lastwake

Se o computador acordou e queremos saber o motivo:

powercfg /lastwake

O resultado pode apontar informações sobre a última origem de ativação.

Esse comando será especialmente importante quando investigarmos computadores que acordam sozinhos.

---

15. Verifique os estados disponíveis

Execute:

powercfg /a

O Windows apresentará os estados de suspensão disponíveis e indisponíveis.

Isso ajuda a entender se a máquina utiliza:

S3

ou uma arquitetura baseada em:

Modern Standby

entre outras possibilidades.

Não compare diretamente dois computadores sem verificar isso.

---

16. Faça o primeiro teste em suspensão

Não desligue o computador ainda.

Primeiro:

Suspender

No outro dispositivo da rede, utilize uma ferramenta confiável de Wake-on-LAN.

Configure o MAC:

00-11-22-33-44-55

e envie o Magic Packet.

Se o computador acordar:

Excelente.

Sabemos que boa parte da cadeia está funcionando.

---

17. Se o computador não acordar, não mude dez configurações

Primeiro precisamos descobrir:

O Magic Packet foi realmente gerado corretamente?

Uma ferramenta extremamente útil para isso é o:

Wireshark

---

18. Wireshark e Wake-on-LAN

O Wireshark permite capturar pacotes trafegando pela interface de rede.

Podemos utilizá-lo no computador que envia o WoL para confirmar que o pacote saiu.

Em determinados cenários também podemos capturar em outro ponto da rede para verificar se o tráfego atravessou a infraestrutura.

O objetivo é enxergar:

origem
↓
Magic Packet
↓
destino/broadcast

---

19. O Wireshark reconhece Wake-on-LAN?

Dependendo do encapsulamento e da versão, o Wireshark pode dissecar o tráfego relacionado ao Wake-on-LAN.

Mesmo quando isso não aparece de forma extremamente amigável, podemos analisar:

• Ethernet;
• UDP;
• endereço de destino;
• porta;
• payload.

O ponto principal é confirmar a existência do padrão esperado.

---

20. Como reconhecer o Magic Packet no conteúdo

Lembre-se da estrutura clássica:

FF FF FF FF FF FF

seguida por 16 repetições do MAC.

Para:

00:11:22:33:44:55

veríamos conceitualmente:

FF FF FF FF FF FF
00 11 22 33 44 55
00 11 22 33 44 55
00 11 22 33 44 55
...

até completar as repetições previstas.

---

21. Por que isso é tão útil?

Imagine:

Aplicativo diz:
Magic Packet enviado

Mas o computador não acorda.

Isso não prova que:

placa-mãe está com problema

O aplicativo pode estar:

• usando MAC incorreto;
• enviando pela interface errada;
• enviando ao destino errado;
• usando configuração inadequada.

Capturar o tráfego permite verificar a primeira metade do caminho.

---

22. Broadcast dentro da LAN

Uma forma comum de distribuir o Magic Packet na rede local utiliza o broadcast da sub-rede.

Imagine:

Rede:
192.168.1.0/24

Broadcast:

192.168.1.255

Uma ferramenta de WoL pode enviar o datagrama para:

192.168.1.255

contendo o MAC da máquina alvo.

---

23. Por que não enviar simplesmente para 192.168.1.50?

Enquanto o computador está ligado:

192.168.1.50
↔
00-11-22-33-44-55

pode estar presente na tabela ARP.

Depois que o computador desliga, a entrada pode permanecer por algum tempo.

Durante esse período:

unicast WoL

pode funcionar.

Horas depois, a entrada expira.

Agora o roteador pergunta:

Quem tem 192.168.1.50?

O computador desligado não responde como faria quando ativo.

O roteador pode deixar de conseguir construir o frame Ethernet destinado ao MAC correto.

Resultado:

WoL funcionava
↓
algum tempo depois
↓
parou

---

24. Veja a tabela ARP

No Windows, podemos usar:

arp -a

ou ferramentas mais modernas do PowerShell, como:

Get-NetNeighbor

Podemos encontrar relações entre:

IP
MAC
estado
interface

Isso ajuda a entender o funcionamento da vizinhança IPv4 na LAN.

---

25. ARP e DHCP são independentes

Reforçando:

Reserva DHCP:
MAC → IP reservado

Não significa:

ARP permanente:
IP → MAC para sempre

O DHCP fornece configuração de rede.

ARP ajuda dispositivos IPv4 a resolver endereços IP para endereços de enlace dentro da rede local.

São mecanismos distintos.

---

26. Uma reserva DHCP ainda é útil?

Sim.

Para administração de computadores, é bastante útil manter um endereço previsível.

Por exemplo:

PC-ESCRITORIO
MAC: 00-11-22-33-44-55
IP reservado: 192.168.1.50

Isso facilita:

• acesso remoto;
• inventário;
• regras;
• monitoramento;
• identificação.

Mas não trate a reserva como solução automática para WoL.

---

27. Porta UDP 7 ou 9?

Muitas ferramentas utilizam:

UDP 7

ou:

UDP 9

para transportar o Magic Packet.

Em uma LAN simples, a escolha da porta normalmente é menos importante do que:

MAC correto
+
payload correto
+
entrega correta

Quando atravessamos roteadores e firewalls, a porta passa a ter maior importância para as regras de encaminhamento.

---

28. O firewall do Windows pode impedir WoL?

Precisamos diferenciar duas situações.

Quando o computador está totalmente ativo, o Windows Firewall filtra tráfego conforme suas regras.

Quando estamos falando de uma NIC detectando Magic Packet em um estado de energia no qual o Windows não está operando normalmente, a lógica não é simplesmente:

abrir UDP 9 no Firewall do Windows
=
WoL resolvido

O mecanismo envolve hardware, driver, firmware e estado de energia.

Portanto, criar regras aleatórias no Firewall do Windows não deve ser a primeira tentativa.

---

29. E o firewall do roteador?

Quando o Magic Packet vem de outra rede, aí a situação muda.

O roteador precisa decidir:

recebo tráfego externo
↓
permito?
↓
para onde encaminho?

Nesse cenário, NAT e firewall tornam-se fundamentais.

Mas ainda não vamos para a Internet.

Primeiro:

LAN precisa funcionar.

---

30. Teste o Magic Packet com o computador ligado

Esse é um excelente método de diagnóstico.

Com o computador alvo ligado, abra o Wireshark nele.

Inicie a captura na interface Ethernet.

Em outro computador, envie o Magic Packet.

Agora verifique se o pacote aparece.

Se aparece:

emissor
↓
rede
↓
computador alvo

estão funcionando enquanto o alvo está ativo.

---

31. Isso garante que chegará quando desligado?

Não.

Esse é um detalhe crucial.

Com o computador ligado, ele participa normalmente da rede:

ARP
IP
switching

Quando desliga, o comportamento muda.

Por isso, uma captura com o PC ligado confirma apenas parte da cadeia.

Ainda assim, é extremamente útil.

---

32. Teste com broadcast

Se o aplicativo permitir, compare:

Destino:
192.168.1.50

com:

Destino:
192.168.1.255

Se o unicast falha depois de algum tempo, mas o broadcast continua funcionando, temos uma pista relacionada à entrega na camada de rede/enlace.

---

33. O switch precisa suportar Wake-on-LAN?

Um switch Ethernet comum não precisa “ligar” o computador.

Ele precisa apenas transportar o frame adequadamente.

Porém, redes empresariais podem possuir:

• VLANs;
• controles de broadcast;
• segurança de portas;
• segmentação;
• filtros.

Nesses ambientes, o comportamento pode ser diferente.

---

34. Wake-on-LAN atravessa VLAN?

Broadcasts normalmente ficam limitados ao domínio de broadcast.

Se:

emissor = VLAN 10

e:

alvo = VLAN 20

o broadcast da VLAN 10 não atravessa automaticamente para a VLAN 20.

Para WoL entre redes diferentes, a infraestrutura precisa possuir uma estratégia específica.

Isso pode envolver recursos de roteamento e administração da rede.

---

35. Directed Broadcast

Existe o conceito de encaminhar tráfego para o broadcast de outra sub-rede, frequentemente chamado de directed broadcast.

Por questões de segurança e histórico de abuso de broadcasts, roteadores podem bloquear esse comportamento por padrão.

Por isso, não podemos assumir:

mandar pacote para 192.168.1.255 pela Internet

e esperar que qualquer roteador doméstico o encaminhe.

---

36. O roteador doméstico pode bloquear broadcast vindo da WAN

Sim.

Na verdade, esse comportamento pode ser desejável do ponto de vista de segurança.

Um roteador não deve simplesmente encaminhar qualquer broadcast externo para a LAN.

É justamente por isso que Wake-on-LAN pela Internet costuma ser mais complicado que WoL dentro da rede.

---

37. Teste de isolamento

Se WoL não funciona, crie esta tabela:

Estado          Resultado

Ligado          Magic Packet chega?
Suspenso        Acorda?
Hibernado       Acorda?
Desligado       Acorda?

Exemplo:

Ligado          Sim
Suspenso        Sim
Hibernado       Não
Desligado       Não

Agora sabemos que:

rede básica funciona
Magic Packet funciona
wake em suspensão funciona

O problema está relacionado aos estados de energia mais profundos.

---

38. Outro exemplo

Ligado          pacote não aparece
Suspenso        não acorda
Desligado       não acorda

Aqui não faz sentido começar mexendo em ErP.

Primeiro precisamos corrigir:

Magic Packet não está chegando.

---

39. Outro cenário

Ligado          pacote chega
Suspenso        não acorda

Agora temos:

rede funcionando

mas:

wake falhando

Investigue:

• driver;
• Wake on Magic Packet;
• gerenciamento de energia;
• BIOS/UEFI;
• suporte do hardware.

---

40. LED da Ethernet depois de suspender

Observe a porta.

Se os LEDs permanecem ativos ou apresentam comportamento compatível com link, isso sugere que a interface ainda possui algum nível de alimentação e conectividade.

Mas não use isso como prova definitiva.

Uma NIC pode ter LED aceso e ainda não estar configurada para gerar wake pelo Magic Packet.

---

41. LED apaga completamente ao desligar

Se:

PC ligado
↓
LED Ethernet aceso

e:

PC desligado
↓
LED apaga completamente

enquanto WoL em S5 não funciona, investigue:

• ErP;
• opções de energia da BIOS;
• Shutdown Wake-on-LAN;
• suporte do hardware;
• comportamento do driver.

É uma pista muito útil.

---

42. Inicialização Rápida do Windows pode entrar na investigação

O recurso Inicialização Rápida altera o caminho utilizado durante determinados desligamentos do Windows.

Em alguns equipamentos, isso pode interagir com comportamento de drivers e wake.

Se:

WoL suspenso = funciona

mas:

WoL após desligar Windows = falha

vale investigar também o comportamento com Inicialização Rápida.

Mas não a desative automaticamente em todos os computadores.

Faça um teste comparativo.

---

43. Reiniciar e desligar não são exatamente iguais

Esse conceito já apareceu em outros diagnósticos da VMIA.

No Windows moderno:

Reiniciar

e:

Desligar + ligar

podem percorrer caminhos diferentes dependendo das configurações de energia.

Isso pode influenciar drivers e estados do hardware.

---

44. Driver atualizado pode alterar o WoL

Imagine:

Driver versão A
WoL funciona

Atualização:

Driver versão B

Depois:

Wake on Magic Packet desaparece

ou:

WoL deixa de funcionar em S5

A cronologia é importante.

Verifique:

Fornecedor
Versão
Data

no Gerenciador de Dispositivos.

---

45. Não instale driver de qualquer site

Para adaptadores de rede, prefira:

• fabricante do computador;
• fabricante da placa-mãe;
• fabricante do adaptador;
• Windows Update quando apropriado.

Evite pacotes de sites desconhecidos e programas genéricos que prometem atualizar todos os drivers.

---

46. Teste com outra porta do roteador ou switch

Se existe comportamento estranho de link, teste:

outra porta Ethernet

Também verifique:

outro cabo

principalmente se a interface perde completamente o link depois de mudar de estado.

---

47. Mesh pode influenciar?

Se o computador está conectado por Ethernet a um nó Mesh, adaptador Powerline, bridge sem fio ou equipamento intermediário, o caminho fica mais complexo.

Exemplo:

PC
↓
Ethernet
↓
nó Mesh
↓
Wi-Fi backhaul
↓
roteador principal

Agora precisamos verificar se o equipamento intermediário mantém e encaminha corretamente o tráfego necessário.

Para o primeiro teste, quanto mais simples a topologia, melhor.

---

48. O primeiro diagnóstico está completo quando sabemos onde falha

Ao final desta etapa, devemos conseguir classificar o problema em uma destas categorias:

A — Magic Packet nem é gerado corretamente

B — pacote é gerado, mas não chega ao segmento correto

C — pacote chega, mas NIC não gera wake

D — WoL funciona suspenso, mas não desligado

E — WoL funciona perfeitamente dentro da LAN

Se chegamos a:

E

podemos avançar.

E é justamente aí que surge a pergunta mais complicada:

Como acordar o computador quando estou fora de casa?

Wake-on-LAN pela Internet: NAT, CGNAT, DDNS, ARP, VPN e formas mais seguras de acordar um PC remotamente

Depois que o Wake-on-LAN funciona corretamente dentro da rede local, surge a etapa mais difícil:

Como enviar o Magic Packet quando estou fora de casa ou do escritório?

Essa situação é muito mais complexa porque o pacote precisa atravessar:

Internet
↓
roteador
↓
NAT
↓
firewall
↓
rede local
↓
placa de rede do PC desligado

É exatamente nesse ponto que muitos tutoriais simplificam demais o processo.

A ideia:

abrir UDP 9
↓
encaminhar para o PC
↓
pronto

pode funcionar em alguns cenários, mas falhar completamente em outros.

O motivo envolve principalmente:

• NAT;
• CGNAT;
• IP público;
• DDNS;
• tabela ARP;
• broadcast;
• comportamento do roteador;
• segurança;
• topologia da rede.

Vamos analisar cada elemento.

Wake-on-LAN pela Internet é diferente do WoL dentro da LAN

Dentro da rede local, podemos enviar o Magic Packet diretamente para o domínio de broadcast.

Exemplo:

Rede:
192.168.1.0/24

Broadcast:
192.168.1.255

Um computador dentro dessa mesma rede pode enviar:

Magic Packet
↓
192.168.1.255
↓
NIC alvo

Pela Internet, isso não acontece diretamente.

O pacote chega primeiro ao endereço público do roteador.

Exemplo:

Internet
↓
200.x.x.x
↓
roteador
↓
192.168.1.0/24

Agora o roteador precisa saber o que fazer com aquele pacote.

O que é NAT nesse cenário?

Em redes domésticas, normalmente vários dispositivos compartilham um único endereço IPv4 público.

Dentro da LAN:

192.168.1.10
192.168.1.20
192.168.1.50

Na Internet, todos podem aparecer usando o mesmo IP público.

O roteador faz a tradução entre:

rede privada
↔
Internet

Esse mecanismo é chamado de NAT.

Quando uma conexão começa de dentro para fora, o roteador sabe qual dispositivo originou o tráfego.

Mas quando um pacote chega espontaneamente da Internet:

Internet
↓
roteador

o roteador precisa saber:

Para qual equipamento interno devo entregar isso?

É aí que entra o encaminhamento de portas.

Port Forwarding e Wake-on-LAN

Imagine que um aplicativo de WoL envie um Magic Packet para:

IP público
UDP 9

O roteador pode possuir uma regra semelhante a:

UDP 9
↓
192.168.1.50

Essa regra é chamada de:

Port Forwarding

ou encaminhamento de portas.

Em teoria:

Internet
↓
IP público:UDP 9
↓
roteador
↓
192.168.1.50
↓
PC

Parece simples.

Mas existe um problema.

O PC está desligado

Se o computador está desligado, o roteador pode não possuir uma associação válida entre:

192.168.1.50
↔
00-11-22-33-44-55

Essa relação normalmente depende de ARP.

Enquanto o computador está ligado, o roteador aprende essa associação.

Depois que ele desliga, a entrada pode permanecer temporariamente.

Algum tempo depois:

entrada ARP expira

O roteador tenta entregar:

192.168.1.50

mas não sabe mais qual endereço MAC deve receber o frame Ethernet.

Ele pode então enviar uma solicitação ARP.

O computador desligado não responde normalmente.

Resultado:

Magic Packet chega ao roteador
↓
roteador não consegue resolver o MAC
↓
pacote não chega à NIC
↓
PC não acorda

Por isso o WoL remoto pode funcionar por alguns minutos e depois parar

Esse é um dos sintomas mais interessantes do Wake-on-LAN remoto.

Imagine:

19:00
PC desligado

19:01
WoL remoto funciona

Depois:

23:00
WoL remoto não funciona

Nada aparentemente mudou.

Mas internamente pode ter acontecido:

entrada ARP válida
↓
tempo passa
↓
entrada ARP expira

Esse comportamento é uma pista muito forte.

Reserva DHCP não impede o ARP de expirar

Vamos reforçar porque essa confusão é comum.

Reserva DHCP:

MAC X
↓
receber sempre IP 192.168.1.50

ARP:

192.168.1.50
↓
qual é o MAC atual?

São funções diferentes.

Uma reserva DHCP não transforma automaticamente a entrada ARP em permanente.

IP fixo também não resolve sozinho

Podemos configurar manualmente:

IP:
192.168.1.50

Mas, com o computador desligado, o roteador ainda precisa saber que:

192.168.1.50
=
00-11-22-33-44-55

Portanto:

IP fixo
≠
ARP estático

ARP estático pode ajudar?

Alguns roteadores permitem criar uma associação estática:

192.168.1.50
↔
00-11-22-33-44-55

Nesse caso, o roteador não precisa reaprender continuamente essa relação.

Isso pode facilitar determinados cenários de WoL unicast.

Mas nem todo roteador doméstico oferece essa função.

E alguns equipamentos mostram algo chamado:

IP-MAC Binding

que pode possuir finalidade diferente dependendo do fabricante.

Leia a documentação antes de assumir que se trata de uma entrada ARP estática.

Outra estratégia: encaminhar para o broadcast

Em vez de mandar o pacote para:

192.168.1.50

algumas arquiteturas tentam encaminhá-lo para:

192.168.1.255

Assim:

Internet
↓
roteador
↓
broadcast da LAN
↓
todas as NICs recebem
↓
somente o MAC correto reage

Esse modelo evita depender diretamente de uma entrada ARP específica do PC.

Mas existe outro problema.

Muitos roteadores não permitem Port Forward para broadcast

É comum a interface do roteador aceitar apenas endereços como:

192.168.1.2
até
192.168.1.254

e recusar:

192.168.1.255

Isso pode ser intencional.

Broadcasts encaminhados de redes externas possuem implicações de segurança.

Por isso, não devemos presumir que qualquer roteador doméstico suportará WoL via broadcast vindo da WAN.

O que é directed broadcast?

Imagine uma rede:

192.168.1.0/24

O endereço:

192.168.1.255

representa o broadcast daquela sub-rede.

Um pacote destinado a esse endereço, mas vindo de outra rede, pode ser considerado um directed broadcast.

Por razões históricas de segurança, muitos roteadores bloqueiam esse tipo de encaminhamento.

Isso reduz riscos associados a amplificação e abuso de broadcasts.

Então abrir UDP 9 não garante WoL remoto

Exatamente.

Uma regra:

WAN UDP 9
↓
192.168.1.50 UDP 9

pode existir corretamente.

Mesmo assim, o processo pode falhar quando:

ARP expira

ou quando:

NIC não está ativa em S5

ou:

operadora usa CGNAT

ou:

roteador bloqueia o encaminhamento

ou:

firewall WAN impede o pacote

Antes de configurar WoL remoto, descubra se você possui IPv4 público

Esse passo é fundamental.

O endereço WAN mostrado pelo roteador pode ser algo como:

100.64.x.x

ou:

10.x.x.x

ou:

172.16.x.x até 172.31.x.x

ou:

192.168.x.x

Se o endereço WAN está em uma faixa privada ou compartilhada, pode existir outro nível de NAT antes do seu roteador.

Nesse cenário, uma simples regra de Port Forwarding no roteador doméstico pode não ser suficiente.

O que é CGNAT?

CGNAT significa:

Carrier-Grade NAT

A operadora compartilha endereços IPv4 públicos entre vários clientes.

De maneira simplificada:

seu PC
↓
seu roteador
↓
NAT da operadora
↓
Internet

Agora existem dois níveis de tradução.

Um pacote espontâneo vindo da Internet pode nem chegar ao seu roteador.

Faixa 100.64.0.0/10

Uma faixa muito associada a CGNAT é:

100.64.0.0
até
100.127.255.255

Ela foi reservada para espaço compartilhado entre operadora e clientes.

Se a interface WAN do roteador apresenta um endereço nessa faixa, isso é uma forte indicação de CGNAT.

Mas o diagnóstico correto deve considerar toda a topologia.

Como comparar o IP WAN com o IP visto na Internet?

A ideia é comparar:

IP WAN exibido no roteador

com:

IP público observado externamente

Se forem diferentes, pode haver:

• CGNAT;
• outro roteador antes do seu;
• modem em modo router;
• dupla NAT;
• outra camada intermediária.

Duplo NAT

Imagine:

Internet
↓
modem da operadora
192.168.0.1
↓
seu roteador
192.168.1.1
↓
PC
192.168.1.50

Agora existem dois roteadores fazendo NAT.

Para encaminhar um pacote da Internet até o PC, seria necessário considerar os dois equipamentos.

Isso é diferente de CGNAT porque o primeiro NAT ainda pode estar sob seu controle local.

DDNS resolve CGNAT?

Não.

DDNS resolve outro problema.

Dynamic DNS associa um nome a um endereço IP que pode mudar.

Exemplo conceitual:

meupc.exemplo
↓
200.x.x.x

Se amanhã o endereço público mudar:

201.x.x.x

o serviço atualiza o registro.

Assim você continua usando o nome.

Mas:

DDNS
≠
remove CGNAT

Se não existe caminho de entrada até sua rede, um nome DNS não cria esse caminho.

Quando DDNS é útil para Wake-on-LAN?

Quando você possui conectividade externa válida, mas o IP público muda periodicamente.

Em vez de memorizar:

200.123.45.67

você usa um hostname.

Isso facilita:

• VPN;
• acesso remoto;
• administração;
• automação.

Segurança: vale a pena deixar UDP 9 exposto?

Precisamos separar duas coisas.

Um Magic Packet clássico não carrega autenticação forte simplesmente por conter um MAC.

O endereço MAC não é segredo.

Se você expõe uma regra de entrada na Internet, cria uma superfície adicional de rede.

Por isso, quando existe alternativa melhor, não considero ideal transformar o WoL direto pela WAN na primeira escolha.

MAC não é senha

Essa ideia é importante.

O Magic Packet utiliza o endereço MAC como parte do padrão.

Mas:

MAC
≠
credencial secreta

Um endereço MAC pode ser descoberto em vários contextos.

Portanto, WoL clássico não deve ser tratado como mecanismo de autenticação.

Acordar o PC não significa invadi-lo

Também é importante não exagerar.

Conseguir gerar um wake não entrega automaticamente:

senha do Windows
arquivos
Área de Trabalho

Mas pode permitir que uma máquina que estava desligada volte a ficar online.

Por isso, a arquitetura deve ser planejada com segurança.

Uma solução geralmente melhor: VPN

Em vez de expor diretamente o Magic Packet pela Internet, podemos criar uma VPN para entrar na rede doméstica ou empresarial.

Fluxo:

celular/notebook remoto
↓
VPN autenticada
↓
rede local
↓
Magic Packet
↓
PC acorda

Isso muda bastante o cenário.

O dispositivo remoto passa a possuir acesso controlado à infraestrutura interna.

Mas qualquer VPN permite broadcast WoL?

Não necessariamente.

Dependendo da implementação, clientes VPN podem ficar em outra sub-rede.

Exemplo:

LAN:
192.168.1.0/24

VPN:
10.8.0.0/24

O broadcast da rede VPN não será automaticamente o broadcast da LAN.

Então ainda precisamos verificar como o servidor VPN e o roteador tratam o WoL.

Roteador com função Wake-on-LAN integrada

Uma das soluções mais elegantes é quando o próprio roteador possui uma função de WoL.

Fluxo:

usuário remoto
↓
acessa roteador com autenticação
↓
roteador já está dentro da LAN
↓
roteador envia Magic Packet localmente

Agora o pacote nasce dentro da própria rede.

Isso reduz várias dificuldades relacionadas a encaminhar broadcast diretamente da WAN.

Por que essa abordagem é interessante?

Porque o roteador conhece a rede local.

Ele pode enviar:

Magic Packet

diretamente para o segmento correto.

Você não precisa necessariamente expor um UDP destinado a um computador desligado.

Outro dispositivo sempre ligado pode funcionar como “agente de WoL”

Imagine possuir:

NAS
servidor doméstico
mini PC
roteador avançado

sempre ligado.

Você acessa esse equipamento remotamente e manda que ele envie o Magic Packet dentro da LAN.

Arquitetura:

Internet
↓
VPN
↓
dispositivo sempre ligado
↓
Wake-on-LAN local
↓
PC

Essa costuma ser uma arquitetura muito mais controlável.

NAS como emissor de Wake-on-LAN

Diversos NAS e sistemas de administração de rede possuem funções relacionadas a WoL.

Isso pode ser útil em escritórios:

NAS ligado 24h
↓
estação de trabalho desligada
↓
administrador acessa infraestrutura
↓
NAS envia WoL
↓
estação inicia

Raspberry Pi ou mini servidor

Em laboratórios e redes administradas, um pequeno equipamento sempre ligado pode executar a mesma função.

O importante não é o dispositivo específico.

O princípio é:

não atravessar diretamente toda a Internet com o Magic Packet

e sim:

entrar de maneira autenticada
↓
gerar WoL dentro da LAN

Tailscale, WireGuard e outras VPNs

Tecnologias VPN modernas podem facilitar acesso remoto seguro a dispositivos e redes.

Porém, a capacidade específica de gerar Wake-on-LAN para outro equipamento depende da configuração e da topologia.

Não devemos assumir:

VPN conectou
=
broadcast WoL funciona

Às vezes é necessário usar um dispositivo da LAN como intermediário.

WoL com um roteador Mesh

Em redes Mesh podemos ter:

Internet
↓
roteador principal
↓
nó Mesh
↓
Ethernet
↓
PC

O Magic Packet precisa atravessar a arquitetura do sistema Mesh.

Alguns produtos tratam broadcasts e dispositivos cabeados de forma transparente.

Outros possuem particularidades.

Por isso, teste primeiro:

dispositivo dentro da LAN
↓
Magic Packet
↓
PC conectado ao nó Mesh

antes de adicionar acesso externo.

CGNAT e VPN com conexão de saída

Uma arquitetura baseada em conexão iniciada de dentro da rede pode funcionar mesmo quando o Port Forward tradicional não é possível.

Isso acontece porque:

rede local
↓
inicia túnel para serviço externo

em vez de esperar uma conexão não solicitada entrando pela operadora.

Essa abordagem é comum em várias soluções modernas de VPN e acesso remoto.

IPv6 muda o cenário?

IPv6 elimina a necessidade tradicional de NAT em muitos cenários, mas isso não significa que podemos simplesmente expor tudo.

O firewall continua essencial.

Além disso, Wake-on-LAN clássico continua relacionado ao mecanismo de wake da interface e ao Magic Packet.

Ter IPv6 global não resolve automaticamente:

hardware
driver
estado de energia

WoL pela Internet e firewall

Se você optar por uma arquitetura com encaminhamento direto, considere que existe:

firewall WAN
↓
regra NAT
↓
LAN

Não é recomendável abrir portas aleatoriamente “para testar”.

Primeiro determine exatamente:

qual protocolo
qual porta
qual origem
qual destino

e, se possível, restrinja o acesso.

Posso limitar a origem?

Alguns firewalls permitem criar regras como:

permitir UDP 9
somente do IP X

Isso pode reduzir exposição.

Mas endereços de origem também podem mudar, especialmente em conexões móveis.

Por isso, autenticação via VPN costuma oferecer um modelo mais robusto.

Diagnóstico do WoL remoto

Vamos construir uma sequência lógica.

Primeiro confirme:

WoL local funciona?

Se:

não

não continue.

Corrija a LAN.

Se:

sim

avance.

Etapa 1 — Verifique o endereço WAN

Entre no roteador.

Anote:

WAN IPv4

Compare com o endereço público externo.

Se houver diferença, investigue:

CGNAT
dupla NAT
modem roteador

Etapa 2 — Verifique se o serviço externo realmente chega ao roteador

Se uma regra de Port Forwarding foi criada, precisamos saber se o tráfego externo alcança a interface WAN.

Em roteadores avançados, logs ou captura de pacotes podem ajudar.

A pergunta é:

Magic Packet chegou à WAN?

Etapa 3 — Verifique o NAT

Depois:

a regra encaminhou?

Se não:

• porta errada;
• protocolo errado;
• regra desabilitada;
• destino errado;
• firewall bloqueando.

Etapa 4 — Verifique ARP

Se o destino interno é unicast:

192.168.1.50

observe se o roteador ainda possui uma associação válida com o MAC.

Se o WoL funciona imediatamente após desligar e falha depois, suspeite dessa etapa.

Etapa 5 — Compare com broadcast

Se o equipamento suporta encaminhamento controlado para broadcast, o teste pode mostrar se o problema estava relacionado à resolução ARP do host desligado.

Nem todo roteador permite isso.

Etapa 6 — Teste um emissor interno

Use um equipamento que permanece ligado dentro da LAN.

Se:

emissor interno
↓
WoL sempre funciona

mas:

Internet
↓
WoL falha

fica claro que o problema está antes do host alvo.

Diagnóstico por sintomas

Funciona na LAN, mas nunca pela Internet

Investigue:

CGNAT
dupla NAT
firewall WAN
NAT
porta
roteador

Funciona remotamente logo após desligar, mas falha horas depois

Investigue:

ARP

principalmente quando utiliza encaminhamento unicast.

Funciona remoto em suspensão, mas não após desligamento

Agora podemos ter duas camadas:

rede externa
+
estado de energia

Teste localmente o S5 antes de culpar a Internet.

Funciona por VPN, mas não por Port Forwarding

Isso sugere que a infraestrutura interna está correta e a diferença está no caminho WAN/NAT/firewall.

Funciona quando estou no Wi-Fi de casa, mas não no 5G

Isso normalmente indica:

WoL local OK
acesso externo não resolvido

Não use DMZ para “resolver” Wake-on-LAN

Colocar um dispositivo em:

DMZ

do roteador apenas para tentar WoL é uma abordagem ruim.

Além de não resolver necessariamente ARP ou CGNAT, pode aumentar significativamente a exposição do dispositivo.

Não desative o firewall inteiro

Outro erro comum:

WoL não funciona
↓
desabilitar todos os firewalls

Isso raramente é um diagnóstico inteligente.

Mude uma variável por vez e determine em qual etapa o pacote desaparece.

Arquitetura recomendada para acesso remoto frequente

Para um ambiente doméstico ou pequeno escritório, uma arquitetura robusta pode ser:

Internet
↓
VPN
↓
roteador/NAS/mini servidor sempre ligado
↓
Magic Packet local
↓
PC
↓
serviço de acesso remoto

Essa estrutura separa claramente duas funções:

segurança de acesso à rede

e:

Wake-on-LAN

Depois que o PC acorda, quanto tempo esperar?

O Wake-on-LAN apenas inicia o processo.

Depois o Windows ainda precisa:

iniciar
↓
carregar drivers
↓
obter rede
↓
iniciar serviços
↓
disponibilizar acesso remoto

Dependendo do computador, isso pode levar alguns segundos ou mais.

Não confunda:

Magic Packet funcionou

com:

serviço remoto já está disponível

Como confirmar que o PC realmente acordou?

Podemos verificar:

ping

quando o host responde a ICMP.

Também podemos testar uma porta ou serviço específico.

No PowerShell:

Test-NetConnection 192.168.1.50

Para um serviço específico:

Test-NetConnection 192.168.1.50 -Port 3389

Esse exemplo verifica conectividade TCP com a porta informada.

Naturalmente, isso só faz sentido se o serviço correspondente estiver autorizado e configurado.

Ping pode estar bloqueado

Se:

ping falha

não conclua automaticamente:

PC continua desligado

O firewall pode bloquear ICMP.

Prefira validar o serviço que realmente será utilizado.

Wake-on-LAN e Área de Trabalho Remota

Uma sequência possível é:

Magic Packet
↓
PC inicia
↓
rede sobe
↓
RDP inicia
↓
usuário conecta

Mas o Wake-on-LAN não configura nem protege o RDP.

São tecnologias independentes.

Nunca exponha serviços remotos à Internet sem avaliar adequadamente a segurança.

Wake-on-LAN e acesso remoto por software

O mesmo princípio vale para outras ferramentas.

O WoL resolve:

ligar

O software de acesso remoto resolve:

controlar

Um não substitui o outro.

Vale deixar o PC ligado o tempo todo?

Depende do caso.

WoL é útil justamente quando não queremos manter a estação ativa permanentemente.

Mas, se o computador precisa responder a serviços continuamente, talvez a melhor arquitetura seja outra.

Tecnologia deve seguir a necessidade, não o contrário.

Wake-on-LAN funciona com notebook na bateria?

Depende muito do fabricante e do estado de energia.

Notebooks podem aplicar políticas agressivas para economizar bateria.

Algumas funções de wake podem funcionar apenas:

conectado ao carregador

ou somente em determinados estados.

Consulte as especificações do equipamento.

Dock USB-C pode complicar WoL

Imagine:

notebook
↓
USB-C dock
↓
Ethernet

Agora a interface Ethernet pode pertencer ao dock.

O suporte a WoL dependerá de:

• notebook;
• firmware;
• dock;
• controlador Ethernet;
• driver;
• estado de energia.

Não presuma que o comportamento será igual ao de uma NIC Ethernet integrada.

Adaptador USB Ethernet e Wake-on-LAN

O mesmo raciocínio vale.

Uma placa Ethernet USB pode funcionar perfeitamente enquanto o Windows está ativo, mas perder alimentação ou capacidade de wake quando o computador entra em determinado estado.

Por isso:

Ethernet funciona

não significa necessariamente:

WoL funciona

O melhor diagnóstico continua sendo por camadas

Não tente resolver Wake-on-LAN remoto com dez alterações simultâneas.

Use esta sequência:

1. hardware suporta?
2. BIOS/UEFI habilitada?
3. driver configurado?
4. WoL local funciona suspenso?
5. WoL local funciona hibernado?
6. WoL local funciona desligado?
7. Magic Packet é gerado corretamente?
8. IP público existe?
9. CGNAT existe?
10. NAT/firewall permitem o tráfego?
11. ARP continua válido?
12. roteador suporta estratégia adequada?
13. VPN ou emissor interno seria melhor?

Essa metodologia transforma um problema aparentemente imprevisível em uma investigação objetiva.

Atendimento mediante agendamento, com possibilidade de suporte remoto ou visita técnica conforme o problema e a localização.