WireGuard DNS DNAT: tenu la respondon vojon en funkcio

Direkti la DNS-demandon de WireGuard-kliento al alia solvilo aspektas kiel unu regulo kaj kondutas kiel tri decidoj. La celo devas esti reskribita, la pako devas esti plusendita, kaj la respondo devas trovi sian vojon reen tra la traduka stato, kiun la enirejo kreis. Forlasu la trian kaj la demando foriras pure, dum la kliento atendas eterne.

Prenu la ekzemplon de rajtigitaj klientoj en 10.77.0.0/24, kiuj alvenas per wg0, demandas la anoncitan adreson 10.77.0.1 kaj bezonas solvilon ĉe 203.0.113.53. La supraflua adreso estas dokumentada anstataŭilo, ne funkcianta servo.

Plusendi demandon ŝanĝas nur ĝian celon

Cela-NAT-regulo en PREROUTING reskribas la adreson antaŭ ol la enkursiga decido estas farita, do la pako poste enkursiĝas al la nova celo anstataŭ la malnova. La fonta adreso de la kliento restas netuŝita de tiu operacio. Tial regulo, kiu aspektas kompleta, ankoraŭ povas produkti silenton: la peto nun vojaĝas al solvilo, kiu neniam aŭdis pri la privata gamo de la kliento. La enirejo tradukis unu kampon kaj heredis duan problemon.

Ambaŭ DNS-transportoj bezonas kongruajn regulojn, ĉar kliento reiras al TCP kiam respondo estas tranĉita.

La reguloj sube elektas unu envenantan interfacon, unu klientan gamon kaj unu originan celan adreson. Nenio alia en la enirejo estas tuŝita, kaj demando de la enirejo mem tute ne kongruas.

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

La responda vojo estas aparta decido

Du aranĝoj lasas la respondon reveni, kaj elekti unu frue ŝparas sencimigan seancon. Aŭ la supraflua solvilo havas itineron reen al 10.77.0.0/24 tra ĉi tiu enirejo, aŭ la enirejo tradukas la fonton ĉe eliro tiel, ke la respondo alvenas ĉe adreso, kiun la supraflua jam konas. Ambaŭ funkcias; nur unu kongruas kun la kontrolo, kiun vi havas super la supraflua.

Enkursigado meritas la unuan provon, ĉar ĝi tenas la adreson de la kliento videbla al la solvilo kaj evitas duan tradukan tavolon. Kiam la supraflua estas ekster via kontrolo, fonta tradukado ĉe la konkreta elira interfaco estas la praktika elekto.

Limigu tiun tradukon same strikte kiel la plusendon, alie la regulo fariĝas ĝenerala NAT por io ajn, kio hazarde kongruas:

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

Konekta spurado tenas la surmapigon parigita, do la respondo reskribiĝas reen al la originala opo de la kliento survoje. Sen la elira regulo, la solvilo sendas sian respondon al privata adreso, kiun ĝi ne povas atingi, kaj la kliento vidas tempolimon anstataŭ eraron.

Skribu la regulojn pli striktaj ol la tasko aspektas

Plusenda permeso apartenas al la sama amplekso. Permesu la fluon de kliento al solvilo kaj la revenan trafikon, kiun conntrack jam rekonas, anstataŭ akcepti ĉiun DNAT-konekton sur la maŝino. Ĝenerala akcepto ankaŭ rajtigas pordajn plusendojn, kiuj havas nenion komunan kun DNS.

La propra solvilo de la enirejo estas alia koda vojo. Demando eldonita loke pasas tra OUTPUT, do testado el la ŝelo de la enirejo ekzercas nek la regulon PREROUTING nek la plusendan politikon. Tial loka testo povas sukcesi dum ĉiu kliento malsukcesas, kaj la malo estas same ofta.

Nenio ĉi tie kovras DNS super HTTPS sur pordo 443 aŭ DNS super TLS sur pordo 853, kaj nenio kovras IPv6. Kliento kun agordita IPv6-solvilo ĝoje ignoros la tutan aranĝon.

Kion pruvas freŝa demando

Konekta spurado memoras pli fruajn surmapigojn, do demando sendita antaŭ regulŝanĝo povas esti respondita el la malnova stato kaj igi la novan regulon aspekti rompita. Komencu per nova fonta pordo kaj, kie la kliento kaŝmemorigas respondojn, per nova nomo.

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

La unua komando montras, ĉu la klienta vojo entute solviĝas, kaj la dua montras la tradukon, kiun la enirejo efektive instaligis, inkluzive ambaŭ direktojn de la opo. Surmapigo montranta al la ĝusta solvilo kun responda nombrilo gluita ĉe nulo estas problemo de revena vojo, ne de filtrado.

Konfirmu, ke la solvilo konas la nomojn, kiujn vi atendas, antaŭ ol plusendi ion ajn. Anstataŭaĵo, kiu respondas al publikaj nomoj sed ne al via privata zono transformas funkciantan serĉon en NXDOMAIN, kiu aspektas kiel rompita tunelo. Testu la solvilon rekte, de la enirejo, antaŭ ol la klienta vojo implikiĝas. Kaj referenco pri iptables-etendaĵoj dokumentas la semantikon de DNAT kaj masquerade, sur kiu ĉi tiuj reguloj dependas.