Wake-on-LAN su VPN non funziona? Il broadcast non attraversa mai il tunnel

Metti in sospensione la macchina dell'ufficio, componi la VPN da casa, e resta spenta. Il tunnel è attivo, le condivisioni file rispondono, e la pagina wake-on-LAN del router riporta di aver inviato la richiesta. Ogni segnale visibile dice che la rete è a posto, ed è proprio per questo che il caso è confuso: il frame che dovrebbe svegliare la macchina non raggiunge mai il segmento in cui si trova.

I sintomi indicano la sottorete, non il tunnel

Il ping fallisce verso l'host addormentato, e quella parte è normale. Una macchina in standby non ha uno stack IP attivo, quindi non può rispondere ad ARP né a ICMP, e nessuna configurazione del tunnel cambia la cosa. Il test utile è se una seconda macchina sulla stessa LAN si sveglia, e se la pagina di wake del router funziona per un host collegato ad esso.

Superato il test sullo stesso segmento, il guasto è di ambito. Il mittente che usi vive sull'interfaccia VPN, e il pacchetto che costruisce è un broadcast per il collegamento locale, quindi esce dall'interfaccia sbagliata o non esce affatto. Il tunnel non è rotto; sta trasportando il tipo sbagliato di traffico. Scopri quale interfaccia sceglie il mittente prima di cambiare una sola impostazione del router.

Un magic packet è un frame, non un servizio

Il payload inizia con un header fisso di sei byte 0xFF, poi l'indirizzo hardware della scheda di destinazione ripetuto sedici volte, poi una password SecureOn opzionale di quattro byte. I mittenti lo incapsulano di solito in UDP verso la porta 7 o la porta 9, ma il numero di porta è una convenzione condivisa tra mittente e scheda, non un listener a cui connettersi. Niente è in ascolto, e niente risponde.

Ciò che sveglia la macchina è l'interfaccia di rete, che mantiene una piccola quantità di circuiti alimentati dal rail di standby mentre il resto del sistema è spento. Per questo l'impostazione deve sopravvivere sia a una perdita di corrente totale sia alla sospensione: una scheda madre che toglie l'alimentazione di standby allo spegnimento non ha più scheda per ricevere qualcosa.

Perché un tunnel instradato non può consegnarlo

Un'interfaccia VPN instradata è un collegamento IP punto a punto tra due indirizzi di tunnel. Esiste per trasportare pacchetti indirizzati al peer, ed è per questo che ping, SSH e condivisioni file si comportano normalmente attraverso di essa. Un frame di broadcast non è indirizzato a quel peer, e l'indirizzo di broadcast limitato non viene inoltrato d'ufficio da un router.

Inoltrare un broadcast diretto a una sottorete è una capacità deliberata del router che la maggior parte delle configurazioni predefinite disattiva, e anche allora consegna a quella sottorete e non a una scheda addormentata specifica. Un host addormentato non può nemmeno rispondere ad ARP, quindi un router che tenta di risolvere l'indirizzo di destinazione prima di inoltrare scarta il frame mentre aspetta una risposta che non arriverà mai. Una voce di binding statica risolve quella parte e lascia intatto il problema di ambito del broadcast. Due restrizioni distinte, quindi, e rimuoverne una non fa nulla per l'altra.

Tre posizionamenti che raggiungono davvero la scheda

Ogni disposizione funzionante mette il frame sul segmento della destinazione, e differiscono per quanto disturbano la rete:

1. Metti un dispositivo sempre acceso sul segmento di destinazione. Un router, un NAS o un piccolo box Linux che resta alimentato può emettere il frame localmente una volta raggiunto attraverso il tunnel, e nulla del VPN cambia.
2. Lascia che sia il router a emettere il frame. Molti firmware offrono una pagina di wake che invia dal bridge LAN, il che funziona finché la destinazione sta su quel bridge e non dietro un secondo router.
3. Ponte i siti con un tunnel di tipo TAP quando i broadcast devono davvero attraversare. Questo unisce due domini di broadcast, con tempeste di broadcast, un unico piano di indirizzamento e ogni protocollo di discovery che vede entrambi i siti insieme.

La prima opzione è quella da preferire per una singola macchina. La terza è una decisione di progettazione di rete con costo continuo, quindi trattala come tale e non come una soluzione rapida per un solo desktop.

Annota quale helper emette il frame e su quale bridge o VLAN si trova. Un helper che emette sull'interfaccia sbagliata produce una cattura perfetta e una macchina che non si sveglia mai, e quella combinazione costa un pomeriggio.

Verifica l'invio prima di dare la colpa al client

Controlla prima la scheda di destinazione, perché nessun mittente può svegliare una scheda che non è armata. Il comando qui sotto legge le modalità di wake supportate e quelle correnti, dove un valore corrente di g significa che il magic packet è attivo:

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

Esegui la cattura sull'helper mentre avviene l'invio, e leggila invece di dare per scontato il successo. Un frame che lascia il bridge giusto con l'indirizzo MAC di broadcast è l'unica prova che l'invio ha funzionato; se la cattura è vuota, il mittente ha scelto un'altra interfaccia e il resto del test non ha senso. Un mittente che costruisce un frame grezzo invece di un datagramma UDP non corrisponde a quel filtro, quindi controlla quale forma usa il tuo strumento prima di concludere che non è stato inviato nulla.

Su Windows il controllo equivalente della scheda è powercfg /devicequery wake_armed, che elenca i dispositivi autorizzati a svegliare il sistema. Un adattatore di rete assente da quell'elenco ignorerà ogni pacchetto inviato, per quanto corretto appaia il frame sul cavo.

Poi conferma il risveglio stesso e il seguito. Una macchina che si accende ma resta irraggiungibile per nome ha bisogno di un indirizzo statico e di un record DNS, perché la risoluzione dei nomi via broadcast continua a non attraversare il tunnel. Il risveglio wireless è una capacità separata e molto meno affidabile della versione cablata, quindi provala sullo stesso segmento prima ancora di tirare in mezzo il VPN. Scrivi il nome dell'interfaccia e l'host dell'helper nel ticket, perché il guasto successivo riguarda di solito gli stessi due fatti.