WireGuard DNS DNAT: manteniu el camí de resposta en funcionament

Apuntar la consulta DNS d’un client de WireGuard a un altre resolutor sembla una sola regla i es comporta com tres decisions. Cal reescriure la destinació, cal reenviar el paquet i la resposta ha de trobar el camí de tornada a través de l’estat de traducció que ha creat la passarel·la. Si us salteu la tercera, la consulta surt neta mentre el client espera per sempre.

Prenem l’exemple de clients autoritzats a 10.77.0.0/24 que arriben per wg0, consulten l’adreça anunciada 10.77.0.1 i necessiten un resolutor a 203.0.113.53. L’adreça superior és un marcador de documentació, no un servei en funcionament.

Redirigir una consulta només en canvia la destinació

Una regla de NAT de destinació a PREROUTING reescriu l’adreça abans que es prengui la decisió d’encaminament, de manera que el paquet s’encamina després cap a la destinació nova en lloc de l’antiga. L’adreça d’origen del client no queda tocada per aquesta operació. Per això una regla que sembla completa encara pot produir silenci: la petició viatja ara a un resolutor que mai no ha sentit parlar del rang privat del client. La passarel·la va traduir un camp i va heretar un segon problema.

Tots dos transports DNS necessiten regles coincidents, perquè un client torna a TCP quan una resposta es trunca.

Les regles següents seleccionen una interfície d’entrada, un rang de clients i una adreça de destinació original. Res més de la passarel·la no queda afectat, i una consulta de la mateixa passarel·la no hi coincideix gens.

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

El camí de resposta és una decisió a part

Dues disposicions permeten que la resposta torni, i triar-ne una aviat estalvia una sessió de depuració. O bé el resolutor superior té una ruta de tornada a 10.77.0.0/24 a través d’aquesta passarel·la, o bé la passarel·la tradueix l’origen a la sortida perquè la resposta arribi a una adreça que el superior ja coneix. Totes dues funcionen; només una encaixa amb el control que teniu sobre el superior.

L’encaminament mereix el primer intent, perquè manté l’adreça del client visible per al resolutor i evita una segona capa de traducció. Quan el superior queda fora del vostre control, la traducció d’origen a la interfície de sortida concreta és l’opció pràctica.

Acoteu aquesta traducció tan estretament com la redirecció, o la regla esdevé un NAT d’ús general per a qualsevol cosa que hi coincideixi:

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

El seguiment de connexions manté l’assignació aparellada, de manera que la resposta es reescriu cap a la tupla original del client en tornar. Sense la regla de sortida, el resolutor envia la seva resposta cap a una adreça privada que no pot assolir, i el client veu un temps d’espera en lloc d’un error.

Escriviu les regles més estretes del que sembla la tasca

El permís de reenviament pertany al mateix àmbit. Permeteu el flux del client al resolutor i el trànsit de retorn que conntrack ja reconeix, en lloc d’acceptar cada connexió DNAT de la màquina. Una acceptació global també autoritza reenviaments de port que no tenen res a veure amb DNS.

El resolutor propi de la passarel·la és un camí de codi diferent. Una consulta emesa localment passa per OUTPUT, així que provar des de la consola de la passarel·la no exerceix ni la regla PREROUTING ni la política de reenviament. Per això una prova local pot passar mentre tots els clients fallen, i el contrari és igual de freqüent.

Aquí no es cobreix DNS sobre HTTPS al port 443 ni DNS sobre TLS al port 853, i no es cobreix IPv6. Un client amb un resolutor IPv6 configurat ignorarà alegrement tota la disposició.

Què demostra una consulta nova

El seguiment de connexions recorda assignacions anteriors, així que una consulta enviada abans d’un canvi de regla es pot respondre des de l’estat antic i fer que la regla nova sembli trencada. Comenceu amb un port d’origen nou i, allà on el client fa memòria cau de respostes, amb un nom nou.

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

La primera ordre mostra si el camí del client es resol, i la segona mostra la traducció que la passarel·la ha instal·lat realment, incloent-hi totes dues direccions de la tupla. Una assignació que apunta al resolutor correcte amb un comptador de respostes encallat a zero és un problema de camí de retorn, no de filtratge.

Confirmeu que el resolutor coneix els noms que espereu abans de redirigir res. Un substitut que respon a noms públics però no a la vostra zona privada converteix una consulta que funciona en un NXDOMAIN que sembla un túnel trencat. Proveu el resolutor directament, des de la passarel·la, abans que hi intervingui el camí del client. I referència d’extensions d’iptables documenta la semàntica de DNAT i masquerade de què depenen aquestes regles.