WireGuard DNS DNAT: hâld it antwurdpaad oan 'e gong

DNAT skriuwt de bestimming oer, net de boarne. Beslis hoe't de upstream-resolver antwurdzje kin foardat jo de regel tafoegje, en hâld elke oerienkomst beheind.

It DNS-fraach fan in WireGuard-klant nei in oare resolver stjoere liket ien regel en hâldt him as trije besluten. De bestimming moat oerskreaun wurde, it pakket moat trochstjoerd wurde, en it antwurd moat syn wei werom fine troch de oersetstân dy't de gateway makke hat. Slach de tredde oer en de fraach giet skjin fuort wylst de klant ivich wachtet.

Nim it foarbyld fan autorisearre klanten yn 10.77.0.0/24 dy't oer wg0 komme, it oankundige adres 10.77.0.1 freegje en in resolver by 203.0.113.53 nedich hawwe. It upstream-adres is in dokumintaasje-plakhâlder en gjin wurkjende tsjinst.

It omlieden fan in fraach feroaret allinnich de bestimming

In bestimming-NAT-regel yn PREROUTING skriuwt it adres oer foardat it routingbeslút nommen wurdt, sadat it pakket dêrnei nei de nije bestimming rûte wurdt yn stee fan de âlde. It boarnekaders fan 'e klant bliuwt ûnoantaat troch dy operaasje. Dêrom kin in regel dy't folslein liket noch stilte jaan: it fersyk reizget no nei in resolver dy't nea fan it privee berik fan 'e klant heard hat. De gateway oersette ien fjild en erve in twadde probleem.

Beide DNS-transporten hawwe passende regels nedich, want in klant falt werom op TCP as in antwurd ôfkoarte wurdt.

De regels hjirûnder kieze ien ynkommend ynterface, ien klantberik en ien oarspronklik bestimmingsadres. Neat oars op 'e gateway wurdt beynfloede, en in fraach fan 'e gateway sels past hielendal net.

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

It antwurdpaad is in apart beslút

Twa regelingen litte it antwurd weromkomme, en ien betiid kieze sparret in debugsesje. Of de upstream-resolver hat in rûte werom nei 10.77.0.0/24 fia dizze gateway, of de gateway oerset de boarne by de útgong sadat it antwurd by in adres oankomt dat de upstream al ken. Beide wurkje; mar ien past by de kontrôle dy't jo oer de upstream hawwe.

Routing fertsjinnet de earste poging, want it hâldt it adres fan 'e klant sichtber foar de resolver en foarkomt in twadde oersetlaach. As de upstream bûten jo kontrôle is, is boarne-oersetting op it spesifike útgongynterface de praktyske kar.

Behein dy oersetting like strak as it omlieden, oars wurdt de regel in algemiene NAT foar alles dat der tafallich by past:

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

Ferbiningsspoaring hâldt de mapping pear, sadat it antwurd ûnderweis werom nei de oarspronklike tuple fan 'e klant oerskreaun wurdt. Sûnder de útgongregel stjoert de resolver syn antwurd nei in privee adres dat er net berikke kin, en de klant sjocht in time-out yn stee fan in flater.

Skriuw de regels smeller as de taak liket

Trochstjoerpermissy heart by deselde omfang. Stean de stream fan klant nei resolver en it weromferkear dat conntrack al werkenne ta, yn stee fan elke DNAT-ferbining op 'e masine te akseptearjen. In algemiene akseptaasje machtiget ek poartetrochstjoeringen dy't neat mei DNS te meitsjen hawwe.

De eigen resolver fan 'e gateway is in oare kodepaad. In fraach dy't lokaal útjûn wurdt giet troch OUTPUT, sadat testen fan 'e gateway-shell noch de PREROUTING-regel noch it trochstjoerbelied oefenet. Dêrom kin in lokale test slagje wylst elke klant mislearret, en it omkearde is like gewoan.

Neat hjir dekt DNS oer HTTPS op poarte 443 of DNS oer TLS op poarte 853, en neat dekt IPv6. In klant mei in konfigurearre IPv6-resolver sil de hiele regeling noflik negearje.

Wat in nije fraach bewiist

Ferbiningsspoaring betinkt eardere mappings, sadat in fraach dy't foar in regelwiziging stjoerd is út 'e âlde steat beantwurde wurde kin en de nije regel brutsen lykje lit. Begjin mei in nije boarne-poarte en, dêr't de klant antwurden yn 'e cache hat, mei in nije namme.

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

It earste kommando lit sjen oft it klantpaad hielendal oplost, en it twadde lit de oersetting sjen dy't de gateway wier ynstallearre hat, ynklusyf beide rjochtingen fan 'e tuple. In mapping dy't nei de juste resolver wiist mei in antwurdteller dy't op nul fêstsit, is in werompaadprobleem en gjin filterprobleem.

Befêstigje dat de resolver de nammen ken dy't jo ferwachtsje foardat jo eat omliede. In ferfanging dy't iepenbiere nammen beantwurdet, mar net jo privee sône feroaret in wurkjende syktocht yn in NXDOMAIN dy't der as in brutsen tunnel útsjocht. Test de resolver direkt, fan 'e gateway, foardat it klantpaad derby belutsen is. En referinsje foar iptables-útwreidings dokumintearret de DNAT- en masquerade-semantyk dêr't dizze regels op berêste.

Relatearre artikelen