Porque é que as consultas do dnsmasq escapam da VPN após um redirecionamento DNS

O cliente da LAN chega corretamente à sua VPN e, no entanto, as suas consultas DNS aparecem no uplink errado. Não é uma fuga no sentido habitual; é o que acontece quando o router deixa de encaminhar uma consulta e responde ele mesmo. A interceção reescreve o destino para um socket local, e depois o resolver abre uma segunda conversa, não relacionada, com o seu próprio endereço de origem e a sua própria decisão de encaminhamento. As marcas aplicadas ao fluxo do cliente descrevem a primeira conversa e absolutamente nada sobre a segunda.

A marca não viaja com a consulta

As marcas de pacote vivem numa entrada conntrack e no pacote em voo. Uma regra REDIRECT termina esse voo: a carga é entregue a um socket local e a entrada original já fez o seu trabalho. O que sai do router depois é um socket novo criado pelo processo do resolver, com o endereço do próprio router como origem.

É por isso que uma rota de política baseada no endereço do cliente da LAN nunca coincide com a consulta ascendente. O novo socket pertence ao dnsmasq e não ao cliente, e o kernel avalia a rota para o tráfego do próprio router. As regras de origem, as regras de interface e as regras de marca veem todas um tuplo diferente. Assumir que a marca se propaga é o erro mais comum nesta configuração e é invisível numa captura do lado do cliente.

As duas conversas partilham de facto um nome e um momento, e é isso que as faz parecer um único fluxo quando se folheia uma captura.

Onde o encaminhamento se torna resolução local

Comece por descobrir se a porta 53 é redirecionada, traduzida para outro host ou deixada intacta, porque os três casos comportam-se de forma diferente. Um redirecionamento para uma porta local termina o encaminhamento, enquanto uma tradução para outra máquina mantém o pacote em movimento e mantém o tuplo do cliente significativo.

Veja os dois protocolos. Um resolver acessível por UDP e TCP será testado nos dois, e um conjunto de regras que só cobre UDP deixa um buraco silencioso para respostas grandes. As regras geradas pelo próprio gestor de configuração do router também contam, e editar um ficheiro gerado costuma perder para o recarregamento seguinte.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Essas saídas respondem a três perguntas por ordem: o que reescreve a consulta, o que a recebe e que processo é dono do socket à escuta. Assim que o dono é conhecido, a política ascendente tem onde viver.

Dê ao resolver a sua própria política de saída

Um upstream específico de domínio é a ferramenta mais limpa quando só alguns nomes precisam do túnel. O dnsmasq aceita uma linha server limitada a um domínio, com uma interface ou endereço de origem opcional que encaminha a consulta para fora de um dispositivo escolhido. É esse direcionamento que faz a segunda conversa seguir a VPN.

server=/corp.example/10.30.0.53@tun_work
log-queries

O domínio, o endereço e a interface acima são marcadores de posição para os seus próprios valores. A seleção de domínio e o controlo de saída continuam a ser decisões separadas: a rota tem de existir, o endereço de origem tem de ser permitido pelo resolver ascendente e a firewall tem de permitir a resposta. O direcionamento só por interface não é fail-closed, porque um túnel que desaparece pode deixar o resolver a cair para outro caminho. Mantenha qualquer alternativa pública longe de um espaço de nomes que tem de permanecer privado.

Coloque a linha no dono da configuração que o router suporta e não num ficheiro gerado, ou o recarregamento seguinte apaga a correção.

O que uma cache partilhada não consegue preservar

Um único reencaminhador com uma única cache serve cada cliente da LAN, e isso derruba uma distinção de que algumas redes precisam. Se dois clientes tiverem de resolver o mesmo nome de forma diferente, o socket partilhado não tem maneira de recuperar qual cliente perguntou. A política por cliente tem de viver em instâncias de resolver separadas ou numa funcionalidade de encaminhamento que preserve a identidade.

Uma resposta em cache também não é prova sobre o novo caminho. A resposta pode vir da memória enquanto a rota ascendente continua quebrada.

As regras da porta 53 não dizem nada sobre aplicações que falam DNS sobre HTTPS ou sobre TLS. Essas consultas nunca chegam ao redirecionamento, portanto uma política construída apenas sobre a porta 53 descreve um subconjunto do tráfego e deve ser documentada como subconjunto.

Verifique a segunda conversa, não a primeira

Teste com um nome que controla e observe os dois lados. Uma captura do lado do cliente prova que a consulta saiu da LAN; só o lado do router prova para onde foi depois.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Limpe a cache antes de cada tentativa, porque uma resposta quente esconde um upstream quebrado. Repita sobre TCP e depois repita com o túnel em baixo para ver o que o resolver faz quando o seu caminho preferido desapareceu. É esse último comportamento que decide se o desenho é fail-closed ou apenas sortudo.