O DNS da VPN assume cada consulta: corrija o dns-priority no NetworkManager

Conecte a VPN do escritório e, de repente, cada consulta de nome vai para o resolver corporativo. Os nomes públicos ainda resolvem, então nada parece quebrado até o nome de uma impressora local falhar ou um registo split-horizon devolver o endereço do escritório. Em algumas instalações do Fedora acontece o contrário: o resolver do fornecedor continua a responder depois que o túnel sobe. Ambos são uma só pergunta — qual resolver é dono desta consulta — e nos sistemas NetworkManager a resposta vive nas propriedades DNS de cada conexão.

Duas conexões, um resolver vencedor

Cada conexão declara uma prioridade DNS. As conexões comuns têm 50 por padrão e as de VPN têm 0, e o menor valor vence. É justamente esse padrão que faz uma conexão VPN superar em silêncio a ligação por cabo para cada domínio que reivindica: zero vence cinquenta sem que ninguém tenha escolhido isso.

A prioridade ordena os candidatos. Ela não limita sobre o que o vencedor é questionado. Uma conexão VPN sem domínio de busca reivindica tudo, então preferi-la também envia as consultas públicas para dentro do túnel e, num projeto de túnel dividido, para onde o resolver corporativo encaminha.

A prioridade decide a ordem, a lista de busca decide a posse

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

A lista de busca é a declaração de posse. Um domínio nu como corp.example torna-se um sufixo de busca e um domínio de encaminhamento. A forma só de encaminhamento ~corp.example envia as consultas sob esse sufixo para esta conexão sem acrescentar o domínio aos nomes curtos. Esse til é a diferença entre «pergunta a este servidor» e «pergunta a este servidor e termina a minha digitação».

Use as duas formas quando os utilizadores escrevem nomes de anfitrião curtos e os registos também são endereçados por nomes totalmente qualificados. Use apenas a forma de encaminhamento quando quiser a divisão sem alterar a forma como o resolver completa um nome nu.

Depois torne a preferência explícita e reative a conexão:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Uma prioridade negativa é a forma documentada de dizer «prefira esta conexão», e definir as duas famílias de endereços mantém o comportamento consistente num anfitrião com conectividade IPv6. Alterar a propriedade sem reativar a conexão não muda nada do que está a correr agora, por isso a sequência termina com um up explícito.

Deixe o systemd-resolved manter a divisão

O plugin dnsmasq predefinido canaliza as consultas para um único resolver local, então a separação por ligação fica grosseira. O systemd-resolved expõe a divisão por ligação, e resolvectl query nomeia a ligação que respondeu.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Depois disso, a ligação corporativa transporta corp.example e um resolver público serve o resto. Quando uma consulta chega à ligação errada, o comando nomeia a ligação que lhe respondeu, e saber isso vale mais do que saber apenas o endereço.

Ajuste o projeto de DNS ao tipo de túnel

Os projetos de privacidade que enviam tudo pelo túnel não devem ter uma lista de divisão, porque ela devolveria os nomes públicos ao resolver local e anularia a intenção. Os projetos de túnel dividido precisam de uma: sem ela o resolver corporativo vê cada consulta pública, e a configuração quebra no momento em que o túnel cai.

Depois há o kill switch que bloqueia o DNS fora do túnel. Os nomes resolvem-se para as zonas do túnel e falham em todo o resto enquanto a conexão está perfeitamente saudável. As respostas viáveis são uma autorização explícita para o resolver da LAN ou uma cache local que só encaminha a zona corporativa, e qualquer uma delas é uma exceção com dono e não um defeito no túnel.

Um perfil que reescreve a configuração do resolver no arranque da interface comporta-se quase da mesma forma: assim que o resolver local fica inalcançável, só se resolvem os nomes que o túnel conhece. Seja qual for o mecanismo aplicável, anote que nomes devem funcionar em cada estado e entregue essa lista a quem trata dos relatórios.

Verifique por ligação e depois outra vez após reconectar

Pergunte um nome interno e um público, e veja para onde a consulta vai realmente. Uma página de verificação de fugas diz qual resolver respondeu, não qual ligação o sistema escolheu, por isso não diz nada sobre a ordem que acabou de configurar.

Execute as duas consultas outra vez depois de desligar e voltar a ligar. As prioridades são reaplicadas quando uma conexão se ativa, e uma ligação simbólica antiga pode sobreviver a uma atualização de que ninguém se lembra. O que quer deixar escrito no fim é qual resolver é dono de qual sufixo, mais uma verificação que ainda valha amanhã.