Archivi tag: wake on lan

OpenVPN e WOL: accendere un PC da remoto attraverso un tunnel VPN

Recentemente mi è stato chiesto se fosse possibile inoltrare un magic packet mediante un tunnel VPN, in modo da accendere un PC da remoto senza forwardare porte aggiuntive sul router di destinazione. Ho quindi scaricato questo programma (free) ed ho subito iniziato i test.

La configurazione del suddetto programma è la seguente:

wol

In particolare, l’IP della workstation che voglio avviare da remoto è 192.168.1.5 e la subnet mask scelta è 255.255.255.255 (questo perchè la subnet della workstation è differente da quella del mio PC, quindi il traffico broadcast di livello 3 viene banalmente droppato dal mio router).

Tirando su uno sniffer sul VPN concentrator remoto:

user@vpn-concentrator:~$ sudo tcpdump -nn -i tun0

ho ottenuto il seguente output (dopo l’invio del magic packet):

17:17:52.386074 IP 192.168.114.2.61234 > 192.168.1.5.9: UDP, length 102
17:17:55.383997 IP 192.168.114.1 > 192.168.114.2: ICMP host 192.168.1.5 unreachable, length 138

ovvero l’interfaccia locale del suddetto VPN concentrator mi ha risposto con un pacchetto ICMP host unreachable.

Dando un’occhiata alla tabella ARP del server in questione ho notato che, essendo la workstation spenta ormai da tempo, non era presente nessuna entry ad essa correlata:

user@vpn-concentrator:~$ arp -a
? (192.168.1.7) associato a <incompleto> su eth0
? (192.168.1.14) associato a <incompleto> su eth0
? (192.168.1.5) associato a <incompleto> su eth0

Ho quindi creato una entry statica mediante il comando:

user@vpn-concentrator:~$ sudo arp -s 192.168.1.5 50:46:5d:54:07:76

ed il successivo invio di un magic packet ha finalmente avuto esito positivo (la macchina si è avviata ed ha iniziato a rispondere ai ping, come si evince dal tracciato tcpdump sottostante):

17:20:23.253400 IP 192.168.114.2.60731 > 192.168.1.5.9: UDP, length 102
17:20:39.211323 IP 192.168.114.2 > 192.168.1.5: ICMP echo request, id 1, seq 34, length 40
17:20:43.815485 IP 192.168.114.2 > 192.168.1.5: ICMP echo request, id 1, seq 35, length 40
17:20:43.815819 IP 192.168.1.5 > 192.168.114.2: ICMP echo reply, id 1, seq 35, length 40

Naturalmente tale settaggio non è più attivo dopo un eventuale riavvio del server. Per renderlo quindi “permanente” occorre modificare il file /etc/rc.local aggiungendo la seguente direttiva:

arp -s 192.168.1.5 50:46:5d:54:07:76

Alla prossima.

Wake on LAN su minipc ASUS at-3iont-i

Premesso che il BIOS installato sulla mobo in questione presenta numerose limitazioni, ho deciso comunque di provare ad abilitare il Wake On LAN sul mio server casalingo (Debian).

Per prima cosa, ho provato ad individuare la voce del BIOS che mi consentisse di abilitare la suddetta funzionalità. Purtroppo però, la specifica versione di software presente sulla mia scheda madre non consente di attivare esplicitamente il WOL dalla scheda Gigabit Ethernet integrata, cosa che mi ha lasciato a dir poco sbalordito.

Nonostante ciò è comunque possibile:

1) abilitare il Wake dopo la pressione di un determinato tasto della keyboard PS2 (funzione testata da me personalmente e funzionante);

2) abilitare il Wake da mouse PS2;

3) abilitare il Wake da interfaccia PCI-Express;

4) schedulare il Wake in una data/ora ben precisa.

Ma queste opzioni non includono, ovviamente, il WOL da scheda di rete integrata.

Ho dunque creato uno scrip che consentisse di attivare la suddetta funzione, utilizzando un tool esterno, ovvero ethtool.

Per installarlo è sufficiante digitare:

nightfly@nightbox:~$ sudo apt-get install ethtool

Ad installazione completata, creiamo un file di testo vuoto:

nightfly@nightbox:~$ sudo nano autowol

il cui contenuto dovrà essere:

#!/bin/bash
ethtool -s eth0 wol g
exit 0

salviamo il file e rendiamolo eseguibile:

nightfly@nightbox:~$ sudo chmod a+x autowol

Lanciamo lo scrip e verifichiamo che il WOL mediante magic packet (g) sia effettivamente attivo:

nightfly@nightbox:~$ sudo ethtool eth0

Lo stralcio di output che ci interessa dovrà essere simile al seguente:

Supports Wake-on: pumbg
        Wake-on: g

La prima riga ci conferma che la scheda eth0 supporta il WOL, la seconda riga, invece, ci fornisce informazioni sul tipo di WOL attivo (magic packet).

Fatto ciò, è necessario che tale opzione venga attivata automaticamente ad ogni avvio del sistema (e prima dello spegnimento). Per fare questo si può copiare il suddetto scrip nella directory /etc/init.d e successivamente usare il comando:

nightfly@nightbox:/etc/init.d$ update-rc.d -f autowol defaults

Bene, a questo punto ho deciso di dare inizio ai miei test. Per prima cosa ho scaricato un software gratuito (per ambienti Windows e dotato di GUI) in grado di forgiare i magic packet. Il tool a cui mi riferisco è questo:

http://www.depicus.com/downloads/WakeOnLanGui.zip

La cosa bella di questo software è che ci permette di scegliere la porta (UDP) su cui inoltrare il magic packet, riuscendo dunque ad aggirare eventuali restrizioni imposte dal PAT (in questo modo potremo utilizzare il WOL anche da remoto).

wolgui.jpg

Per accendere il nostro server da remoto sarà sufficiente riempire i campi richiesti dal suddetto tool, ovvero:

1) MAC address della macchina che si vuole avviare;

2) indirizzo IP (oppure hostname) pubblico della macchina;

3) porta (UDP).

Solitamente il WOL si avvale della porta 7 o 9 (UDP) ma vi consiglio di forwardare porte più alte in modo da complicare la vita ad eventuali scrip kiddie (sai che piacere lasciare il server spento e ritrovarselo accesso di punto in bianco?).

In definitiva, i test hanno dato questo esito:

1) se il server è spento (S5) il WOL non funziona;

2) se il server è sospeso (S3, con RAM alimentata), il WOL funziona;

3) se il server è ibernato (S4), ovvero il dump della RAM si trova nell’area swap dell’HD, il WOL non funziona.

Quindi, così come stanno le cose il WOL è quasi inutile. Nei prossimi giorni vedrò di aggiornare il BIOS ed eventualmente di acquistare una scheda Ethernet PCI-Express.

Speriamo bene.

PS: per maggiori dattagli sui power state ACPI potete consultare questa pagina.

PPS: potete operare con i power state direttamente da CLI utilizzando il comando pmi action <stato>.

AGGIORNAMENTO del 16/04/2020

Finalmente ho trovato un po’ di tempo per lavorarci e credo di aver risolto il problema. E’ stato sufficiente modificare un’opzione del BIOS, ovvero:

Power -> Control EuP

portandola da “Enabled” a “Disabled”.

In soldoni, tale opzione (Energy Using Products), se abilitata, disattiva il WOL quando il sistema si trova in S4 (hibernate) oppure in S5 (spento).

Ergo, adesso il WOL funziona anche a PC spento.