WireGuard DNS DNAT: mantén operativa a ruta de resposta

Apuntar a consulta DNS dun cliente de WireGuard a outro resolutor semella unha soa regra e compórtase como tres decisións. Hai que reescribir o destino, hai que reenviar o paquete e a resposta ten que atopar o camiño de volta a través do estado de tradución que creou a pasarela. Se saltas a terceira, a consulta sae limpa mentres o cliente espera para sempre.

Tomemos o exemplo de clientes autorizados en 10.77.0.0/24 que chegan por wg0, consultan o enderezo anunciado 10.77.0.1 e necesitan un resolutor en 203.0.113.53. O enderezo superior é un marcador de documentación, non un servizo en funcionamento.

Redirixir unha consulta só cambia o seu destino

Unha regra de NAT de destino en PREROUTING reescribe o enderezo antes de que se tome a decisión de encamiñamento, así que o paquete encamíñase despois cara ao novo destino en lugar do antigo. O enderezo de orixe do cliente queda intacto por esa operación. Por iso unha regra que parece completa pode seguir producindo silencio: a petición viaxa agora a un resolutor que nunca oíu falar do rango privado do cliente. A pasarela traduciu un campo e herdou un segundo problema.

Ambos os transportes DNS necesitan regras coincidentes, porque un cliente recorre a TCP cando unha resposta se trunca.

As regras seguintes seleccionan unha interface de entrada, un rango de clientes e un enderezo de destino orixinal. Nada máis na pasarela se ve afectado, e unha consulta da propia pasarela non coincide en absoluto.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

A ruta de resposta é unha decisión aparte

Dúas disposicións permiten que a resposta volva, e escoller unha cedo aforra unha sesión de depuración. Ou ben o resolutor superior ten unha ruta de volta a 10.77.0.0/24 a través desta pasarela, ou ben a pasarela traduce a orixe na saída para que a resposta chegue a un enderezo que o superior xa coñece. Ambas funcionan; só unha encaixa co control que tes sobre o superior.

O encamiñamento merece o primeiro intento, porque mantén o enderezo do cliente visible para o resolutor e evita unha segunda capa de tradución. Cando o superior queda fóra do teu control, a tradución de orixe na interface de saída concreta é a opción práctica.

Acouta esa tradución coa mesma estreiteza que a redirección, ou a regra convértese nun NAT de propósito xeral para calquera cousa que coincida con ela:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

O seguimento de conexións mantén a asignación emparellada, así que a resposta reescríbese de volta á tupla orixinal do cliente á volta. Sen a regra de saída, o resolutor envía a súa resposta cara a un enderezo privado que non pode alcanzar, e o cliente ve un tempo de espera en lugar dun erro.

Escribe as regras máis estreitas do que parece a tarefa

O permiso de reenvío pertence ao mesmo ámbito. Permite o fluxo do cliente ao resolutor e o tráfico de retorno que conntrack xa recoñece, en lugar de aceptar cada conexión DNAT da máquina. Unha aceptación global tamén autoriza redireccións de portos que non teñen nada que ver con DNS.

O resolutor propio da pasarela é unha ruta de código distinta. Unha consulta emitida localmente pasa por OUTPUT, así que probar desde a consola da pasarela non exercita nin a regra PREROUTING nin a política de reenvío. Por iso unha proba local pode pasar mentres todos os clientes fallan, e o contrario é igual de frecuente.

Nada disto cobre DNS sobre HTTPS no porto 443 nin DNS sobre TLS no porto 853, e nada cobre IPv6. Un cliente cun resolutor IPv6 configurado ignorará alegremente toda a disposición.

Que demostra unha consulta nova

O seguimento de conexións lembra asignacións anteriores, así que unha consulta enviada antes dun cambio de regra pode responderse desde o estado antigo e facer que a regra nova pareza rota. Comeza cun porto de orixe novo e, onde o cliente cachea respostas, cun nome novo.

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

O primeiro comando mostra se a ruta do cliente resolve sequera, e o segundo mostra a tradución que a pasarela instalou realmente, incluídas ambas as direccións da tupla. Unha asignación que apunta ao resolutor correcto cun contador de respostas atascado en cero é un problema de ruta de retorno e non de filtrado.

Confirma que o resolutor coñece os nomes que esperas antes de redirixir nada. Un substituto que responde a nomes públicos pero non á túa zona privada converte unha busca que funciona nun NXDOMAIN que parece un túnel roto. Proba o resolutor directamente, desde a pasarela, antes de que interveña a ruta do cliente. E referencia de extensións de iptables documenta a semántica de DNAT e masquerade da que dependen estas regras.