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:
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.
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).
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/
Oui, au lieu d'envoyer le paquet WoL à l'adresse de diffusion dans le réseau cible, envoyez-le simplement à l'adresse IP de la machine que vous souhaitez réveiller. Programmes testés avec PPTP VPN:
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
eh bien en fait la réponse est OUI.
J'utilise avec succès WOL sur PPTP VPN en utilisant cette application: https://play.google.com/store/apps/details?id=com.benfinnigan.wol&hl=pl
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é!