Wake-on-LAN por VPN non funciona? A difusión nunca cruza

Pos a durmir o equipo da oficina, marcas a VPN desde casa, e segue apagado. O túnel está levantado, os recursos compartidos responden, e a páxina wake-on-LAN do router informa de que enviou a petición. Cada sinal visible di que a rede está ben, e por iso mesmo este caso desconcerta: a trama que espertaría a máquina nunca chega ao segmento onde vive.

Os síntomas apuntan á subrede, non ao túnel

O ping falla contra o host durmido, e esa parte é normal. Un equipo en suspensión non ten pila IP en marcha, así que non pode responder a ARP nin a ICMP, e ningunha configuración do túnel cambia iso. A proba útil é se esperta un segundo equipo na mesma LAN, e se a páxina de wake do propio router funciona para un host conectado a el.

Cando a proba no mesmo segmento sae ben, o fallo é de alcance. O emisor que usas vive na interface da VPN, e o paquete que constrúe é unha difusión para a ligazón local, así que sae pola interface equivocada ou non sae. O túnel non está roto; está levando o tipo equivocado de tráfico. Averigua que interface escolle o emisor antes de cambiar un só axuste do router.

Un magic packet é unha trama, non un servizo

A carga útil comeza cunha cabeceira fixa de seis bytes 0xFF, despois o enderezo de hardware da tarxeta destino repetido dezaseis veces, despois un contrasinal SecureOn opcional de catro bytes. Os emisores adoitan envolvela en UDP cara ao porto 7 ou o porto 9, pero o número de porto é unha convención compartida entre emisor e tarxeta, non un servizo á escoita ao que conectarse. Nada escoita, e nada responde.

O que esperta a máquina é a interface de rede, que mantén unha pequena cantidade de circuítos alimentados desde o raíl de espera mentres o resto do sistema está apagado. Por iso o axuste ten que sobrevivir a un corte de corrente completo e tamén á suspensión: unha placa que corta a alimentación de espera ao apagarse xa non ten tarxeta para recibir nada.

Por que un túnel encamiñado non o pode entregar

Unha interface VPN encamiñada é unha ligazón IP punto a punto entre dous enderezos de túnel. Existe para levar paquetes dirixidos ao par, e por iso ping, SSH e recursos compartidos se comportan con normalidade a través dela. Unha trama de difusión non vai dirixida a ese par, e o enderezo de difusión limitada nunca se reenvía por rutina nun router.

Reenviar unha difusión dirixida a unha subrede é unha capacidade deliberada do router que a maioría das configuracións por defecto desactivan, e mesmo entón entrega a esa subrede e non a unha tarxeta durmida concreta. Un host durmido tampouco pode responder a ARP, así que un router que intenta resolver o enderezo destino antes de reenviar descarta a trama mentres agarda unha resposta que nunca chegará. Unha entrada de ligazón estática arranxa esa parte e deixa intacto o problema de alcance da difusión. Dúas restricións distintas, pois, e quitar unha non fai nada pola outra.

Tres ubicacións que si chegan á tarxeta

Calquera disposición viable pon a trama no segmento do destino, e difiren en canto perturban a rede:

1. Pon un dispositivo sempre acendido no segmento destino. Un router, un NAS ou unha pequena caixa Linux que siga alimentada pode emitir a trama localmente en canto a alcanzas polo túnel, e nada da VPN cambia.
2. Deixa que o router emita a trama. Moitos firmwares ofrecen unha páxina de wake que envía desde a ponte LAN, o que funciona mentres o destino estea nesa ponte e non detrás dun segundo router.
3. Pontea os sitios cun túnel de tipo TAP cando as difusións teñan que cruzar de verdade. Iso fusiona dous dominios de difusión, con tormentas de difusión, un único plano de enderezamento e cada protocolo de descuberta vendo ambos os sitios á vez.

A primeira opción é a preferible para unha soa máquina. A terceira é unha decisión de deseño de rede con custo permanente, así que trátaa como tal e non como unha solución rápida para un só escritorio.

Anota que axudante emite a trama e en que ponte ou VLAN está. Un axudante que emite na interface equivocada produce unha captura perfecta e unha máquina que nunca esperta, e esa combinación custa unha tarde.

Verifica o envío antes de culpar o cliente

Comproba primeiro a tarxeta destino, porque ningún emisor pode espertar unha tarxeta que non está armada. A orde de abaixo le os modos de wake admitidos e o actual, onde un valor actual de g significa que o magic packet está activado:

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

Executa a captura no axudante mentres ocorre o envío, e léaa en vez de dar o éxito por feito. Unha trama que sae da ponte correcta coa MAC de difusión é a única proba de que o envío funcionou; se a captura está baleira, o emisor escolleu outra interface e o resto da proba non significa nada. Un emisor que constrúe unha trama crua en lugar dun datagrama UDP non encaixa nese filtro, así que mira que forma usa a túa ferramenta antes de concluír que non se enviou nada.

En Windows a comprobación equivalente da tarxeta é powercfg /devicequery wake_armed, que lista os dispositivos autorizados a espertar o sistema. Un adaptador de rede que falte nesa lista ignorará cada paquete que se lle envíe, por moi correcta que se vexa a trama no cable.

Despois confirma o propio espertar e o seguimento. Un equipo que arranca pero segue inalcanzable polo nome necesita un enderezo estático e un rexistro DNS, porque a resolución de nomes por difusión tampouco cruza o túnel. O espertar sen fíos é unha capacidade aparte e moito menos fiable ca versión por cable, así que próbaa no mesmo segmento antes de meter a VPN no asunto. Apunta no ticket o nome da interface e o host do axudante, porque o seguinte fallo adoita ir dos mesmos dous datos.