WireGuard DNS DNAT: hald svarvegen i gang

DNAT skriv om destinasjonen, ikkje kjelda. Avgjer korleis oppstraumsresolveren kan svare før du legg til regelen, og hald kvar treff avgrensa.

Å peike DNS-spørjinga frå ein WireGuard-klient mot ein annan resolver ser ut som éin regel og oppfører seg som tre avgjerder. Destinasjonen må skrivast om, pakken må videresendast, og svaret må finne vegen tilbake gjennom omsetjingstilstanden gatewayen oppretta. Hopp over den tredje, og spørjinga går pent ut medan klienten ventar i evighet.

Ta dømet med autoriserte klientar i 10.77.0.0/24 som kjem inn via wg0, spør på den annonserte adressa 10.77.0.1 og treng ein resolver på 203.0.113.53. Oppstraumsadressa er ein plasshaldar for dokumentasjon, ikkje ei teneste som verkar.

Omleiding av ei spørjing endrar berre destinasjonen

Ein destinasjons-NAT-regel i PREROUTING skriv om adressa før rutingsavgjerda blir teken, slik at pakken deretter blir ruta mot den nye destinasjonen i staden for den gamle. Kjeldeadressa til klienten blir ikkje rørd av den operasjonen. Derfor kan ein regel som ser fullstendig ut likevel gje stillheit: førespurnaden reiser no til ein resolver som aldri har høyrt om det private området til klienten. Gatewayen omsette eitt felt og arva eit andre problem.

Begge DNS-transportane treng samsvarande reglar, fordi ein klient fell tilbake til TCP når eit svar blir avkorta.

Reglane nedanfor vel eitt innkomande grensesnitt, eitt klientområde og éi opphavleg destinasjonsadresse. Ingenting anna på gatewayen blir påverka, og ei spørjing frå gatewayen sjølv passar slett ikkje.

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

Svarvegen er ei eiga avgjerd

To ordningar lèt svaret kome tilbake, og å velje éi tidleg sparer ein feilsøkingsøkt. Anten har oppstraumsresolveren ei rute tilbake til 10.77.0.0/24 gjennom denne gatewayen, eller så omset gatewayen kjelda på egress slik at svaret kjem fram til ei adresse oppstraums alt kjenner. Begge verkar; berre éi passar med kontrollen du har over oppstraums.

Ruting fortener det første forsøket, fordi det held adressa til klienten synleg for resolveren og unngår eit andre omsetjingslag. Når oppstraums ligg utanfor din kontroll, er kjeldeomsetjing på det aktuelle egress-grensesnittet det praktiske valet.

Avgrens den omsetjinga like stramt som omleidinga, elles blir regelen ein NAT for generelle føremål for alt som tilfeldigvis passar:

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

Tilkoplingssporing held mappinga paret, slik at svaret blir skrive tilbake til den opphavlege tuple til klienten på vegen inn. Utan egress-regelen sender resolveren svaret sitt mot ei privat adresse han ikkje kan nå, og klienten ser ein tidsavbrot i staden for ein feil.

Skriv reglane strammare enn oppgåva ser ut

Videresendingstilgang høyrer til same omfang. Tillat straumen frå klient til resolver og returtrafikken som conntrack alt kjenner att, i staden for å godta kvar DNAT-tilkopling på maskina. Ei blank godkjenning autoriserer også portvideresendingar som ikkje har noko med DNS å gjere.

Den eigen resolveren til gatewayen er ein annan kodeveg. Ei spørjing utferda lokalt går gjennom OUTPUT, så testing frå gateway-skalet øver korkje PREROUTING-regelen eller videresendingspolitikken. Derfor kan ein lokal test bestå medan kvar klient feilar, og det motsette er like vanleg.

Ingenting her dekkjer DNS over HTTPS på port 443 eller DNS over TLS på port 853, og ingenting dekkjer IPv6. Ein klient med konfigurert IPv6-resolver vil gladeleg ignorere heile ordninga.

Kva ei fersk spørjing provar

Tilkoplingssporing hugsar tidlegare mappingar, så ei spørjing send før ei regelendring kan bli svara frå den gamle tilstanden og få den nye regelen til å sjå øydelagd ut. Start med ein ny kjeldeport og, der klienten cachar svar, eit nytt namn.

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

Den første kommandoen viser om klientvegen i det heile blir løyst, og den andre viser omsetjinga gatewayen faktisk installerte, inkludert begge retningane av tuple. Ei mapping som peikar på rett resolver med ein svarteljar fastlåst på null er eit problem med returvegen og ikkje med filtreringa.

Stadfest at resolveren kjenner namna du forventar før du omdirigerer noko. Ein erstattar som svarar på offentlege namn, men ikkje på den private sona di gjer eit fungerande oppslag om til eit NXDOMAIN som ser ut som ein øydelagd tunnel. Test resolveren direkte, frå gatewayen, før klientvegen er involvert. Og referansen for iptables-utvidingar dokumenterer DNAT- og masquerade-semantikken som desse reglane er avhengige av.

Relaterte artiklar