WireGuard DNS DNAT: păstrați funcțională calea răspunsului

Direcționarea interogării DNS a unui client WireGuard către alt resolver pare o singură regulă și se comportă ca trei decizii. Destinația trebuie rescrisă, pachetul trebuie transmis, iar răspunsul trebuie să-și găsească drumul înapoi prin starea de traducere creată de gateway. Săriți peste a treia și interogarea pleacă curat în timp ce clientul așteaptă la nesfârșit.

Luați exemplul clienților autorizați din 10.77.0.0/24 care sosesc prin wg0, interoghează adresa anunțată 10.77.0.1 și au nevoie de un resolver la 203.0.113.53. Adresa din amonte este un substituent de documentație, nu un serviciu funcțional.

Redirecționarea unei interogări schimbă doar destinația

O regulă NAT de destinație în PREROUTING rescrie adresa înainte de a se lua decizia de rutare, astfel încât pachetul este apoi rutat către noua destinație în loc de cea veche. Adresa de sursă a clientului rămâne neatinsă de acea operație. De aceea o regulă care pare completă poate produce totuși tăcere: cererea călătorește acum către un resolver care nu a auzit niciodată de intervalul privat al clientului. Gateway-ul a tradus un câmp și a moștenit o a doua problemă.

Ambele transporturi DNS au nevoie de reguli potrivite, deoarece un client revine la TCP atunci când un răspuns este trunchiat.

Regulile de mai jos selectează o interfață de intrare, un interval de clienți și o adresă de destinație originală. Nimic altceva de pe gateway nu este afectat, iar o interogare a gateway-ului însuși nu se potrivește deloc.

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

Calea răspunsului este o decizie separată

Două aranjamente permit întoarcerea răspunsului, iar alegerea unuia devreme economisește o sesiune de depanare. Fie resolverul din amonte are o rută înapoi la 10.77.0.0/24 prin acest gateway, fie gateway-ul traduce sursa la ieșire astfel încât răspunsul să ajungă la o adresă pe care partea din amonte o știe deja. Ambele funcționează; doar unul corespunde controlului pe care îl aveți asupra părții din amonte.

Rutarea merită prima încercare, pentru că păstrează adresa clientului vizibilă pentru resolver și evită un al doilea strat de traducere. Când partea din amonte este în afara controlului dumneavoastră, traducerea sursei pe interfața de ieșire specifică este alegerea practică.

Limitați acea traducere la fel de strict ca redirecționarea, altfel regula devine un NAT de uz general pentru orice se potrivește întâmplător:

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

Urmărirea conexiunilor menține maparea în perechi, astfel încât răspunsul este rescris înapoi la tuple-ul original al clientului la întoarcere. Fără regula de ieșire, resolverul trimite răspunsul către o adresă privată pe care nu o poate atinge, iar clientul vede un timeout în loc de o eroare.

Scrieți regulile mai înguste decât pare sarcina

Permisiunea de redirecționare aparține aceluiași domeniu. Permiteți fluxul de la client la resolver și traficul de retur pe care conntrack îl recunoaște deja, în loc să acceptați fiecare conexiune DNAT de pe mașină. O acceptare generală autorizează și redirecționări de porturi care nu au nimic de-a face cu DNS.

Resolverul propriu al gateway-ului este o altă cale de cod. O interogare emisă local trece prin OUTPUT, așa că testarea din shell-ul gateway-ului nu exersează nici regula PREROUTING, nici politica de redirecționare. De aceea un test local poate trece în timp ce fiecare client eșuează, iar inversul este la fel de frecvent.

Nimic de aici nu acoperă DNS peste HTTPS pe portul 443 sau DNS peste TLS pe portul 853 și nimic nu acoperă IPv6. Un client cu un resolver IPv6 configurat va ignora bucuros întreaga aranjare.

Ce demonstrează o interogare nouă

Urmărirea conexiunilor își amintește mapările anterioare, așa că o interogare trimisă înainte de o schimbare de regulă poate primi răspuns din starea veche și poate face noua regulă să pară stricată. Începeți cu un port de sursă nou și, unde clientul memorează răspunsuri, cu un nume nou.

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

Prima comandă arată dacă calea clientului se rezolvă deloc, iar a doua arată traducerea pe care gateway-ul a instalat-o efectiv, inclusiv ambele direcții ale tuple-ului. O mapare care indică resolverul corect cu un contor de răspunsuri blocat la zero este o problemă de cale de retur, nu de filtrare.

Confirmați că resolverul cunoaște numele pe care le așteptați înainte de a redirecționa ceva. Un înlocuitor care răspunde la nume publice dar nu la zona dumneavoastră privată transformă o căutare funcțională într-un NXDOMAIN care arată ca un tunel stricat. Testați resolverul direct, de pe gateway, înainte ca calea clientului să fie implicată. Iar referința extensiilor iptables documentează semantica DNAT și masquerade pe care se bazează aceste reguli.