Svegliare un PC di casa addormentato via VPN: da dove arriva il pacchetto

Ti connetti, il router risponde e il desktop resta al buio. Il tunnel è a posto; il pacchetto che avrebbe dovuto svegliare la macchina non ha mai raggiunto il segmento dove la macchina ascolta. Ripercorrendo il cammino all’indietro dal router si vede dove muore.

Tre dispositivi hanno tre compiti. Confonderli è la ragione abituale per cui un tentativo di risveglio gira all’infinito.

Parti dal client remoto e segui il percorso

Da una rete d’albergo ti connetti al router di casa, che è l’unico endpoint sempre attivo dell’immagine. Una richiesta di risveglio scritta sul portatile diventa traffico di tunnel ordinario, indirizzato alla destinazione che hai indicato. Quella destinazione decide tutto ciò che segue.

Se l’hai inviata all’indirizzo LAN del router di casa sulla porta del magic packet, il router può accettare il datagramma e non emettere mai un frame sul segmento di casa, perché lì nulla ascolta quella porta. Se la trasmetti in broadcast dentro il tunnel, si ferma all’interfaccia del tunnel. Un tunnel instradato non è un’estensione di livello 2 del cablaggio di casa. Segui il percorso salto per salto e il vicolo cieco diventa evidente.

Il controllo che lo risolve richiede un comando dal lato remoto e uno dal lato casa. Invia la richiesta, poi osserva il segmento di casa per il frame.

Sposta il mittente sul segmento di casa

Il router può fare il risveglio da solo una volta che ti sei autenticato attraverso il tunnel. OpenWrt documenta un servizio Wake-on-LAN che gira sul dispositivo ed emette il frame localmente, ed è esattamente la forma necessaria: autenticazione remota fuori, trasmissione locale dentro.

Questa disposizione tiene anche la funzione di risveglio fuori da internet pubblico. Nulla di nuovo viene esposto a internet, perché il trigger viaggia sulla VPN di cui ti fidi già. L’alternativa, un servizio di risveglio con porta inoltrata, scambia una piccola comodità con un endpoint rivolto a internet che chiunque può sondare.

La dipendenza circolare merita di essere nominata chiaramente. Un client VPN installato sul desktop non può svegliare quel desktop, perché il processo del client ha bisogno della macchina in funzione. Tieni il punto d’ingresso remoto sul router o su un’altra scatola sempre attiva, e lascia che il desktop sia solo un bersaglio.

Verifica il bersaglio prima di dare la colpa al tunnel

Questa parte la decide l’hardware, non la VPN, e lo stato di alimentazione la decide per primo. L’adattatore deve supportare il risveglio, il firmware deve lasciare l’adattatore alimentato in sospensione e il sistema operativo deve essere configurato per consentirlo. Una macchina sospesa è un caso diverso da una spenta, ed entrambe differiscono da una macchina con l’alimentazione staccata alla parete. Chiarisci quello stato prima di affrontare il resto della lista.

Leggi l’indirizzo hardware dall’adattatore che riceverà davvero il frame. Un desktop con Ethernet e Wi-Fi ha spesso due indirizzi, e solo uno di essi potrebbe essere in grado di svegliare. Il risveglio wireless è una capacità separata con i propri requisiti firmware, quindi un risveglio Ethernet che funziona non dice nulla sul risveglio via Wi-Fi.

Dimostra prima il percorso locale. Invia il magic packet da un altro dispositivo sullo stesso switch e guarda la macchina salire. Se fallisce, nessuna quantità di debug del tunnel aiuterà, e il guasto è nel firmware, nelle impostazioni dell’adattatore o nello stato di alimentazione.

Dopo la ripresa, connettiti al servizio che volevi

Svegliare non è accesso remoto. Quando la macchina riprende, deve ancora avviare i suoi servizi, ottenere un indirizzo e accettare la sessione che ti serve davvero. Dalle tempo per raggiungere quello stato prima di concludere che il risveglio è fallito.

# remote side: trigger the wake through the already-authenticated tunnel
ssh [email protected] 'wol -i br-lan 3c:7a:8f:2b:11:04'

# home side: is the target answering on the LAN?
ping -c 3 10.10.0.42
arp -n 10.10.0.42

La riga arp è quella utile. Una voce che passa da incompleta a un vero indirizzo hardware significa che la macchina è ripartita e ha risposto; una richiesta che non si risolve mai rimanda al passo di risveglio, non al servizio che cercavi di raggiungere.

Separa le fasi nei tuoi appunti: risveglio, avvio, servizio. Un guasto nella seconda fase sembra identico a un guasto nella prima da una finestra di chat, e solo l’evidenza locale li distingue.