Permitir DNS apenas pelo seu próprio resolvedor VPN: um percurso passo a passo

Siga uma única consulta de nome desde o momento em que a escreve. O navegador pergunta ao sistema operativo, o sistema operativo pergunta ao resolvedor escolhido pela sua política, e a consulta sai do dispositivo por uma interface qualquer com um transporte qualquer. O seu desenho de VPN diz que a resposta deve vir de um resolvedor concreto por um caminho concreto. A diferença entre estas duas afirmações é o que configura e depois impõe.

Passo 1: nomeie o resolvedor e o caminho

Anote três coisas antes de tocar numa firewall: o endereço do resolvedor, o protocolo e a porta que espera, e a interface por onde a consulta deve sair. Sem essa lista, uma regra é uma suposição sobre tráfego e não a execução de uma decisão. Uma VPN pode transportar dados de aplicações enquanto o DNS segue um arranjo separado, e isso não é um erro por si só. É o que acontece quando ninguém disse outra coisa ao cliente.

Nomear o caminho de forma explícita é a diferença entre um desenho e um acidente. Também lhe dá algo para testar mais tarde, porque cada observação pode ser comparada com uma expectativa escrita. Guarde essa lista no ticket de mudança e não na cabeça de alguém.

Passo 2: coloque a política onde ela realmente vive

A escolha do resolvedor pertence ao cliente: a configuração de rede do sistema operativo, as definições do próprio cliente VPN ou uma política de navegador gerida. Coloque-a primeiro aí, com o mecanismo que a plataforma suporta, porque uma firewall não pode obrigar um cliente a escolher um resolvedor de que nunca ouviu falar. Num cliente com túnel dividido, diga explicitamente que domínios vão para o resolvedor interno. Numa frota gerida, a política do navegador é muitas vezes a única alavanca para DoH, porque o navegador pode escolher o seu próprio resolvedor cifrado independentemente da definição do sistema.

Salte isto e vá direto à firewall, e obtém uma regra que permite o resolvedor certo mais um cliente que nunca o usa. A regra parece correta e os registos do resolvedor ficam vazios, um par confuso de depurar. Configure primeiro a escolha e só depois a imponha.

Passo 3: imponha o caminho de forma estreita

Agora acrescente a permissão de rede para o caminho permitido: o endereço do resolvedor, o protocolo e a porta, e a interface por onde deve sair. Mantenha a regra limitada a esse resolvedor em vez de permitir todo o DNS de saída. Os três caminhos abaixo são os que um cliente moderno pode tomar, e só o primeiro é coberto por uma regra da porta 53.

Bloquear DoH e DoT é legítimo; supor que uma regra da porta 53 já os bloqueou não é. Um navegador com DoH resolve nomes por um caminho que a sua regra nunca descreveu, e uma aplicação que traz o seu próprio resolvedor faz o mesmo. Escreva cada caminho que pretende permitir e cada um que pretende recusar. Uma regra que não nomeia um caminho não decidiu nada sobre ele.

Passo 4: siga nomes privados e públicos

O DNS dividido envia deliberadamente apenas espaços de nomes privados para um resolvedor interno enquanto os nomes públicos vão para outro sítio, por isso mais do que um resolvedor no desenho não é uma fuga. A fuga é uma consulta que devia ter ido para o seu resolvedor e chega a outro lugar, ou um caminho previsto inalcançável que faz o cliente recuar em silêncio. São esses dois casos que deve procurar. Siga um nome interno e um nome público sob a política prevista e anote que resolvedor respondeu a cada um.

Um sítio de teste que reporta o seu resolvedor é uma pista, não uma prova, porque só vê as consultas que o alcançaram. Capture a consulta do lado do cliente quando precisar de saber que caminho tomou de facto, e compare as duas observações. Quando não coincidem, encontrou um recuo que ninguém documentou.

Se o endereço do resolvedor está correto mas inacessível, o problema está no encaminhamento ou na filtragem e não na política. Siga a consulta até esse endereço e confirme que a resposta volta pela interface esperada antes de alterar qualquer definição do resolvedor.

Passo 5: mantenha um caminho de volta

Antes de apertar o acesso DNS na gateway, confirme um método de recuperação que não dependa da resolução de nomes. Um resolvedor avariado torna cada ferramenta de reparação mais difícil de alcançar, incluindo as que usaria para desfazer a mudança. Mantenha uma consola local ou um caminho fora de banda aberta até a nova política estar provada. Remova-a só depois de a política ter sobrevivido a uma reconexão.

Depois de uma reconexão ou de uma atualização da política do navegador, inspecione novamente o estado efetivo, porque ambos podem mudar o resolvedor sem mudar a sua regra. O requisito é um destinatário conhecido e um caminho protegido para as consultas, não uma etiqueta de resolvedor tranquilizadora numa captura de ecrã. A especificação RFC 8484 de DNS over HTTPS é a referência para o caminho cifrado que a sua regra de porta não vê.