È vero che non possiamo consentire a nessuna macchina di dormire che potrebbe essere necessario accedere a una connessione VPN?
(Lo sto chiedendo per errore del server, in quanto riguarda tanto i server VPN quanto i PC degli utenti finali che dormono)
Risposte:
Vecchio thread, ma volevo entrare perché è ancora il risultato di ricerca più votato per "wol over vpn".
Sì, il pacchetto magico WOL è definito nell'ambito dei vincoli del livello 2, ma ciò non significa che non possa essere contenuto all'interno di un'entità del protocollo di rete e di trasporto che può quindi essere utilizzato per instradarlo attraverso la VPN. La ragione di ciò è che la sequenza "magica" può trovarsi ovunque all'interno del payload. Quindi in sostanza diventa una questione di ottenere un pacchetto instradabile regolare per l'host target con la sequenza "magica" all'interno del suo payload.
La maggior parte delle implementazioni del pacchetto magico utilizza la porta UDP 9 sebbene ciò non contenga fino a quando viene instradato correttamente e trasmesso sullo stesso dominio di trasmissione del computer di destinazione. Finché il client VPN ha i percorsi corretti, può inviare correttamente un pacchetto di trasmissione come 192.168.1.255 (un indirizzo di trasmissione) al gateway VPN attraverso Internet.
Quindi il routing è davvero semplice, il problema potrebbe risiedere nel trasmetterlo correttamente dal gateway VPN di destinazione. Ciò significa configurare il gateway VPN / trovare un'opzione per inoltrare il traffico di trasmissione dai client remoti VPN alla rete locale.
In genere no, dato che il "MagicPacket" è effettivamente al livello 2. Non è nemmeno instradabile senza l'assistenza degli spedizionieri (ad es. Helper IP).
C'è un modo elegante per costruire un tunnel di livello 2 con SSH, e con questo WOL dovrebbe funzionare bene. Pertanto non vedo alcun motivo per fare a meno di mandare le macchine a dormire.
Sulla base della menzione @slm ho incluso le parti importanti della fonte di seguito.
Prerequisiti:
1) entrambi i computer devono avere il login root abilitato. (scusate: le vostre credenziali su entrambi i computer devono consentire di creare il dispositivo TAP). Questo significa: a livello di sistema, root ha una password;
2) nel file sshd_config dell'host che esegue il demone ssh, sono impostate le opzioni PermitTunnel yes e PermitRootLogin yes;
3) l'IP Forwarding è abilitato nel kernel. Utilizzare il comando sysctl per impostare questa opzione: sysctl -w net.ipv4.ip_forwarding = 1; inoltre, aggiungi la riga net.ipv4.ip_forwarding = 1 al tuo file /etc/sysctl.conf affinché l'impostazione si attacchi dopo il riavvio. Fallo su entrambi i computer;
4) Hai installato il pacchetto bridge-utils, o altrimenti hai il comando brctl a tua disposizione, su entrambi i computer.
Crea il tunnel:
ssh -w 1: 1 -o Tunnel = nome host ethernet
l'opzione -w imposta il nome del dispositivo TAP su entrambi gli host (qui, tap1 verrà creato su entrambe le estremità).
l'opzione -o serve per specificare un'opzione del file di configurazione sulla riga di comando. Usiamo Tunnel = ethernet per impostare un tunnel di livello 2.
Questo modulo manterrà la sessione ssh aperta in primo piano. Se desideri che abbandoni la shell dopo che il tunnel è stato stabilito, puoi usare l'opzione -f per dire che si biforca in background. Tuttavia, ha bisogno di un comando per fork, quindi puoi semplicemente usare un comando fittizio come true per farlo funzionare. Potresti anche usare questa funzionalità per configurare il bridge sull'estremità remota, ma non ci sto entrando in questo momento. Quindi, sarebbe simile a questo:
ssh -f -w 1: 1 -o Tunnel = nome host Ethernet vero
Aggiungi dispositivi TAP a un bridge:
brctl addbr br0; brctl addif tap1; ifconfig tap1 up; ifconfig br0 up
lo esegui su entrambi gli host (nota che non ho assegnato un IP). brctl è il comando da utilizzare per manipolare i dispositivi bridge. brctl addbr aggiunge il bridge br0 e il comando addif unisce il dispositivo tap1 ad esso.
Il prossimo sarebbe aggiungere interfacce Ethernet fisiche al dispositivo bridge. Il modo in cui vorresti farlo varierà, quindi esaminerò un paio di scenari. Il primo scenario è dove i tuoi peer VPN si trovano sulla stessa sottorete (cioè, nessun routing tra di loro) e il secondo scenario sarà su Internet.
Senza vergogna rubato da: http://la11111.wordpress.com/2012/09/24/layer-2-vpns-using-ssh/
Sì, invece di inviare il pacchetto WoL all'indirizzo di trasmissione nella rete di destinazione, puoi semplicemente inviarlo all'indirizzo IP della macchina che desideri svegliare. Programmi testati con VPN PPTP:
Sono d'accordo con user48838 - per definizione il pacchetto magico viene inviato solo sulla sottorete locale. Tuttavia, in precedenza avevo usato uno script scritto da jpo che funzionava da una sottorete diversa tramite un normale router. Prova questo - YMMV
bene in realtà la risposta è SÌ.
Uso con successo WOL su PPTP VPN usando quell'app: https://play.google.com/store/apps/details?id=com.benfinnigan.wol&hl=pl
Ho provato questo e la risposta è SÌ :)
Ho trovato uno strumento su Internet che invia il pacchetto WOL come uni-cast all'host previsto, evitando così di trasmettere il pacchetto di trasmissione attraverso il problema del router.
Un punto a cui devi fare attenzione con questa soluzione, devi inserire la voce statica arp sul router poiché l'host sarà spento e non risponderà alla richiesta ARP del router. Saluti!