DNS do OpenVPN no gateway: dnsmasq e alcance do firewall

Execute o dnsmasq no endereço do túnel, permita DNS apenas do conjunto de clientes, propague o resolvedor e depois teste consultas diretas e a pesquisa do próprio aplicativo.

Os clientes no túnel alcançam o gateway, e o gateway alcança o resolvedor interno, então o DNS deveria funcionar. Não funciona, porque são duas permissões diferentes e um serviço DNS funcional é uma terceira coisa. O ouvinte precisa existir num endereço que os clientes alcancem, o firewall precisa permitir consultas a esse endereço, e o cliente precisa ser informado de que o usa. Abrir o túnel nos dois sentidos resolve os dois primeiros por acidente e deixa o terceiro por fazer.

O ouvinte é um serviço local com duas direções

Na entrada, um cliente envia uma consulta ao endereço do túnel do gateway na porta 53. Na saída, o daemon encaminha essa consulta ao seu servidor ascendente configurado. As duas metades precisam funcionar, e falham de maneiras diferentes.

Um tempo limite informado pelo cliente e um tempo limite visto no gateway não são a mesma avaria.

Vincule o endereço do túnel, não todos os endereços

Uma instância dedicada do dnsmasq para esta tarefa precisa de um endereço de escuta explícito, um modo de vinculação que tolere o aparecimento do túnel depois do arranque e um ascendente claro. Esta é a versão menor que uso:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic vincula os endereços individuais e lida com o caso em que tun0 aparece mais tarde, o que importa num host onde o serviço VPN reinicia. Listar o loopback mantém as ferramentas locais a funcionar sem acrescentar um ouvinte público. no-resolv impede o daemon de herdar ascendentes da configuração do resolvedor do host, e no-hosts impede esta instância de publicar o arquivo hosts do gateway. Nenhuma dessas opções dá a alguém permissão para consultar o serviço.

Verifique se há um ouvinte já existente na porta 53 antes de iniciar um segundo daemon, e use o proprietário da configuração da distribuição em vez de um arquivo perdido no diretório errado.

Permita a entrada de DNS, não o trânsito do túnel

As regras de firewall que fazem isto funcionar são regras de entrada local limitadas à interface do túnel, ao conjunto de clientes, ao endereço do gateway e à porta 53. Duas regras, uma por protocolo, bastam:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

O DNS funciona sobre TCP tal como sobre UDP, portanto uma regra só para UDP deixa as respostas grandes falhando de uma forma que parece intermitente. Estas não são ufw route permissões, e não devem tornar-se uma permissão ampla em tun0. A ordem importa tanto como o conteúdo: uma regra anterior que descarte toda a entrada de tun0 continua a ganhar, e acrescentar uma permissão abaixo de um descarte terminal não cria nada.

Se o DNS do gateway agora faz parte do desenho, reveja essa política anterior de propósito e registe porquê.

A metade ascendente é um caminho à parte

As consultas saem do gateway a partir do seu próprio endereço em direção ao resolvedor ascendente, portanto a rota do gateway e a política de saída para esse resolvedor têm de permitir a troca. É uma regra diferente da que deixa os clientes chegar ao ouvinte, e falha com um sintoma diferente.

Não acrescente saída de túnel sem restrições para fazer as respostas funcionar; as respostas rastreadas não precisam disso.

Propague a opção e depois verifique a entrega

O servidor pode anunciar o resolvedor aos clientes com uma opção propagada. Isso é uma opção, não uma instrução que o sistema operativo tenha de obedecer:

push "dhcp-option DNS 10.90.0.1"

Um cliente Linux de linha de comandos pode precisar da integração do resolvedor do seu gestor de ligações, e um dispositivo gerido pode precisar do perfil de gestão atualizado. Confirme o resolvedor ativo no cliente depois de ligar em vez de assumir que a propagação foi aplicada. Quando dois mecanismos tentam definir o DNS ao mesmo tempo, surge uma corrida que se apresenta como resolução intermitente.

O objetivo é um único proprietário da configuração do resolvedor do cliente, e a propagação costuma ser esse proprietário apenas quando a plataforma do cliente concorda.

Teste o que realmente construiu

Consulte um nome privado totalmente qualificado e um nome externo permitido diretamente contra o endereço do túnel, por UDP e TCP. Depois repita pelo caminho de pesquisa habitual da aplicação.

Se as consultas diretas funcionarem e a aplicação continuar a falhar, a avaria está na entrega e não no servidor:

  • O cliente nunca aplicou a opção propagada.
  • Outro resolvedor foi definido mais tarde e ganhou a corrida.
  • A aplicação usa a sua própria biblioteca de resolvedores ou uma resposta em cache.

Termine confirmando que uma origem fora do caminho VPN aprovado não pode usar o ouvinte de todo. Uma resolução bem-sucedida não autoriza o endereço que devolveu, por isso mantenha essas duas perguntas separadas.

Artigos relacionados