WireGuard DNS DNAT: hold svarvejen kørende

DNAT omskriver destinationen, ikke kilden. Beslut, hvordan den opstrøms resolver kan svare, før du tilføjer reglen, og hold hver match snæver.

At pege en WireGuard-klients DNS-forespørgsel mod en anden resolver ligner én regel og opfører sig som tre beslutninger. Destinationen skal omskrives, pakken skal videresendes, og svaret skal finde vej tilbage gennem den oversættelsestilstand, gatewayen har oprettet. Spring det tredje over, og forespørgslen forlader stedet pænt, mens klienten venter for evigt.

Tag eksemplet med autoriserede klienter i 10.77.0.0/24, der ankommer via wg0, forespørger på den annoncerede adresse 10.77.0.1 og har brug for en resolver på 203.0.113.53. Opstrømsadressen er en pladsholder til dokumentation og ikke en fungerende tjeneste.

Omdirigering af en forespørgsel ændrer kun dens destination

En destination-NAT-regel i PREROUTING omskriver adressen, før routingbeslutningen træffes, så pakken derefter routes mod den nye destination i stedet for den gamle. Klientens kildeadresse er urørt af den handling. Derfor kan en regel, der ser komplet ud, stadig give tavshed: anmodningen rejser nu til en resolver, der aldrig har hørt om klientens private område. Gatewayen oversatte ét felt og arvede et andet problem.

Begge DNS-transporter har brug for matchende regler, fordi en klient falder tilbage til TCP, når et svar afkortes.

Reglerne nedenfor vælger én indgående grænseflade, ét klientområde og én oprindelig destinationsadresse. Intet andet på gatewayen påvirkes, og en forespørgsel fra gatewayen selv matcher slet ikke.

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

Svarvejen er en selvstændig beslutning

To arrangementer lader svaret vende tilbage, og et tidligt valg sparer en fejlretningssession. Enten har den opstrøms resolver en rute tilbage til 10.77.0.0/24 gennem denne gateway, eller også oversætter gatewayen kilden på egress, så svaret ankommer til en adresse, som opstrøms allerede kender. Begge virker; kun én svarer til den kontrol, du har over opstrøms.

Routing fortjener det første forsøg, fordi det holder klientens adresse synlig for resolveren og undgår et andet oversættelseslag. Når opstrøms ligger uden for din kontrol, er kildeoversættelse på den specifikke egress-grænseflade det praktiske valg.

Afgræns den oversættelse lige så snævert som omdirigeringen, ellers bliver reglen en NAT til generelle formål for alt, hvad der tilfældigvis matcher den:

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

Forbindelsessporing holder koblingen parret, så svaret omskrives tilbage til klientens oprindelige tuple på vej ind. Uden egress-reglen sender resolveren sit svar mod en privat adresse, den ikke kan nå, og klienten ser en timeout i stedet for en fejl.

Skriv reglerne strammere, end opgaven ser ud

Videresendelsestilladelse hører til samme omfang. Tillad strømmen fra klient til resolver og den returtrafik, conntrack allerede genkender, i stedet for at acceptere hver DNAT-forbindelse på maskinen. En blanket accept autoriserer også portvideresendelser, der intet har med DNS at gøre.

Gatewayens egen resolver er en anden kodesti. En forespørgsel udstedt lokalt går gennem OUTPUT, så test fra gatewayens shell hverken øver PREROUTING-reglen eller videresendelsespolitikken. Derfor kan en lokal test bestå, mens hver klient fejler, og det modsatte er lige så almindeligt.

Intet her dækker DNS over HTTPS på port 443 eller DNS over TLS på port 853, og intet her dækker IPv6. En klient med en konfigureret IPv6-resolver ignorerer gerne hele arrangementet.

Hvad en frisk forespørgsel beviser

Forbindelsessporing husker tidligere koblinger, så en forespørgsel sendt før en regelændring kan blive besvaret fra den gamle tilstand og få den nye regel til at se brudt ud. Start med en ny kildeport og, hvor klienten cacher svar, et nyt navn.

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

Den første kommando viser, om klientstien overhovedet opløses, og den anden viser den oversættelse, gatewayen faktisk installerede, inklusive begge retninger af tuplen. En kobling, der peger på den rigtige resolver med en svar-tæller fastlåst på nul, er et problem med returvejen og ikke med filtreringen.

Bekræft, at resolveren kender de navne, du forventer, før du omdirigerer noget. En erstatning, der svarer på offentlige navne, men ikke på din private zone forvandler et fungerende opslag til et NXDOMAIN, der ligner en brudt tunnel. Test resolveren direkte fra gatewayen, før klientstien er involveret. Og referencen for iptables-udvidelser dokumenterer den DNAT- og masquerade-semantik, som disse regler afhænger af.

Relaterede artikler