WireGuard DNS DNAT: išlaikyti atsakymo kelią veikiantį

DNAT perrašo paskirties adresą, o ne šaltinį. Nuspręskite, kaip aukštesnio lygio resolveris gali atsakyti, prieš pridėdami taisyklę, ir kiekvieną atitikimą laikykite siaurą.

WireGuard kliento DNS užklausos nukreipimas į kitą resolverį atrodo kaip viena taisyklė, o elgiasi kaip trys sprendimai. Paskirties adresą reikia perrašyti, paketą persiųsti, o atsakymas turi rasti kelią atgal per vertimo būseną, kurią sukūrė gateway. Praleiskite trečiąjį ir užklausa tyliai išvyks, o klientas lauks amžinai.

Paimkime pavyzdį: leidžiami klientai 10.77.0.0/24 tinkle atvyksta per wg0, užklausia skelbiamo adreso 10.77.0.1 ir jiems reikia resolverio adresu 203.0.113.53. Aukštesnio lygio adresas yra dokumentacijos pakaitinis žymuo, o ne veikianti paslauga.

Užklausos peradresavimas keičia tik jos paskirtį

Paskirties NAT taisyklė PREROUTING grandinėje perrašo adresą prieš priimant maršruto sprendimą, todėl paketas vėliau nukreipiamas į naują paskirtį, o ne į senąją. Kliento šaltinio adresas šios operacijos neliečiamas. Štai kodėl taisyklė, kuri atrodo baigta, vis tiek gali sukelti tylą: užklausa dabar keliauja pas resolverį, kuris niekada negirdėjo apie kliento privatų diapazoną. Gateway išvertė vieną lauką ir paveldėjo antrą problemą.

Abiems DNS transportams reikia atitinkančių taisyklių, nes klientas grįžta prie TCP, kai atsakymas apkerpamas.

Toliau pateiktos taisyklės pasirenka vieną įeinantį sąsają, vieną klientų diapazoną ir vieną pradinį paskirties adresą. Niekas kitas gateway nepaveiktas, o paties gateway užklausa visiškai neatitinka.

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

Atsakymo kelias yra atskiras sprendimas

Dvi schemos leidžia atsakymui grįžti, o vienos pasirinkimas anksti sutaupo derinimo sesiją. Arba aukštesnio lygio resolveris turi grįžimo maršrutą į 10.77.0.0/24 per šį gateway, arba gateway išversdamas šaltinį ties išėjimu, kad atsakymas atkeliautų į adresą, kurį aukštesnysis jau žino. Veikia abi; tik viena atitinka jūsų turimą aukštesniojo lygio kontrolę.

Maršrutizavimas vertas pirmo bandymo, nes jis išlaiko kliento adresą matomą resolveriui ir išvengia antrojo vertimo sluoksnio. Kai aukštesnysis yra už jūsų kontrolės ribų, šaltinio vertimas konkrečioje išėjimo sąsajoje yra praktiškas pasirinkimas.

Apribokite tą vertimą taip pat griežtai kaip peradresavimą, kitaip taisyklė taps bendros paskirties NAT viskam, kas su ja sutampa:

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

Ryšių stebėjimas palaiko susiejimą poromis, todėl atsakymas grįžtant perrašomas atgal į pradinį kliento rinkinį. Be išėjimo taisyklės resolveris siunčia atsakymą į privatų adresą, kurio negali pasiekti, o klientas mato skirtąjį laiką, o ne klaidą.

Rašykite taisykles siauriau, nei atrodo užduotis

Persiuntimo leidimas priklauso tai pačiai sričiai. Leiskite srautą nuo kliento iki resolverio ir grįžtamąjį srautą, kurį conntrack jau atpažįsta, o ne priimkite kiekvieną DNAT ryšį mašinoje. Bendrai leidžiant taip pat leidžiamas portų persiuntimas, neturintis nieko bendra su DNS.

Paties gateway resolveris yra kitas kodo kelias. Vietoje išduota užklausa eina per OUTPUT, todėl bandymas iš gateway shell netikrina nei PREROUTING taisyklės, nei persiuntimo politikos. Todėl vietinis testas gali praeiti, kai kiekvienas klientas nepavyksta, ir atvirkščiai yra taip pat dažnai.

Niekas čia neapima DNS per HTTPS 443 prievade ar DNS per TLS 853 prievade, ir niekas neapima IPv6. Klientas su sukonfigūruotu IPv6 resolveriu mielai ignoruos visą schemą.

Ką įrodo nauja užklausa

Ryšių stebėjimas prisimena ankstesnius susiejimus, todėl užklausa, išsiųsta prieš taisyklės pakeitimą, gali būti atsakyta iš senos būsenos ir priversti naują taisyklę atrodyti sugedusia. Pradėkite nuo naujo šaltinio prievado ir, kur klientas saugo atsakymus, nuo naujo vardo.

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

Pirmoji komanda parodo, ar kliento kelias apskritai sprendžiamas, o antroji – vertimą, kurį gateway iš tikrųjų įdiegė, įskaitant abi rinkinio kryptis. Susiejimas, rodantis į teisingą resolverį, bet su atsakymų skaitikliu, įstrigusiu ties nuliu, yra grįžimo kelio problema, o ne filtravimo.

Prieš ką nors peradresuodami patvirtinkite, kad resolveris žino vardus, kurių tikitės. Pakaitalas, kuris atsako į viešus vardus, bet ne į jūsų privatų zoną paverčia veikiančią paiešką NXDOMAIN, kuris atrodo kaip sugedęs tunelis. Išbandykite resolverį tiesiogiai, iš gateway, prieš įtraukiant kliento kelią. O iptables plėtinių nuoroda dokumentuoja DNAT ir masquerade semantiką, kuria šios taisyklės remiasi.

Susiję straipsniai