VPNSmith
VPS Contabo
self-host-vpnINFO

wg-quick: line 32: resolvconf: command not found (solução WireGuard)

O wg-quick para na linha 32 porque a linha DNS chama o resolvconf, ausente em servidores mínimos. Solução: apt install openresolv, ou systemd-resolvconf se o systemd-resolved estiver ativo. 4 soluções e qual escolher.

Por Eric Gerard · Fundador · VPNSmith - Especialista em VPN auto-hospedada e VPS RGPD4 min de leituraFoto via Pexels

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.

Uma prateleira de supermercado em arame quase vazia fotografada de perto, com uma única caixa de cartão aberta de gnocchi ainda de pé, o resto da estante vazio
Uma prateleira de supermercado em arame quase vazia fotografada de perto, com uma única caixa de cartão aberta de gnocchi ainda de pé, o resto da estante vazio

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→

Perguntas frequentes

Porque é que o wg-quick diz resolvconf: command not found?
Porque o wg-quick não configura o DNS sozinho. Quando a configuração contém uma linha DNS, executa o comando externo resolvconf para a aplicar, e numa imagem de servidor mínima esse binário não está instalado. A configuração do túnel está correta; falta um programa auxiliar.
Posso simplesmente apagar a linha DNS?
Sim, e o túnel sobe de imediato. A consequência é que as resoluções de nomes continuam a ir para o teu resolver atual em vez de passarem pelo túnel, o que é uma fuga de DNS se o objetivo do túnel era a privacidade. Só é a resposta certa quando não precisavas de DNS no túnel.
Que pacote fornece o resolvconf?
Em Debian e Ubuntu é o openresolv ou o resolvconf, e em Arch é o openresolv. Num sistema que já corre o systemd-resolved, instalar outra implementação de resolvconf pode criar dois gestores para um só ficheiro, o que é pior do que o erro original.
Qual é a diferença entre resolvconf e systemd-resolved aqui?
Resolvem o mesmo problema de formas incompatíveis. O resolvconf é um pequeno programa que arbitra as escritas em /etc/resolv.conf; o systemd-resolved é um daemon que é dono do ficheiro através de um link simbólico e se configura com resolvectl. Escolhe o que já gere o teu sistema e não instales o outro.
Este erro significa que a minha VPN é insegura?
Não. O erro acontece antes de a interface estar totalmente configurada, por isso ou o túnel não sobe de todo, ou sobe sem a definição de DNS que pediste. O segundo caso merece atenção, porque o túnel funciona e as resoluções, discretamente, não o usam.