Wake on LAN peut-il fonctionner sur une connexion VPN?


14

Est-il vrai que nous ne pouvons autoriser aucune machine en veille à laquelle il peut être nécessaire d'accéder via une connexion VPN?

(Je pose la question sur la faute du serveur car cela concerne autant les serveurs VPN que les PC des utilisateurs finaux qui dorment)

Réponses:


9

Ancien fil, mais je voulais faire un carillon car c'est toujours le résultat de recherche le mieux noté pour "wol over vpn".

Oui, le paquet magique WOL est défini dans les contraintes de la couche 2, mais cela ne signifie pas qu'il ne peut pas être contenu dans une entité de protocole de réseau et de transport qui peut ensuite être utilisée pour l'acheminer à travers le VPN. La raison en est que la séquence "magique" peut se trouver n'importe où dans la charge utile. Il s'agit donc essentiellement d'obtenir un paquet routable régulier vers l'hôte cible avec la séquence "magique" dans sa charge utile.

La plupart des implémentations du paquet magique utilisent le port UDP 9, bien que cela n'ait pas d'importance tant qu'il est correctement acheminé et transmis sur le même domaine de diffusion que l'ordinateur cible. Tant que le client VPN dispose des routes correctes, il peut envoyer correctement un paquet de diffusion tel que 192.168.1.255 (une adresse de diffusion) à la passerelle VPN via Internet.

Le routage est donc très simple, le problème peut résider dans sa diffusion correcte à partir de la passerelle VPN cible. Cela signifie configurer la passerelle VPN / trouver une option pour transférer le trafic de diffusion des clients distants VPN vers le réseau local.


4

Généralement non, car le "MagicPacket" est en fait à la couche 2. Il n'est même pas routable sans l'aide de transitaires (par exemple, un assistant IP).


J'espérais que les serveurs VPN auraient une sorte de construction de surport pour cela ...
Ian Ringrose

En règle générale, ce n'est pas la «norme» avec les clients VPN. À partir de la session VPN elle-même, vous pouvez configurer un système / équipement intermédiaire pour aider au lancement du "MagicPacket" sur le système / appareil ciblé.
user48838

1

Il existe un moyen sophistiqué de construire un tunnel de couche 2 avec SSH, et avec ce WOL devrait bien fonctionner. Je ne vois donc aucune raison de ne pas envoyer des machines en veille.

Sur la base de la mention @slm, j'ai inclus les parties importantes de la source ci-dessous.

Conditions préalables:

1) la connexion root doit être activée sur les deux ordinateurs. (désolé - vos informations d'identification sur les deux ordinateurs doivent vous permettre de créer le périphérique TAP). Cela signifie: au niveau du système, root a un mot de passe;

2) dans le fichier sshd_config de l'hôte qui exécute le démon ssh, les options PermitTunnel yes et PermitRootLogin yes sont définies;

3) Le transfert IP est activé dans le noyau. Utilisez la commande sysctl pour définir cette option: sysctl -w net.ipv4.ip_forwarding = 1; ajoutez également la ligne net.ipv4.ip_forwarding = 1 à votre fichier /etc/sysctl.conf pour que le paramètre reste après le redémarrage. Faites cela sur les deux ordinateurs;

4) Vous avez installé le package bridge-utils, ou vous avez autrement la commande brctl à votre disposition sur les deux ordinateurs.

Créez le tunnel:

ssh -w 1: 1 -o Tunnel = nom d'hôte Ethernet

l'option -w définit le nom du périphérique TAP sur l'un ou l'autre hôte (ici, tap1 sera créé aux deux extrémités).

l'option -o permet de spécifier une option de fichier de configuration sur la ligne de commande. Nous utilisons Tunnel = ethernet pour configurer un tunnel de couche 2.

Ce formulaire gardera la session ssh ouverte au premier plan. Si vous souhaitez qu'il abandonne le shell une fois le tunnel établi, vous pouvez utiliser l'option -f pour lui dire de se bifurquer en arrière-plan. Cependant, il a besoin d'une commande à fork, donc vous pouvez simplement utiliser une commande fictive telle que true pour le faire fonctionner. Vous pouvez également utiliser cette fonctionnalité pour configurer le pont sur l'extrémité distante, mais je n'entre pas dans le détail pour le moment. Donc, cela ressemblerait à ceci:

ssh -f -w 1: 1 -o Tunnel = nom d'hôte Ethernet true

Ajoutez des périphériques TAP à un pont:

brctl addbr br0; brctl addif tap1; ifconfig tap1 up; ifconfig br0 up

vous exécutez cela sur les deux hôtes (notez que je n'ai pas attribué d'adresse IP). brctl est la commande à utiliser pour manipuler les périphériques de pont. brctl addbr ajoute le pont br0, et la commande addif lui joint le périphérique tap1.

La prochaine étape serait d'ajouter des interfaces Ethernet physiques au périphérique de pont. La façon dont vous voudriez faire cela variera, donc je vais passer en revue quelques scénarios. Le premier scénario est où vos homologues VPN sont sur le même sous-réseau (c'est-à-dire, aucun routage entre eux), et le deuxième scénario se fera sur Internet.

Impudique volé à: http://la11111.wordpress.com/2012/09/24/layer-2-vpns-using-ssh/


Bienvenue dans Server Fault! Généralement, nous aimons les réponses sur le site pour pouvoir se débrouiller seules - Les liens sont excellents, mais si ce lien se casse, la réponse devrait avoir suffisamment d'informations pour être utile. Veuillez envisager de modifier votre réponse pour inclure plus de détails. Voir la FAQ pour plus d'informations.
slm

où puis-je trouver sshd_config sur un système Windows 7?
Ian Ringrose

@IanRingrose Je n'en ai aucune idée car je ne travaille qu'avec Linux
Sir l33tname


0

Je suis d'accord avec user48838 - par définition, le paquet magique n'est envoyé que sur le sous-réseau local. Cependant, j'ai déjà utilisé un script écrit par jpo qui fonctionnait à partir d'un sous-réseau différent via un routeur normal. Essayez ceci - YMMV

http://gsd.di.uminho.pt/jpo/software/wakeonlan/



0

J'ai testé cela et la réponse est OUI :)

J'ai trouvé un outil sur Internet qui envoie le paquet WOL en tant que multidiffusion à l'hôte prévu, par lequel éviter de passer le paquet de diffusion à travers le problème du routeur.

Un point que vous devez surveiller avec cette solution, vous devez mettre l'entrée d'arp statique sur le routeur car l'hôte sera éteint et ne répondra pas à la demande ARP du routeur. À votre santé!


Cela semble fonctionner, il semble également que ces paquets seront effectivement diffusés. L'entrée ARP ne se traduit que d'IP en MAC. Il ne dit pas au commutateur sur quel port le MAC est activé. Et si l'hôte est hors ligne, le commutateur ne sait probablement pas où se trouve ce MAC, il sera donc diffusé. Mais au moins aucun des hôtes ne va envoyer de réponse, donc ça devrait aller.
kasperd

Quelques informations sur la façon de trouver l'outil que vous avez utilisé pourraient améliorer cette réponse.
kasperd
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.