É verdade que não podemos permitir que nenhuma máquina entre em sono que precise ser acessada por uma conexão VPN?
(Estou perguntando isso por falha do servidor, pois é tanto sobre servidores VPN quanto sobre os PCs do usuário final em suspensão)
É verdade que não podemos permitir que nenhuma máquina entre em sono que precise ser acessada por uma conexão VPN?
(Estou perguntando isso por falha do servidor, pois é tanto sobre servidores VPN quanto sobre os PCs do usuário final em suspensão)
Respostas:
Tópico antigo, mas eu queria conversar porque ainda é o resultado da pesquisa mais votada para "wol over vpn".
Sim, o pacote mágico WOL é definido dentro das restrições da camada 2, mas isso não significa que ele não possa estar contido em uma entidade de protocolo de rede e transporte que pode ser usada para rotear pela VPN. A razão para isso é que a sequência "mágica" pode estar em qualquer lugar da carga. Portanto, basicamente torna-se uma questão de obter um pacote roteável regular para o host de destino com a sequência "mágica" dentro de sua carga.
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. Desde 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 transmissão) corretamente para o gateway da VPN na Internet.
Portanto, o roteamento é realmente simples, o problema pode estar na transmissão correta do gateway VPN de destino. Isso significa configurar o gateway da VPN / encontrar uma opção para encaminhar o tráfego de broadcast dos clientes remotos da VPN para a rede local.
Normalmente não, já que o "MagicPacket" está na camada 2. Ele não é roteável sem a ajuda de encaminhadores (por exemplo, auxiliar de IP).
Existe uma maneira elegante de construir um túnel de camada 2 com SSH, e com esse WOL deve funcionar bem. Portanto, não vejo razão para não 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 ativado. (desculpe - suas credenciais nos dois 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á ativado no kernel. Use o comando sysctl para definir esta opção: sysctl -w net.ipv4.ip_forwarding = 1; adicione também 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 nos dois computadores;
4) Você instalou o pacote bridge-utils ou, caso contrário, tem o comando brctl disponível para você, nos dois computadores.
Crie o túnel:
ssh -w 1: 1 -o Tunnel = nome do host da Ethernet
a opção -w define o nome do dispositivo TAP em qualquer host (aqui, tap1 será criado nas duas extremidades).
a opção -o é para especificar uma opção de arquivo de configuração na linha de comandos. Usamos Tunnel = ethernet para configurar um túnel de camada 2.
Este formulário manterá a sessão ssh aberta em primeiro plano. Se você deseja abandonar o shell após o estabelecimento do túnel, use a opção -f para instruí-lo a entrar em segundo plano. Porém, ele precisa de um comando para bifurcar, para que você possa usar apenas um comando fictício como true para fazê-lo funcionar. Você também pode usar essa funcionalidade para configurar a ponte na extremidade remota, mas não estou entrando nisso agora. Então, ficaria assim:
ssh -f -w 1: 1 -o Tunnel = nome do host ethernet true
Adicione dispositivos TAP a uma ponte:
brctl addbr br0; brctl addif tap1; ifconfig tap1 up; ifconfig br0 up
você executa isso nos dois hosts (observe que eu não atribuai um IP). brctl é o comando a ser usado para manipular dispositivos de ponte. O brctl addbr adiciona a ponte br0 e o comando addif une o dispositivo tap1 a ele.
Em seguida, seria adicionar interfaces Ethernet físicas ao dispositivo de ponte. Como você gostaria de fazer isso varia, então vou abordar alguns cenários. O primeiro cenário é o local em que seus pares de VPN estão na mesma sub-rede (ou seja, não há roteamento entre eles), e o segundo cenário será pela Internet.
Vergonhoso roubado de: http://la11111.wordpress.com/2012/09/24/layer-2-vpns-using-ssh/
Sim, você pode, em vez de enviar o pacote WoL para transmitir o endereço na rede de destino, basta enviá-lo para o endereço IP da máquina que deseja ativar. Programas testados com VPN PPTP:
Eu concordo com o usuário48838 - por definição, o pacote mágico é enviado apenas pela sub-rede local. No entanto, eu anteriormente usei um script escrito pelo jpo que funcionava em uma sub-rede diferente por meio de um roteador normal. Tente isso - YMMV
Bem, na verdade a resposta é SIM.
Uso com êxito a VPN WOL sobre PPTP usando esse aplicativo: https://play.google.com/store/apps/details?id=com.benfinnigan.wol&hl=pl
Eu testei isso e a resposta é SIM :)
Encontrei uma ferramenta na internet que envia o pacote WOL como uni-cast para o host pretendido, evitando a passagem do pacote de broadcast pelo problema do roteador.
Um ponto que você precisa observar com esta solução é colocar a entrada estática arp no roteador, pois o host estará desligado e não responderá à solicitação ARP do roteador. Felicidades!