A configuração está correta, as chaves coincidem, e wg-quick up wg0 para em:
/usr/bin/wg-quick: line 32: resolvconf: command not found
A mensagem nomeia exatamente o problema real, e quase ninguém a lê assim. Não está a dizer que a tua definição de DNS está errada. Está a dizer que um programa chamado resolvconf devia aplicá-la e não existe nesta máquina.
O que o wg-quick faz realmente com uma linha DNS
O wg-quick é um script de shell que envolve o comando wg. Quando a tua configuração contém:
[Interface]
DNS = 10.10.0.1
não escreve /etc/resolv.conf ele próprio. Executa o binário externo resolvconf e deixa esse programa arbitrar, porque várias coisas num sistema Linux podem querer controlar o resolver ao mesmo tempo, e sobrescrever o ficheiro diretamente é a forma como entram em conflito.
Numa distribuição desktop esse programa está presente. Numa imagem de servidor mínima, numa instância cloud ou num contentor, normalmente não está, e o script falha exatamente nessa linha.

Solução 1: instalar uma implementação de resolvconf
A resposta direta, quando nada mais gere o teu resolver:
apt install openresolv # Debian, Ubuntu
pacman -S openresolv # Arch
Depois o wg-quick up wg0 funciona sem alterações.
⛔ Não faças isto se o systemd-resolved estiver a correr. Terias então dois programas a reclamar autoridade sobre um só ficheiro, e o sintoma é pior do que o erro de partida: DNS que funciona até algo reiniciar e depois deixa de funcionar. Verifica primeiro:
systemctl is-active systemd-resolved
Solução 2: usar o systemd-resolved, que talvez já tenhas
Se esse comando responder active, a máquina já tem um gestor de resolver e o wg-quick pode falar com ele através de uma camada de compatibilidade. Em Debian e Ubuntu:
apt install systemd-resolvconf
Isto fornece um comando resolvconf que reencaminha para o systemd-resolved, em vez de uma segunda implementação independente. Confirma depois que o ficheiro é gerido como esperas:
ls -l /etc/resolv.conf
Um link simbólico para /run/systemd/resolve/ significa que o systemd-resolved é o dono. Um ficheiro normal significa que outra coisa o é, e vale a pena esclarecer isso antes de juntar um túnel à mistura.
Solução 3: definir o DNS tu próprio com PostUp
Se preferires não instalar nada, substitui a linha DNS por comandos que fazem o trabalho diretamente:
[Interface]
PostUp = printf 'nameserver 10.10.0.1\n' > /etc/resolv.conf
PostDown = printf 'nameserver 1.1.1.1\n' > /etc/resolv.conf
É rudimentar e funciona, mas tem dois limites que convém dizer. Sobrescreve o que estiver no ficheiro, por isso qualquer outra coisa que gira o resolver vai discordar de ti. E a linha PostDown tem de repor algo sensato, porque um túnel que desce e deixa um resolv.conf vazio leva o DNS consigo.
Para um contentor ou um VPS de uso único onde nada mais toca no resolver, é uma escolha perfeitamente razoável.
Solução 4: decidir que não precisas dele
Apaga a linha DNS e o túnel sobe de imediato.
É a resposta correta exatamente num caso: quando o túnel existe para chegar a uma rede, não para esconder as tuas resoluções. Uma ligação site a site entre dois servidores não tem razão para alterar o resolver de nenhuma das máquinas.
⛔ É a resposta errada quando o túnel serve a privacidade. Sem DNS no túnel, cada nome que resolves continua a ir para o teu resolver anterior em claro, e o facto de o tráfego ser encriptado depois não desfaz isso. A mecânica dessa fuga está em fugas de DNS no WireGuard.
Deste com este erro num portátil Linux com um .conf descarregado de uma VPN comercial? Não precisas de lutar com o wg-quick. A app Linux oficial da Proton VPN (Debian, Ubuntu, Fedora, Arch) gere o túnel através do NetworkManager em vez do wg-quick, por isso o resolvconf não entra em jogo, e envia o DNS para os seus próprios resolvers, com kill switch em todos os planos incluindo o Free (link de afiliado). Mantém as soluções acima quando o servidor é teu: a app só substitui o lado cliente de um serviço comercial.
Escolher entre elas
systemd-resolved already active -> systemd-resolvconf (fix 2) nothing manages the resolver -> openresolv (fix 1) container, single-purpose VPS -> PostUp (fix 3) tunnel between two servers -> remove the DNS line (fix 4)
Em resumo: systemd-resolved já ativo, solução 2; nada gere o resolver, solução 1; contentor ou VPS de uso único, solução 3; túnel entre dois servidores, solução 4.
Se só queres que os teus domínios internos sejam resolvidos através do túnel e o resto fique como está, é outra configuração: WireGuard split DNS (em inglês).
E se o túnel agora sobe mas nada carrega, o problema não era o DNS: vê MTU para páginas que ficam a carregar, e resolução de problemas de handshake se o wg show não indicar handshake nenhum.
★ Datacenter GDPR em Nuremberg · ✓ IPv4 dedicado incluído · porta de 200 Mbit/s
Aloje a sua VPN no seu próprio VPS → ContaboAcesso root completo · IPv4 público · escolha a sua região→


