WireGuard DNS DNAT: zadržite povratni put u radu

DNAT prepisuje odredište, ne izvor. Odlučite kako upstream resolver može odgovoriti prije nego dodate pravilo i držite svako podudaranje usko.

Usmjeravanje DNS upita WireGuard klijenta na drugi resolver izgleda kao jedno pravilo, a ponaša se kao tri odluke. Odredište se mora prepisati, paket se mora proslijediti, a odgovor mora pronaći put natrag kroz stanje prevođenja koje je gateway stvorio. Preskočite treće i upit mirno odlazi dok klijent čeka zauvijek.

Uzmite primjer autorizovanih klijenata u 10.77.0.0/24 koji dolaze preko wg0, upućuju upit na oglašenu adresu 10.77.0.1 i trebaju resolver na 203.0.113.53. Upstream adresa je dokumentacijski rezervisano mjesto, a ne usluga koja radi.

Preusmjeravanje upita mijenja samo njegovo odredište

Pravilo odredišnog NAT-a u PREROUTING-u prepisuje adresu prije nego što se donese odluka o rutiranju, pa se paket zatim rutira prema novom odredištu umjesto starom. Izvorna adresa klijenta tom operacijom nije dotaknuta. Zato pravilo koje izgleda potpuno ipak može proizvesti tišinu: zahtjev sada putuje do resolvera koji nikada nije čuo za privatni raspon klijenta. Gateway je preveo jedno polje i naslijedio drugi problem.

Oba DNS transporta trebaju odgovarajuća pravila, jer klijent prelazi na TCP kada je odgovor skraćen.

Pravila ispod biraju jedno dolazno sučelje, jedan raspon klijenata i jednu originalnu odredišnu adresu. Ništa drugo na gatewayu nije pogođeno, a upit samog gatewaya ne podudara se uopće.

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

Povratni put je zasebna odluka

Dva rasporeda omogućavaju da se odgovor vrati, a rani odabir jednog štedi sesiju za otklanjanje grešaka. Ili upstream resolver ima rutu natrag do 10.77.0.0/24 kroz ovaj gateway, ili gateway prevodi izvor na izlazu pa odgovor stiže na adresu koju upstream već poznaje. Oba rade; samo jedan odgovara kontroli koju imate nad upstreamom.

Rutiranje zaslužuje prvi pokušaj, jer čuva adresu klijenta vidljivom resolveru i izbjegava drugi sloj prevođenja. Kada je upstream izvan vaše kontrole, prevođenje izvora na konkretnom izlaznom sučelju je praktičan izbor.

Ograničite to prevođenje jednako usko kao preusmjeravanje, inače pravilo postaje NAT opšte namjene za sve što se slučajno podudari:

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

Praćenje konekcija drži mapiranje uparenim, pa se odgovor na povratku prepisuje natrag u originalni torku klijenta. Bez izlaznog pravila resolver šalje svoj odgovor na privatnu adresu do koje ne može doći, a klijent vidi istek umjesto greške.

Pišite pravila uža nego što zadatak izgleda

Dozvola za prosljeđivanje pripada istom obimu. Dozvolite tok od klijenta do resolvera i povratni saobraćaj koji conntrack već prepoznaje, umjesto da prihvatite svaku DNAT konekciju na mašini. Opšte prihvatanje također odobrava prosljeđivanja portova koja nemaju veze s DNS-om.

Vlastiti resolver gatewaya je drugačija putanja koda. Upit izdan lokalno prolazi kroz OUTPUT, pa testiranje iz gateway shell-a ne vježba ni PREROUTING pravilo ni politiku prosljeđivanja. Zato lokalni test može proći dok svaki klijent pada, a obrnuto je jednako često.

Ovdje ništa ne pokriva DNS preko HTTPS-a na portu 443 ni DNS preko TLS-a na portu 853, i ništa ne pokriva IPv6. Klijent s konfigurisanim IPv6 resolverom rado će ignorisati cijeli raspored.

Šta dokazuje svjež upit

Praćenje konekcija pamti ranija mapiranja, pa upit poslan prije promjene pravila može biti odgovoren iz starog stanja i učiniti novo pravilo pokvarenim. Počnite s novim izvornim portom i, gdje klijent kešira odgovore, s novim imenom.

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

Prva komanda pokazuje da li se klijentska putanja uopće razrješava, a druga prikazuje prevođenje koje je gateway zaista instalirao, uključujući oba smjera torke. Mapiranje koje pokazuje na ispravan resolver s brojačem odgovora zaglavljenim na nuli problem je povratnog puta, a ne filtriranja.

Potvrdite da resolver zna imena koja očekujete prije nego bilo šta preusmjerite. Zamjena koja odgovara na javna imena ali ne na vašu privatnu zonu pretvara radnu pretragu u NXDOMAIN koji izgleda kao pokvaren tunel. Testirajte resolver direktno, s gatewaya, prije nego se klijentska putanja umiješa. A referenca za iptables ekstenzije dokumentuje DNAT i masquerade semantiku na kojoj ova pravila zavise.

Povezani članci