WireGuard: Unable to Access Interface: Operation Not Permitted (solução)

Divulgação de afiliados - Este artigo contém links de afiliados da Contabo. Se contratares um VPS através deles, ganhamos uma comissão sem custo adicional para ti.

Corres wg-quick up wg0 e ele para numa linha:

Unable to access interface: Operation not permitted

A primeira resposta que vais encontrar é acrescentar sudo. Muitas vezes o sudo já lá está, e o comando continua a falhar, e é aí que a maioria das pessoas fica presa.

O que a mensagem está a relatar

Operation not permitted é EPERM, devolvido pelo kernel quando o wg tenta configurar a interface por netlink. O kernel foi consultado, e o kernel disse que não. É uma afirmação mais restrita do que parece, e vale a pena separá-la de dois erros com que é confundida:

• No such device significa que a interface não existe. Outro problema.
• Command not found ou um erro de módulo significa que faltam as ferramentas ou o módulo do kernel. Também é outro problema.

Aqui as ferramentas correram, a chamada foi feita, e a permissão foi negada ao nível do kernel. Portanto a questão não é "sou root?", é "o que mais está a bloquear esta chamada?".

Causa 1: não és mesmo root

Vale a pena eliminá-la com um comando, porque não custa nada:

id -u

Se o resultado não for 0 e não usaste sudo, tens a resposta. Se mostrar 0, avança. Repara que sudo wg-quick up wg0 e sudo -E wg-quick up wg0 se comportam de forma diferente quanto ao ambiente, mas nenhum dos dois altera a questão das capabilities descrita abaixo.

Causa 2: um contentor sem CAP_NET_ADMIN

Esta é a mais comum, e o sudo não a resolve. Dentro de um contentor podes ter uid 0 e mesmo assim não ter a capability que autoriza a administração de rede. Root num contentor não é root no host.

Verifica o que tens realmente:

capsh --print | grep -i net_admin

Sem cap_net_admin no conjunto efetivo, o kernel recusa, sempre, com ou sem sudo. Em Docker:

docker run --cap-add NET_ADMIN --device /dev/net/tun ...

Num contentor LXC sem privilégios, a capability sozinha normalmente não basta porque o dispositivo tun não está exposto; o dispositivo tem de ser passado na configuração do contentor. O mesmo se aplica quando o "servidor" que alugaste é ele próprio um contentor: nos planos VPS baseados em OpenVZ ou LXC é o kernel do fornecedor que decide o que podes fazer, e nenhum sudo do teu lado acrescenta NET_ADMIN. A solução aí é uma instância KVM, tratada no fim deste artigo. Se o teu WireGuard vive num contentor por opção, a instalação em contentor é tratada à parte em WireGuard em Docker.

Se preferires partir de uma definição de contentor que já tenha as capabilities certas, o modelo docker-compose do nosso WireGuard Self-Hosting Kit (9 USD, PDF + Markdown + ficheiros .conf prontos) declara cap_add: NET_ADMIN, SYS_MODULE e o sysctl net.ipv4.ip_forward=1, com a interface web ligada apenas ao endereço do túnel. O kit inclui também uma checklist de 12 causas para um túnel que sobe mas não passa tráfego. Tudo nesta página continua gratuito. Ver o kit no Gumroad.

Causa 3: o ficheiro de configuração que a ferramenta não lê

O wg-quick lê /etc/wireguard/wg0.conf antes de tocar na interface. Dois problemas ao nível do ficheiro surgem perto deste passo:

ls -l /etc/wireguard/wg0.conf

O modo deve ser 600 e o dono root. Uma configuração legível por todos que contém uma chave privada é um problema real por si só, e o wg-quick avisa-te disso. Um ficheiro que o utilizador que o invoca não consegue ler provoca uma falha mais cedo na execução, antes de qualquer chamada netlink, por isso lê a saída completa e não só a última linha.

chmod 600 /etc/wireguard/wg0.conf
chown root:root /etc/wireguard/wg0.conf

Causa 4: algo acima do kernel está a dizer que não

Se és root, tens NET_ADMIN e o ficheiro está limpo, vê o que mais pode devolver EPERM numa chamada netlink:

• Um módulo de segurança. SELinux ou AppArmor em modo enforcing podem negar a operação. dmesg | tail logo a seguir ao comando falhado é a forma mais rápida de ver uma negação, porque estes registam onde o comando não regista.
• Um /sys só de leitura ou restrito. Alguns ambientes endurecidos ou mínimos montam-no de forma a bloquear a configuração da interface.
• Um filtro de syscalls. Um perfil seccomp que descarta as chamadas relevantes produz o mesmo errno sem mais nenhuma pista.

dmesg | tail -20

Se nada aparecer no dmesg, a causa 4 é pouco provável e a resposta é quase de certeza a causa 2.

A ordem a seguir

1. id -u, confirma que és 0.
2. capsh --print | grep net_admin, confirma a capability.
3. ls -l /etc/wireguard/wg0.conf, confirma o modo 600 e o dono root.
4. dmesg | tail -20 imediatamente após a falha, procura uma negação.

Quatro comandos, que eliminam as causas pela ordem da frequência com que acabam por ser a verdadeira.

Quando a interface sobe

Um wg-quick up bem-sucedido não é o mesmo que um túnel a funcionar. Se a interface já existe mas nada passa, passaste para uma questão de encaminhamento ou de handshake, não de permissões: o lado do handshake é tratado em resolução de problemas de handshake WireGuard, e os erros de endereço que aparecem logo a seguir em o erro bad address (em inglês).

Para um VPS onde alojar tudo isto, root e NET_ADMIN vêm de série numa instância KVM, o que é uma razão para a preferir às ofertas mais baratas baseadas em contentores, onde exatamente este problema vem incorporado. Um convidado KVM corre o seu próprio kernel, por isso o wg-quick up está a pedir a um kernel que controlas, não ao do fornecedor. A gama Cloud VPS da Contabo é virtualizada em KVM (indicado em contabo.com, verificado a 18 de outubro de 2026) e é a que usamos nos nossos próprios guias; as nossas notas sobre as alternativas estão em o VPS mais barato para uma VPN WireGuard.