Qual ligação responde: domínios de encaminhamento para o DNS de uma VPN com túnel dividido

Mantenha a navegação normal na ligação local enquanto os nomes da empresa são resolvidos pelo servidor DNS fornecido pelo túnel. Desativar a rota predefinida da VPN dá-lhe a primeira metade e deixa a segunda por construir. Seguem-se a definição em falta, a pontuação que lhe muda o sentido e o único comando que mostra qual ligação respondeu realmente. Assume-se NetworkManager e systemd-resolved ao longo do texto, porque é nesse par que a confusão costuma começar.

Primeiro passo: separe a rota do resolvedor

ipv4.never-default responde a uma pergunta de encaminhamento e impede o NetworkManager de instalar esta ligação como o caminho para todo o tráfego IPv4. Um domínio de encaminhamento DNS responde a outra pergunta: quais servidores de nomes de qual ligação recebem uma consulta para um sufixo correspondente. Nenhum implica o outro, e um perfil pode transportar um durante anos enquanto lhe falta o outro. Só rota significa que o túnel transporta as sub-redes da empresa e o seu resolvedor responde aos nomes da empresa, enquanto tudo o resto fica intacto.

Defina apenas a propriedade da rota e os nomes internos falham, normalmente com um tempo limite que soa a túnel avariado. Defina apenas o domínio e acrescentou em silêncio um sufixo de pesquisa a cada nome curto da máquina. Ambos os erros enviam o pedido de suporte para o servidor VPN, que raramente é a parte errada.

Segundo passo: acrescente um domínio só de encaminhamento ao perfil

Suponha que a ligação se chama corp-vpn, que o sufixo da empresa é internal.example e que o resolvedor do túnel já está acessível. Leia primeiro os valores atuais, porque os comandos abaixo alteram propriedades que podem já ter entradas.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Substitua pelo seu próprio nome de ligação e sufixo, porque os valores acima são ilustrativos. O sinal de mais importa mais do que parece: com ele o valor é acrescentado à lista existente, enquanto sem ele a propriedade é substituída e domínios não relacionados desaparecem de um perfil que ontem funcionava. O til muda o comportamento, não o estilo, e o parágrafo abaixo explica o que seleciona. Mantenha a leitura antes da escrita, para que a forma de substituição nunca o surpreenda.

Um til inicial marca um domínio só de encaminhamento, por isso as consultas correspondentes vão para os servidores desta ligação e o sufixo não é acrescentado aos nomes curtos. Retire o til e a mesma cadeia torna-se também um sufixo de pesquisa, um resultado diferente que as pessoas raramente pretendem. Ambas as definições acima são IPv4, por isso um perfil de dupla pilha precisa de ipv6.never-default e do mesmo domínio de encaminhamento em ipv6.dns-search, senão o lado IPv6 continua a usar a rota predefinida e os nomes internos falham lá.

Terceiro passo: pergunte ao resolvectl qual ligação respondeu

Execute resolvectl status e leia os servidores DNS e os domínios de cada ligação, depois execute resolvectl query host.internal.example contra um nome interno real que tenha permissão para consultar. O segundo comando é a única prova direta de que o domínio de encaminhamento faz o seu trabalho, porque nomeia a ligação que respondeu. Uma lista de estado sozinha prova a configuração; a consulta prova a resolução.

O systemd-resolved escolhe o domínio de encaminhamento que melhor corresponde, por isso um domínio mais específico noutra ligação pode ainda ganhar a corrida. Se a consulta voltar de uma ligação que não esperava, leia as listas de domínios antes de mexer no servidor DNS da VPN. Um domínio raiz de ~. corresponde a tudo, e se já estiver presente o seu domínio específico continua a ganhar para os seus próprios nomes enquanto a ligação responde a muito mais do que pediu. Remova ou estreite essa entrada raiz quando a intenção era apenas nomes da empresa.

Se a ligação VPN não lista qualquer servidor DNS, o cliente nunca registou nenhum. Um domínio de encaminhamento sem servidor atrás falha de forma diferente de um domínio em falta, por isso corrija primeiro o registo.

Quarto passo: quando o nome resolve mas o serviço não

Uma resposta correta prova apenas que a resolução funcionou, e a aplicação ainda precisa de uma rota para o endereço recebido. Essa rota tem de sobreviver à rota predefinida dividida que acabou de configurar, por isso verifique-a antes de culpar novamente o DNS. Depois verifique a acessibilidade na porta do serviço, porque uma partilha de ficheiros ou um serviço de diretório falha na resolução, no encaminhamento ou na autenticação e produz mensagens muito semelhantes em cada caso. Mantenha essas três camadas separadas quando relata o resultado, ou a pessoa seguinte volta a verificar um DNS que já estava correto.

A alteração no Samba que circula ao lado desta pergunta diz respeito à camada de acesso, não à escolha de DNS. Aplicá-la a uma falha de resolução de nomes é a forma como um problema pequeno adquire um segundo.

Quinto passo: não substitua o resolvedor para corrigir um domínio em falta

O conselho que substitui o ficheiro do resolvedor ou instala outro gestor de resolvedor resolve um problema diferente. São alterações de integração do sistema com os seus próprios modos de falha, e nenhuma acrescenta um domínio de encaminhamento que nunca foi configurado. Determine que componente é dono da resolução de nomes na máquina antes de o substituir, porque num ambiente de trabalho NetworkManager com systemd-resolved essa propriedade já está definida. Lutar contra ela é a forma como uma configuração funcional se torna algo que ninguém consegue reproduzir.

Ordem de trabalho: confirme que o túnel fornece um resolvedor, acrescente o domínio só de encaminhamento, volte a ligar através dos controlos do perfil, verifique a ligação que responde e depois teste o serviço na sua porta. Essa sequência deixa um resultado que pode entregar à pessoa seguinte sem uma segunda entrevista.