Wake-on-LAN pela VPN não funciona? O broadcast nunca atravessa

Você põe a máquina do escritório a dormir, disca a VPN de casa, e ela continua desligada. O túnel está de pé, os compartilhamentos de ficheiros respondem, e a página wake-on-LAN do router informa que enviou o pedido. Todos os sinais visíveis dizem que a rede está bem, e é exatamente por isso que este caso confunde: a trama que acordaria a máquina nunca chega ao segmento onde ela vive.

Os sintomas apontam para a sub-rede, não para o túnel

O ping falha para o anfitrião adormecido, e essa parte é normal. Uma máquina em suspensão não tem pilha IP a correr, logo não pode responder a ARP nem a ICMP, e nenhuma configuração do túnel muda isso. O teste útil é saber se uma segunda máquina na mesma LAN acorda, e se a página de wake do próprio router funciona para um anfitrião ligado a ele.

Assim que o teste no mesmo segmento passa, a falha é de alcance. O emissor que usa vive na interface da VPN, e o pacote que constrói é um broadcast para a ligação local, por isso sai pela interface errada ou não sai de todo. O túnel não está avariado; está a transportar o tipo errado de tráfego. Descubra que interface o emissor escolhe antes de alterar uma única definição do router.

Um magic packet é uma trama, não um serviço

A carga útil começa com um cabeçalho fixo de seis bytes 0xFF, depois o endereço de hardware da placa de destino repetido dezasseis vezes, depois uma palavra-passe SecureOn opcional de quatro bytes. Os emissores costumam envolvê-la em UDP para a porta 7 ou a porta 9, mas o número da porta é uma convenção partilhada entre emissor e placa, não um serviço à escuta ao qual se ligar. Nada escuta, e nada responde.

O que acorda a máquina é a interface de rede, que mantém uma pequena quantidade de circuitos alimentados pelo rail de espera enquanto o resto do sistema está desligado. É por isso que a definição tem de sobreviver a uma perda total de energia e também à suspensão: uma placa que corta a alimentação de espera ao desligar já não tem placa para receber nada.

Porque um túnel encaminhado não o consegue entregar

Uma interface VPN encaminhada é uma ligação IP ponto a ponto entre dois endereços de túnel. Existe para transportar pacotes endereçados ao par, e é por isso que ping, SSH e partilhas de ficheiros se comportam normalmente através dela. Uma trama de broadcast não é endereçada a esse par, e o endereço de broadcast limitado nunca é reencaminhado por rotina num router.

Reencaminhar um broadcast dirigido a uma sub-rede é uma capacidade deliberada do router que a maioria das configurações predefinidas desativa, e mesmo assim entrega a essa sub-rede e não a uma placa adormecida específica. Um anfitrião adormecido também não pode responder a ARP, por isso um router que tenta resolver o endereço de destino antes de reencaminhar descarta a trama enquanto espera por uma resposta que nunca chega. Uma entrada de ligação estática resolve essa parte e deixa intacto o problema de alcance do broadcast. Duas restrições distintas, portanto, e remover uma não faz nada pela outra.

Três colocações que chegam mesmo à placa

Qualquer disposição viável põe a trama no segmento do destino, e diferem na quantidade de rede que perturbam:

1. Coloque um dispositivo sempre ligado no segmento de destino. Um router, um NAS ou uma pequena caixa Linux que fique alimentada pode emitir a trama localmente assim que a alcançar pelo túnel, e nada da VPN muda.
2. Deixe o router emitir a trama. Muitos firmwares oferecem uma página de wake que envia a partir da ponte LAN, o que funciona desde que o destino esteja nessa ponte e não atrás de um segundo router.
3. Ligue os locais com um túnel do tipo TAP quando os broadcasts tiverem mesmo de atravessar. Isso funde dois domínios de broadcast, com tempestades de broadcast, um único plano de endereçamento e todos os protocolos de descoberta a ver ambos os locais ao mesmo tempo.

A primeira opção é a preferível para uma só máquina. A terceira é uma decisão de desenho de rede com custo permanente, por isso trate-a como tal e não como uma correção rápida para um posto de trabalho.

Registe qual auxiliar emite a trama e em que ponte ou VLAN está. Um auxiliar que emite na interface errada produz uma captura perfeita e uma máquina que nunca acorda, e essa combinação custa uma tarde.

Verifique o envio antes de culpar o cliente

Confirme primeiro a placa de destino, porque nenhum emissor acorda uma placa que não está armada. O comando abaixo lê os modos de wake suportados e o atual, em que um valor atual de g significa que o magic packet está ativado:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

Corra a captura no auxiliar enquanto o envio acontece, e leia-a em vez de assumir o sucesso. Uma trama que sai da ponte correta com o MAC de broadcast é a única prova de que o envio funcionou; se a captura estiver vazia, o emissor escolheu outra interface e o resto do teste não significa nada. Um emissor que constrói uma trama crua em vez de um datagrama UDP não corresponde a esse filtro, por isso verifique que forma a sua ferramenta usa antes de concluir que nada foi enviado.

No Windows, a verificação equivalente da placa é powercfg /devicequery wake_armed, que lista os dispositivos autorizados a acordar o sistema. Um adaptador de rede ausente dessa lista ignora todos os pacotes que lhe sejam enviados, por muito correta que a trama pareça no cabo.

Depois confirme o próprio acordar e o seguimento. Uma máquina que arranca mas continua inalcançável por nome precisa de um endereço estático e de um registo DNS, porque a resolução de nomes por broadcast continua a não atravessar o túnel. O acordar sem fios é uma capacidade separada e muito menos fiável do que a versão por cabo, por isso teste-a no mesmo segmento antes de envolver a VPN. Escreva o nome da interface e o anfitrião do auxiliar no pedido, porque a falha seguinte costuma envolver os mesmos dois factos.