¿Puede Wake on LAN funcionar en una conexión VPN?

¿Es cierto que no podemos permitir que ninguna máquina duerma a la que se deba acceder desde una conexión VPN?

(Estoy preguntando esto por culpa del servidor, ya que se trata tanto de los servidores VPN como de las PC del usuario final en reposo)

Hilo antiguo, pero quería intervenir porque sigue siendo el resultado de búsqueda mejor calificado para "wol over vpn".

Sí, el paquete mágico WOL se define dentro de las restricciones de la capa 2, pero esto no significa que no pueda estar contenido dentro de una red y una entidad de protocolo de transporte que luego puede usarse para enrutarlo a través de la VPN. La razón de esto es que la secuencia "mágica" puede estar en cualquier lugar dentro de la carga útil. Así que esencialmente se trata de llevar un paquete enrutable regular al host de destino con la secuencia "mágica" dentro de su carga útil.

La mayoría de las implementaciones del paquete mágico usan el puerto UDP 9, aunque esto realmente no importa siempre que se enrute correctamente y se transmita en el mismo dominio de transmisión que la computadora de destino. Siempre que el cliente VPN tenga las rutas correctas, puede enviar un paquete de transmisión como 192.168.1.255 (una dirección de transmisión) correctamente a la puerta de enlace VPN a través de Internet.

Entonces, el enrutamiento es realmente sencillo, el problema puede estar en transmitirlo correctamente desde la puerta de enlace VPN de destino. Esto significa configurar la puerta de enlace VPN / encontrar una opción, para reenviar el tráfico de difusión desde clientes remotos VPN a la red local.

Normalmente no, ya que el "MagicPacket" está realmente en la capa 2. Ni siquiera es enrutable sin la ayuda de los reenviadores (por ejemplo, IP helper).

Hay una forma elegante de construir un túnel de capa 2 con SSH, y con este WOL debería funcionar bien. Por lo tanto, no veo ninguna razón para hacerlo sin enviar máquinas a dormir.

Sobre la base de la mención @slm, incluí las partes importantes de la fuente a continuación.

Prerrequisitos:

1) ambas computadoras deben tener habilitado el inicio de sesión raíz. (lo siento, sus credenciales en ambas computadoras deben permitirle crear el dispositivo TAP). Esto significa: en el nivel del sistema, root tiene una contraseña;

2) en el archivo sshd_config del host que ejecuta el demonio ssh, se configuran las opciones PermitTunnel yes y PermitRootLogin yes;

3) el reenvío de IP está habilitado en el núcleo. Use el comando sysctl para establecer esta opción: sysctl -w net.ipv4.ip_forwarding = 1; también, agregue la línea net.ipv4.ip_forwarding = 1 a su archivo /etc/sysctl.conf para que la configuración permanezca después de reiniciar. Haga esto en ambas computadoras;

4) Ha instalado el paquete bridge-utils, o tiene el comando brctl disponible en ambas computadoras.

Crea el túnel:

ssh -w 1: 1 -o Túnel = nombre de host de ethernet

la opción -w establece el nombre del dispositivo TAP en cualquier host (aquí, se creará tap1 en ambos extremos).

la opción -o es para especificar una opción de archivo de configuración en la línea de comando. Usamos Tunnel = ethernet para configurar un túnel de capa 2.

Este formulario mantendrá la sesión ssh abierta en primer plano. Si desea que abandone el caparazón después de establecer el túnel, puede usar la opción -f para indicarle que se bifurque en segundo plano. Sin embargo, necesita un comando para bifurcar, por lo que puede usar un comando ficticio como true para que funcione. También podría usar esta funcionalidad para configurar el puente en el extremo remoto, pero no me estoy metiendo en eso en este momento. Entonces, se vería así:

ssh -f -w 1: 1 -o Túnel = nombre de host de ethernet verdadero

Agregue dispositivos TAP a un puente:

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

ejecuta esto en ambos hosts (tenga en cuenta que no asigné una IP). brctl es el comando que se utiliza para manipular dispositivos de puente. brctl addbr agrega el puente br0, y el comando addif se une al dispositivo tap1.

El siguiente paso sería agregar interfaces físicas de Ethernet al dispositivo de puente. La forma en que desearía hacer eso variará, así que repasaré un par de escenarios. El primer escenario es donde sus pares VPN están en la misma subred (es decir, no hay enrutamiento entre ellos), y el segundo escenario será a través de Internet.

Desvergonzado robado de: http://la11111.wordpress.com/2012/09/24/layer-2-vpns-using-ssh/

Sí, puede, en lugar de enviar el paquete WoL a la dirección de difusión en la red de destino, simplemente envíelo a la dirección IP de la máquina que desea activar. Programas probados con PPTP VPN:

• http://www.nirsoft.net/utils/wake_on_lan.html
• https://play.google.com/store/apps/details?id=com.overlook.android.fing

Estoy de acuerdo con user48838: por definición, el paquete mágico se envía solo a través de la subred local. Sin embargo, anteriormente utilicé un script escrito por jpo que funcionaba desde una subred diferente a través de un enrutador normal. Prueba esto: YMMV

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

Bueno, en realidad la respuesta es SÍ.

Utilizo con éxito WOL sobre PPTP VPN con esa aplicación: https://play.google.com/store/apps/details?id=com.benfinnigan.wol&hl=pl

He probado esto y la respuesta es SÍ :)

Encontré una herramienta en Internet que envía el paquete WOL como uni-cast al host previsto, por lo que evito pasar el paquete de transmisión a través del problema del enrutador.

Un punto que debe tener en cuenta con esta solución, debe colocar la entrada Arp estática en el enrutador ya que el host estará apagado y no responderá a la solicitud ARP del enrutador. ¡Salud!