WireGuard não consegue criar a sua interface: kernel ou permissões?
A criação da interface falha antes de qualquer aperto de mão com um par. Leia o erro para distinguir um módulo ausente de um limite de privilégios ou de um proprietário já existente da interface.
WireGuard não consegue criar a sua interface, por isso não há dispositivo para configurar, nem chave para trocar, nem aperto de mão para depurar. A falha fica inteiramente na máquina local, e o texto do erro diz que parte da pilha local recusou. Lê-lo corretamente é mais rápido do que reinstalar a configuração do par. As camadas podem ser separadas, e a mensagem nomeia a que recusou.
O erro ocorre antes de qualquer par falar
Criar uma interface é um único pedido netlink ao kernel a solicitar um dispositivo do tipo wireguard. O kernel tem ou não um controlador que compreenda esse tipo, e a resposta volta de imediato. Nenhum pacote sai da máquina durante este passo, e é por isso que os endereços dos extremos e as chaves do servidor não podem ser a causa.
Essa ordem importa para o diagnóstico. Se o comando nunca criou um dispositivo, o problema não pode ser uma chave pública errada nem uma porta UDP bloqueada. Corrija primeiro o caminho local de criação e só depois olhe para fora.
Que implementação deve possuir o dispositivo
Duas implementações podem responder a esse pedido. O módulo dentro do kernel registra o tipo de dispositivo wireguard, e uma implementação em espaço de utilizador como o wireguard-go fornece a mesma interface através de outro mecanismo. Se o módulo estiver ausente, o kernel rejeita o pedido com um erro de dispositivo não suportado, e a solução é carregar o módulo ou apontar as ferramentas para a implementação em espaço de utilizador.
Verifique o que está realmente presente antes de escolher entre as duas. O primeiro comando mostra se o módulo está carregado e o segundo pergunta ao kernel diretamente:
lsmod | grep wireguard
ip link add wgtest0 type wireguardO segundo comando é a menor reprodução possível: pede um dispositivo e nada mais. Se falhar com uma mensagem de tipo não suportado, a peça que falta é a implementação e não o seu ficheiro de configuração.
| Error text | What refused | Next step |
|---|---|---|
| Unknown device type or operation not supported | The kernel has no wireguard driver | Load the module or use the userspace implementation |
| Operation not permitted | Missing privilege | Use the service context or grant the capability |
| File exists | The name is already in use | Inspect the owner before touching it |
| No such device in a container | No tunnel device or capability | Add the device and NET_ADMIN to the container |
Privilégios e limites do contentor
Criar e configurar um dispositivo de rede exige privilégios, seja como root ou com a capacidade de administrar a rede. Uma sessão de utilizador normal não o consegue fazer, e essa restrição é o desenho e não um obstáculo a contornar executando um instalador que não reviu.
Dentro de um contentor o limite duplica. O contentor precisa de acesso ao dispositivo de túnel e da capacidade de o configurar, e os sinalizadores que o concedem são os mesmos que um contentor de VPN no Linux usa. Um convidado restrito que consegue navegar na web normalmente continua a não poder criar uma interface, porque navegar não exige essa capacidade. Conceda a capacidade ao serviço que precisa dela e não a cada sessão do anfitrião.
Resolva o conflito de nomes e tente novamente
Uma interface que já existe não é automaticamente um resto. Outro gestor pode possuir o nome e estar a usá-lo neste momento, por isso inspecione-a antes de apagar seja o que for:
ip link show wg0
sudo wg show wg0Se o proprietário for um serviço ativo, configure esse serviço em vez de criar um segundo dispositivo. Se estiver realmente obsoleta, remova-a através da ferramenta que a criou e depois suba a interface com o cliente ou a unidade documentados, para que a configuração e o dispositivo se mantenham alinhados.
Assim que a criação for bem-sucedida, a falha seguinte pertence a uma etapa posterior, e uma unidade que relata uma falha depois de o dispositivo existir é um problema diferente de um dispositivo que nunca foi criado. Separe os dois antes de voltar a alterar permissões.