WireGuard DNS DNAT: weka njia ya jibu ifanye kazi

Kuelekeza swali la DNS la mteja wa WireGuard kwa resolver nyingine huonekana kama kanuni moja na hujiendesha kama maamuzi matatu. Lengwa linapaswa kuandikwa upya, pakiti inapaswa kusambazwa, na jibu linapaswa kupata njia ya kurudi kupitia hali ya tafsiri iliyoundwa na gateway. Ruka la tatu na swali linatoka safi wakati mteja anasubiri milele.

Chukua mfano wa wateja walioidhinishwa katika 10.77.0.0/24 wanaokuja kwa wg0, wakiuuliza anwani iliyotangazwa 10.77.0.1 na kuhitaji resolver katika 203.0.113.53. Anwani ya juu ni kishika nafasi cha nyaraka, si huduma inayofanya kazi.

Kuelekeza swali upya hubadilisha lengwa lake tu

Kanuni ya NAT ya lengwa katika PREROUTING huandika upya anwani kabla ya uamuzi wa uelekezaji kufanywa, kwa hivyo pakiti huelekezwa baadaye kwenye lengwa jipya badala ya lile la zamani. Anwani ya chanzo ya mteja haigusiwi na operesheni hiyo. Ndiyo sababu kanuni inayoonekana kamili bado inaweza kutoa ukimya: ombi sasa husafiri kwa resolver ambayo haijawahi kusikia kuhusu masafa ya faragha ya mteja. Gateway ilitafsiri sehemu moja na ikarithi tatizo la pili.

Usafirishaji wote wa DNS unahitaji kanuni zinazolingana, kwa sababu mteja hurudi kwa TCP wakati jibu linakatwa.

Kanuni zilizo hapa chini huchagua kiolesura kimoja cha kuingia, masafa moja ya wateja na anwani moja ya awali ya lengwa. Hakuna kingine kwenye gateway kinachoathiriwa, na swali la gateway yenyewe halilingani kabisa.

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

Njia ya jibu ni uamuzi tofauti

Mipangilio miwili huruhusu jibu kurudi, na kuchagua moja mapema huokoa kikao cha utatuzi. Aidha resolver ya juu ina njia ya kurudi hadi 10.77.0.0/24 kupitia gateway hii, au gateway hutafsiri chanzo kwenye kitokeo ili jibu lifike kwenye anwani ambayo upande wa juu unajua tayari. Zote mbili zinafanya kazi; moja tu inalingana na udhibiti ulio nao juu ya upande wa juu.

Uelekezaji unastahili jaribio la kwanza, kwa sababu huweka anwani ya mteja ionekane kwa resolver na huepuka tabaka la pili la tafsiri. Wakati upande wa juu uko nje ya udhibiti wako, tafsiri ya chanzo kwenye kiolesura maalum cha kutoka ndiyo chaguo la vitendo.

Punguza tafsiri hiyo kwa ukali sawa na uelekezaji upya, la sivyo kanuni itakuwa NAT ya kusudi la jumla kwa kila kitu kinacholingana nayo kwa bahati:

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

Ufuatiliaji wa miunganisho huweka uchoraji pamoja kwa jozi, kwa hivyo jibu huandikwa upya kurudi kwenye tuple ya awali ya mteja wakati wa kurudi. Bila kanuni ya kutoka, resolver hutuma jibu lake kwenye anwani ya faragha ambayo haiwezi kuifikia, na mteja huona muda kupita badala ya hitilafu.

Andika kanuni nyembamba kuliko kazi inavyoonekana

Idhini ya usambazaji ni ya wigo huo huo. Ruhusu mtiririko kutoka kwa mteja hadi kwa resolver na trafiki ya kurudi ambayo conntrack inaitambua tayari, badala ya kukubali kila muunganisho wa DNAT kwenye mashine. Idhini ya jumla pia huwezesha usambazaji wa bandari ambao hauna uhusiano wowote na DNS.

Resolver ya gateway yenyewe ni njia nyingine ya msimbo. Swali linalotolewa mahali hapa hupitia OUTPUT, kwa hivyo kujaribu kutoka kwenye shell ya gateway hakuendelezi kanuni ya PREROUTING wala sera ya usambazaji. Ndiyo sababu jaribio la mahali hapa linaweza kupita wakati kila mteja anashindwa, na kinyume chake ni kawaida vile vile.

Hakuna kitu hapa kinachoshughulikia DNS juu ya HTTPS kwenye bandari 443 au DNS juu ya TLS kwenye bandari 853, na hakuna kinachoshughulikia IPv6. Mteja aliye na resolver ya IPv6 iliyowekwa atapuuza kwa furaha mpangilio wote.

Swali jipya linathibitisha nini

Ufuatiliaji wa miunganisho hukumbuka uchoraji wa awali, kwa hivyo swali lililotumwa kabla ya mabadiliko ya kanuni linaweza kujibiwa kutoka hali ya zamani na kufanya kanuni mpya ionekane imevunjika. Anza na bandari mpya ya chanzo na, pale mteja huhifadhi majibu, kwa jina jipya.

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

Amri ya kwanza inaonyesha kama njia ya mteja inatatuliwa kabisa, na ya pili inaonyesha tafsiri ambayo gateway iliweka kweli, ikiwa ni pamoja na pande zote mbili za tuple. Uchoraji unaoelekeza kwenye resolver sahihi lakini kihesabu cha majibu kimekwama kwenye sifuri ni tatizo la njia ya kurudi na si la uchujaji.

Kabla ya kuelekeza kitu chochote upya, thibitisha kwamba resolver inajua majina unayotarajia. Mbadala unaojibu majina ya umma lakini si eneo lako la faragha hubadilisha utafutaji unaofanya kazi kuwa NXDOMAIN inayoonekana kama handaki iliyovunjika. Jaribu resolver moja kwa moja, kutoka kwa gateway, kabla njia ya mteja haijashiriki. Na marejeo ya viendelezi vya iptables huandika maana ya DNAT na masquerade ambayo kanuni hizi zinategemea.