WireGuard DNS DNAT: hold svarveien i gang

DNAT skriver om destinasjonen, ikke kilden. Bestem hvordan oppstrøms resolver kan svare før du legger til regelen, og hold hvert treff begrenset.

Å peke DNS-spørringen fra en WireGuard-klient mot en annen resolver ser ut som én regel og oppfører seg som tre beslutninger. Destinasjonen må skrives om, pakken må videresendes, og svaret må finne veien tilbake gjennom oversettelsestilstanden gatewayen opprettet. Hopp over den tredje, og spørringen går pent ut mens klienten venter i evighet.

Ta eksempelet med autoriserte klienter i 10.77.0.0/24 som kommer inn via wg0, spør på den annonserte adressen 10.77.0.1 og trenger en resolver på 203.0.113.53. Oppstrømsadressen er en plassholder for dokumentasjon, ikke en tjeneste som virker.

Omdirigering av en spørring endrer bare destinasjonen

En destinasjons-NAT-regel i PREROUTING skriver om adressen før rutingsbeslutningen tas, slik at pakken deretter rutes mot den nye destinasjonen i stedet for den gamle. Kildeadressen til klienten blir ikke berørt av den operasjonen. Derfor kan en regel som ser komplett ut likevel gi stillhet: forespørselen reiser nå til en resolver som aldri har hørt om klientens private område. Gatewayen oversatte ett felt og arvet et andre problem.

Begge DNS-transportene trenger samsvarende regler, fordi en klient faller tilbake til TCP når et svar blir avkortet.

Reglene nedenfor velger ett innkommende grensesnitt, ett klientområde og én opprinnelig destinasjonsadresse. Ingenting annet på gatewayen påvirkes, og en spørring fra gatewayen selv passer ikke i det hele tatt.

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

Svarveien er en egen beslutning

To ordninger lar svaret komme tilbake, og å velge en tidlig sparer en feilsøkingsøkt. Enten har oppstrøms resolveren en rute tilbake til 10.77.0.0/24 gjennom denne gatewayen, eller så oversetter gatewayen kilden på egress slik at svaret ankommer en adresse oppstrøms allerede kjenner. Begge virker; bare én passer med kontrollen du har over oppstrøms.

Ruting fortjener det første forsøket, fordi det holder klientens adresse synlig for resolveren og unngår et andre oversettelseslag. Når oppstrøms ligger utenfor din kontroll, er kildeoversettelse på det aktuelle egress-grensesnittet det praktiske valget.

Begrens den oversettelsen like stramt som omdirigeringen, ellers blir regelen en NAT for generelle formål for alt som tilfeldigvis passer:

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

Tilkoblingssporing holder mappingen paret, slik at svaret skrives tilbake til klientens opprinnelige tuple på vei inn. Uten egress-regelen sender resolveren svaret sitt mot en privat adresse den ikke kan nå, og klienten ser en tidsavbrudd i stedet for en feil.

Skriv reglene strammere enn oppgaven ser ut

Videresendingstillatelse hører til samme omfang. Tillat strømmen fra klient til resolver og returtrafikken som conntrack allerede gjenkjenner, i stedet for å godta hver DNAT-tilkobling på maskinen. En blanket godkjenning autoriserer også portvideresendinger som ikke har noe med DNS å gjøre.

Gatewayens egen resolver er en annen kodesti. En spørring utstedt lokalt går gjennom OUTPUT, så testing fra gatewayens shell øver verken PREROUTING-regelen eller videresendingspolicyen. Derfor kan en lokal test bestå mens hver klient feiler, og det motsatte er like vanlig.

Ingenting her dekker DNS over HTTPS på port 443 eller DNS over TLS på port 853, og ingenting dekker IPv6. En klient med konfigurert IPv6-resolver vil gladelig ignorere hele ordningen.

Hva en fersk spørring beviser

Tilkoblingssporing husker tidligere mappinger, så en spørring sendt før en regelendring kan besvares fra den gamle tilstanden og få den nye regelen til å se ødelagt ut. Start med en ny kildeport og, der klienten cacher svar, et nytt navn.

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

Den første kommandoen viser om klientstien i det hele tatt løses, og den andre viser oversettelsen gatewayen faktisk installerte, inkludert begge retningene av tuple. En mapping som peker på riktig resolver med en svarteller fastlåst på null er et problem med returveien og ikke med filtreringen.

Bekreft at resolveren kjenner navnene du forventer før du omdirigerer noe. En erstatning som svarer på offentlige navn, men ikke på den private sonen din gjør et fungerende oppslag om til et NXDOMAIN som ser ut som en ødelagt tunnel. Test resolveren direkte, fra gatewayen, før klientstien er involvert. Og referansen for iptables-utvidelser dokumenterer DNAT- og masquerade-semantikken som disse reglene er avhengige av.

Relaterte artikler