Dê à sua VPN doméstica os seus próprios registos DNS para nas.home.arpa
Publique um nome a partir do dnsmasq, encaminhe o resolver pelo WireGuard e depois escolha entre enviar o DNS a todo o cliente e um split-DNS apenas para home.arpa.
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
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine 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.