WireGuard DNS DNAT: panatilihing gumagana ang daanan ng sagot

Ang pagturo ng DNS query ng isang WireGuard client sa ibang resolver ay mukhang isang tuntunin at kumikilos na parang tatlong desisyon. Dapat muling isulat ang destinasyon, dapat ipasa ang packet, at dapat mahanap ng sagot ang daan pabalik sa pamamagitan ng estado ng pagsasalin na ginawa ng gateway. Laktawan ang ikatlo at malinis na aalis ang query habang ang client ay naghihintay magpakailanman.

Kunin ang halimbawa ng mga awtorisadong client sa 10.77.0.0/24 na dumarating sa wg0, nagtatanong sa inihayag na address 10.77.0.1 at nangangailangan ng resolver sa 203.0.113.53. Ang upstream address ay isang placeholder para sa dokumentasyon, hindi isang serbisyong gumagana.

Ang pag-redirect ng query ay nagbabago lamang ng destinasyon nito

Ang tuntuning NAT ng destinasyon sa PREROUTING ay nagsusulat muli ng address bago gawin ang desisyon sa routing, kaya ang packet ay iruruta pagkatapos patungo sa bagong destinasyon sa halip na ang luma. Ang source address ng client ay hindi nagagalaw ng operasyong iyon. Ito ang dahilan kung bakit ang tuntuning mukhang kumpleto ay maaari pa ring magdulot ng katahimikan: ang kahilingan ay naglalakbay ngayon patungo sa resolver na hindi kailanman nakarinig tungkol sa pribadong saklaw ng client. Isinalin ng gateway ang isang field at nagmana ng pangalawang problema.

Ang parehong DNS transport ay nangangailangan ng tugmang tuntunin, dahil ang client ay bumabalik sa TCP kapag ang sagot ay pinutol.

Pinipili ng mga tuntunin sa ibaba ang isang papasok na interface, isang saklaw ng client at isang orihinal na address ng destinasyon. Wala nang iba sa gateway ang naaapektuhan, at ang query mula sa gateway mismo ay hindi tugma.

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

Ang daanan ng sagot ay hiwalay na desisyon

Dalawang kaayusan ang nagpapahintulot sa sagot na bumalik, at ang maagang pagpili ng isa ay nakakatipid ng isang sesyon ng pag-debug. Alinman sa upstream resolver ay may ruta pabalik sa 10.77.0.0/24 sa pamamagitan ng gateway na ito, o isinasalin ng gateway ang pinagmulan sa labasan upang ang sagot ay makarating sa address na alam na ng upstream. Gumagana ang dalawa; isa lamang ang tumutugma sa kontrol na mayroon ka sa upstream.

Ang routing ay karapat-dapat sa unang pagtatangka, dahil pinapanatili nitong nakikita ng resolver ang address ng client at iniiwasan ang pangalawang antas ng pagsasalin. Kapag ang upstream ay wala sa iyong kontrol, ang pagsasalin ng pinagmulan sa partikular na exit interface ang praktikal na pagpipilian.

Limitahan ang pagsasaling iyon nang kasing higpit ng pag-redirect, kung hindi ay magiging NAT na pangkalahatang layunin ang tuntunin para sa anumang nagkataong tumutugma:

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

Pinapanatili ng connection tracking ang pagmamapa nang pares, kaya ang sagot ay muling isinusulat pabalik sa orihinal na tuple ng client sa pagbabalik. Kung walang tuntunin sa labasan, ipinapadala ng resolver ang sagot nito sa pribadong address na hindi nito maabot, at ang client ay nakakakita ng timeout sa halip na error.

Isulat ang mga tuntunin nang mas makitid kaysa sa hitsura ng gawain

Ang pahintulot sa pagpapasa ay kabilang sa parehong saklaw. Payagan ang daloy mula sa client patungo sa resolver at ang trapikong pabalik na kinikilala na ng conntrack, sa halip na tanggapin ang bawat koneksyong DNAT sa makina. Ang malawakang pagtanggap ay nagpapahintulot din ng pagpapasa ng port na walang kinalaman sa DNS.

Ang sariling resolver ng gateway ay ibang landas ng code. Ang query na inilabas nang lokal ay dumadaan sa OUTPUT, kaya ang pagsubok mula sa shell ng gateway ay hindi nagsasanay sa tuntuning PREROUTING ni sa patakarang pangpagpapasa. Ito ang dahilan kung bakit ang lokal na pagsubok ay maaaring pumasa habang bawat client ay nabigo, at ang kabaligtaran ay kasing karaniwan.

Wala rito ang sumasaklaw sa DNS sa HTTPS sa port 443 o DNS sa TLS sa port 853, at wala ring sumasaklaw sa IPv6. Ang client na may naka-configure na IPv6 resolver ay masayang magwawalang-bahala sa buong kaayusan.

Ano ang pinatutunayan ng bagong query

Naaalala ng connection tracking ang mga naunang pagmamapa, kaya ang query na ipinadala bago ang pagbabago ng tuntunin ay maaaring sagutin mula sa lumang estado at gawing parang sira ang bagong tuntunin. Magsimula sa bagong source port at, kung saan nagka-cache ng sagot ang client, sa bagong pangalan.

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

Ipinapakita ng unang utos kung ang daanan ng client ay nalulutas man, at ipinapakita ng pangalawa ang pagsasaling aktwal na inilagay ng gateway, kasama ang dalawang direksyon ng tuple. Ang pagmamapang tumuturo sa tamang resolver na ang counter ng sagot ay nakaipit sa sero ay problema sa daanan ng pagbabalik at hindi sa pagsasala.

Kumpirmahin na alam ng resolver ang mga pangalang inaasahan mo bago mag-redirect ng anuman. Isang kapalit na sumasagot sa mga pampublikong pangalan ngunit hindi sa iyong pribadong sona ginagawang NXDOMAIN na mukhang sirang tunnel ang isang gumaganang paghahanap. Subukan ang resolver nang direkta, mula sa gateway, bago masangkot ang daanan ng client. At ang sanggunian ng mga extension ng iptables ay nagdodokumento sa semantika ng DNAT at masquerade na pinagkakatiwalaan ng mga tuntuning ito.