O Wake on LAN funciona na conexão VPN?

Question

É verdade que não podemos permitir que qualquer máquina durma e precise acessar uma conexão VPN?

(Eu estou perguntando isso na falha do servidor, pois é tanto sobre os servidores VPN quanto sobre os PCs dos usuários finais que dormem)

    

Answer 1

Tópico antigo, mas eu queria entrar em contato porque ainda é o resultado de pesquisa mais bem classificado para "wol over vpn".

Sim, o pacote mágico WOL é definido dentro das restrições da camada 2, mas isso não significa que não possa ser contido dentro de uma entidade de protocolo de rede e transporte, que pode ser usado para rotea-lo através da VPN. A razão para isso é que a sequência "mágica" pode estar em qualquer lugar dentro da carga útil. Então, essencialmente, torna-se uma questão de obter um pacote roteável regular para o host de destino com a seqüência "mágica" dentro de sua carga útil.

A maioria das implementações do pacote mágico usa a porta UDP 9, embora isso realmente não importe, desde que seja roteado corretamente e transmitido no mesmo domínio de broadcast que o computador de destino. Contanto que o cliente VPN tenha as rotas corretas, ele pode enviar um pacote de transmissão como 192.168.1.255 (um endereço de broadcast) corretamente para o gateway da VPN através da Internet.

Portanto, o roteamento é realmente direto, o problema pode estar na difusão correta do gateway da VPN de destino. Isso significa configurar o gateway da VPN / encontrar uma opção para encaminhar o tráfego de broadcast de clientes remotos VPN para a rede local.

    

Answer 2

Normalmente, não, uma vez que o "MagicPacket" está na camada 2. Nem sequer é possível encaminhá-lo sem a ajuda de encaminhadores (por exemplo, o IP helper).

    

Answer 3

Existe uma maneira sofisticada de construir um túnel da Camada 2 com SSH, e com este WOL deve funcionar bem. Portanto, não vejo razão para fazer sem enviar máquinas para dormir.

Com base na menção @slm, incluí as partes importantes da fonte abaixo.

Pré-requisitos:

1) os dois computadores devem ter o login raiz habilitado. (desculpe - suas credenciais em ambos os computadores devem permitir que você crie o dispositivo TAP). Isso significa: no nível do sistema, o root tem uma senha;

2) no arquivo sshd_config do host que está executando o daemon ssh, as opções PermitTunnel yes e PermitRootLogin yes são definidas;

3) O encaminhamento de ip está habilitado no kernel. Use o comando sysctl para definir esta opção: sysctl -w net.ipv4.ip_forwarding = 1; Além disso, adicione a linha net.ipv4.ip_forwarding = 1 ao seu arquivo /etc/sysctl.conf para que a configuração permaneça após a reinicialização. Faça isso em ambos os computadores;

4) Você instalou o pacote bridge-utils ou tem o comando brctl disponível em ambos os computadores.

Crie o túnel:

ssh -w 1:1 -o Tunnel=ethernet hostname

a opção -w define o nome do dispositivo TAP em qualquer um dos hosts (aqui, o tap1 será criado em ambas as extremidades).

A opção -o é para especificar uma opção de arquivo de configuração na linha de comando. Usamos Túnel = ethernet para configurar um túnel de camada 2.

Este formulário manterá a sessão ssh aberta em primeiro plano. Se você quiser abandonar o shell depois que o túnel for estabelecido, poderá usar a opção -f para que ele seja bifurcado em segundo plano. Ele precisa de um comando para bifurcar, portanto, você pode simplesmente usar um comando fictício, como true, para fazê-lo funcionar. Você também pode usar essa funcionalidade para configurar a ponte no ponto remoto, mas não estou entendendo isso agora. Então, ficaria assim:

ssh -f -w 1:1 -o Tunnel=ethernet hostname true

Adicione dispositivos TAP a uma ponte:

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

você executa isso em ambos os hosts (observe que eu não atribuí um IP). brctl é o comando usado para manipular dispositivos de ponte. brctl addbr adiciona a ponte br0, e o comando addif junta o dispositivo tap1 a ela.

O próximo passo seria adicionar interfaces Ethernet físicas ao dispositivo de ponte. O que você gostaria de fazer isso varia, então analisarei alguns cenários. O primeiro cenário é onde seus pares de VPN estão na mesma sub-rede (ou seja, nenhum roteamento entre eles) e o segundo cenário será pela Internet.

Shameless roubado de: link

    

Answer 4

Sim, você pode, em vez de enviar o pacote WoL para o endereço de broadcast na rede de destino, apenas enviá-lo para o endereço IP da máquina que você quer acordar. Programas testados com VPN PPTP:

• link
• link

Answer 5

Concordo com user48838 - por definição, o pacote mágico é enviado apenas pela sub-rede local. No entanto, usei anteriormente um script escrito por jpo que funcionava de uma sub-rede diferente por meio de um roteador normal. Tente isso - YMMV

link

    

Answer 6

bem, na verdade, a resposta é sim.

Eu uso com êxito o WOL via VPN PPTP usando esse aplicativo: link

    

Answer 7

Eu testei isso e a resposta é SIM:)

Eu encontrei uma ferramenta na internet que envia o pacote WOL como uni-cast para o host pretendido, pelo qual evito passar o pacote de broadcast através do problema do roteador.

Um ponto que você precisa observar com esta solução, você precisa colocar a entrada Static arp no roteador, já que o host estará desligado e não responderá à solicitação ARP do roteador. Felicidades!