Tenho tentado configurar um ambiente para meu hipervisor, que é apenas um Bookworm Debian executando o qemu.
Tenho usado a interface web Cockpit para me ajudar a ver as coisas quando o terminal está muito árido. Mas, ao fazer isso, tive que mudar de using systemd-nerworkd
para NetworkManager
.
Recentemente, aprendi como criar uma rede bridge para que minhas VMs e o host possam se comunicar entre si. Mas depois de fazer isso meu wakeonlan parou de funcionar. Entendo que isso é esperado porque o roteador agora 'vê' o endereço MAC da ponte em vez do endereço MAC da placa de rede.
Pelo que entendi, o wakeonlan funciona no nível MAC do modelo de rede. Tentei usar arping
de outros clientes da rede e eles não conseguem "ver" o endereço MAC do meu hipervisor (bridge).
Agora estou começando a pensar que talvez não seja possível ter uma ponte ao mesmo tempo que wakeonlan. Isso é possível? Se sim, como posso fazer isso? de preferência usando NetworkManager
.
Wake-On-LAN é um recurso de hardware: não se destina a alcançar a interface principal participante do roteamento: a ponte, mas sempre a interface física: a interface NIC real definida como porta da ponte. O método usual usado para Wake-On-LAN é usar o Magic Packet (white paper original da AMD de 1995: PDF ), em vez de outros métodos (como unicast, broadcast ou ARP) para evitar despertares falsos e indesejados.
Normalmente, Wake-On-LAN pode ser habilitado usando
ethtool
(por exemplo: oneth0
) com:dando:
Mas, na verdade, o NetworkManager, se não for informado de outra forma, provavelmente desativará novamente o Wake-On-LAN na interface que gerencia antes ou depois de uma suspensão, fazendo com que falhe na primeira ou na segunda vez (e após as reinicializações). Então isso não é suficiente. O NetworkManager deve ser informado para usar Wake-On-LAN nesta interface.
nmcli
os comandos abaixo podem ser executados usando o miniaplicativo GUI se uma GUI estiver disponível.Se por exemplo o NetworkManager tiver estes nomes de conexão:
Bridge connection 1
e como interface escravaEthernet connection 1
, o recurso deverá ser ativado emEthernet connection 1
.que está documentado em
nm-settings-nmcli(5)
:Embora possa haver um padrão em outro lugar, configurá-lo explicitamente para
magic
garantir que o Wake-On-LAN permaneça ativado nesta interface.Configure-o para magia assim:
Como esta configuração pode não ser aplicada imediatamente pelo NetworkManager (mesmo incluindo depois
nmcli connection reload
), ela também deve ser definida manualmente, apenas uma vez após ter configurado isso, conforme descrito acima (altere o nome da interface conforme necessário):Agora sobre o uso. Não há razão para que o endereço MAC Ethernet da ponte seja igual ao endereço MAC Ethernet da NIC. Este não é explicitamente o padrão nos sistemas systemd modernos (embora o próprio NetworkManager possa optar por copiá-lo para a ponte). Portanto, o ARP, mesmo que ainda esteja no cache de um sistema na mesma LAN, nunca será o método correto para que um Magic Packet alcance a interface física. Quando suspenso, não se pode mais confiar que a interface física será mantida em modo promíscuo (porque é uma porta de ponte). De qualquer forma, esse ARP também falharia se a entrada do cache fosse removida do cache do sistema.
Se estiver usando IP como mecanismo de carga útil, sempre use um destino que será resolvido em um destino de transmissão Ethernet MAC (FF:FF:FF:FF:FF:FF) e não tente uma resolução ARP: a transmissão LAN 255.255.255.255 ou o transmissão direcionada (por exemplo, em LAN 192.168.1.0/24, seria 192.168.1.255).
Por exemplo, se o endereço MAC da NIC for 12:34:56:78:9a:bc, usando
wakeonlan
, basta fazer, da mesma LAN :ou se o sistema tiver acesso a múltiplas LANs, por exemplo, 192.0.2.0/24 e 192.168.1.0/24 e o sistema a ser ativado estiver no último:
Outras ferramentas podem ter ou não ter outros recursos. Por exemplo:
etherwake
requer, em vez disso, especificar uma interface e não usará IP, mas Ethernet tipo 0x0842, que é um tipo de fato reservado para Wake-On-LAN (mas não precisa ser usado) e requer root ou recursos adequados para ser usado:Isso está fora do escopo da questão, mas para dar dicas, ativar remotamente pela Internet requer ajuda do gateway da Internet: ele precisa executar um software personalizado ou fazer NAT para uma transmissão e ativar o roteamento de transmissões direcionadas que estão sempre desabilitadas por padrão por razões de segurança . Conforme descrito acima, definir um endereço ARP permanente geralmente não ajuda com uma ponte, mas pode ser um endereço ARP permanente falso com a finalidade de despertar o sistema, reservando um endereço IP fictício (não usado em nenhum lugar, incluindo não presente em a interface bridge) na LAN para tal propósito.