Depois de o túnel estar levantado, o último passo é normalmente um nome que funciona em vez de um endereço que cola num marcador. Um registo de anfitrião do dnsmasq mais um endereço de resolver que o cliente consegue alcançar fazem isso com dois ficheiros e sem multicast. A decisão que realmente exige reflexão é mais estreita: o cliente envia todo o DNS pelo resolver de casa, ou apenas os nomes sob home.arpa? Tudo o que se segue pressupõe uma instalação de WireGuard aprovada com um cliente Linux e um resolver de laboratório que o administrador de casa já gere.

Três formas de entregar um resolver ao cliente

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

Para um portátil que se junta ao túnel ocasionalmente, o split-DNS é a melhor predefinição: mantém os nomes de internet comuns no resolver em que a máquina já confia. Para uma máquina que existe para alcançar os serviços de casa, enviar o resolver é mais simples e o custo do âmbito não importa.

Publique o registo no resolver que detém a zona

Mantenha os papéis separados antes de escrever configuração: o endereço do cliente VPN, o resolver e o serviço são três anfitriões diferentes com três tarefas diferentes. Neste laboratório são 10.77.0.2 para o cliente, 192.168.50.53 para o dnsmasq e 192.168.50.20 para o NAS, com o túnel a encaminhar a LAN de casa.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

A linha host-record fornece o endereço e a linha local= mantém as perguntas desconhecidas de home.arpa dentro deste resolver em vez de as reencaminhar para cima. Leia primeiro a configuração existente e reconcilie tudo o que já define um servidor, uma interface ou o mesmo domínio local; empilhar um fragmento sobre um conflituoso produz um resolver que carrega alegremente e responde mal. O manual do dnsmasq define ambas as diretivas e os controlos de escuta.

Depois verifique o serviço em execução, não o ficheiro. Um teste de configuração mais um reinício é o mínimo, e a resposta efetiva é o que uma consulta devolve.

Encaminhe o resolver, não apenas a página web

O AllowedIPs do WireGuard decide que destinos entram no túnel. Se o endereço do resolver ficar de fora, a consulta sai pela rota normal e nunca chega ao dnsmasq, embora o próprio NAS seja acessível. Inclua o endereço do resolver, ou o prefixo de LAN que o contém, e verifique a política de reencaminhamento da gateway do outro lado.

Permita UDP e TCP na porta 53 a partir do intervalo de túnel autorizado, com um caminho de regresso ao endereço de túnel do cliente. Não reencaminhe a porta 53 a partir da WAN para facilitar os testes: um resolver recursivo aberto numa ligação doméstica é encontrado em poucas horas. Ligar-se a uma interface não é, por si só, uma política de acesso.

Verifique a resposta antes da aplicação

Pergunte primeiro ao resolver diretamente, depois ao sistema, depois à aplicação. Cada passo isola um elo da cadeia, e a diferença entre eles é o diagnóstico.

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

Vale a pena executar a consulta TCP porque uma resposta UDP truncada força uma nova tentativa, e uma política que descarta TCP 53 produz falhas que parecem intermitentes. O passo getent mostra o que a configuração de resolver da máquina faz realmente, o que nem sempre é o que enviou.

Decida o que acontece quando o túnel está em baixo

Se o DNS geral do cliente aponta para 192.168.50.53, toda a resolução de nomes deixa de funcionar quando o túnel não está levantado. Isso é aceitável numa máquina que só é útil com o túnel, e inaceitável num portátil que também usa o Wi-Fi de um café. O split-DNS evita a questão por completo, porque só as pesquisas de home.arpa dependem do resolver de casa.

Lembre-se do que é o nome: home.arpa está reservado para redes residenciais e não é único a nível global, pelo que outra rede pode usar legitimamente o mesmo nome. É uma conveniência local, não um identificador fiável. Mantenha o registo atualizado quando o serviço se muda, e retire a política do resolver quando o laboratório é desativado em vez de deixar um portátil a apontar para um endereço a que só consegue chegar por um túnel que já não existe.

Artigos relacionados