WireGuard DNS DNAT: udržte spiatočnú cestu funkčnú

DNAT prepisuje cieľ, nie zdroj. Rozhodnite, ako môže nadradený resolver odpovedať, skôr než pridáte pravidlo, a každú zhodu držte úzku.

Smerovanie DNS dotazu klienta WireGuard na iný resolver vyzerá ako jedno pravidlo a správa sa ako tri rozhodnutia. Cieľ treba prepísať, paket treba preposlať a odpoveď si musí nájsť cestu späť cez stav prekladu, ktorý vytvorila brána. Vynechajte tretie a dotaz čisto odíde, kým klient čaká naveky.

Vezmite príklad autorizovaných klientov v 10.77.0.0/24, ktorí prichádzajú cez wg0, dotazujú sa na inzerovanú adresu 10.77.0.1 a potrebujú resolver na 203.0.113.53. Nadradená adresa je dokumentačný zástupný údaj, nie fungujúca služba.

Presmerovanie dotazu mení len jeho cieľ

Pravidlo cieľového NAT v PREROUTING prepíše adresu pred prijatím rozhodnutia o smerovaní, takže paket je potom smerovaný k novému cieľu namiesto starého. Zdrojová adresa klienta zostáva touto operáciou nedotknutá. Preto pravidlo, ktoré vyzerá úplne, môže stále produkovať ticho: požiadavka teraz putuje k resolveru, ktorý o súkromnom rozsahu klienta nikdy nepočul. Brána preložila jedno pole a zdedila druhý problém.

Oba DNS transporty potrebujú zodpovedajúce pravidlá, pretože klient prechádza na TCP, keď je odpoveď skrátená.

Pravidlá nižšie vyberajú jedno prichádzajúce rozhranie, jeden rozsah klientov a jednu pôvodnú cieľovú adresu. Nič iné na bráne nie je zasiahnuté a dotaz samotnej brány vôbec nezodpovedá.

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

Spiatočná cesta je samostatné rozhodnutie

Dve usporiadania umožňujú návrat odpovede a včasná voľba jedného ušetrí jedno ladiacie sedenie. Buď má nadradený resolver cestu späť do 10.77.0.0/24 cez túto bránu, alebo brána prekladá zdroj na výstupe, aby odpoveď dorazila na adresu, ktorú nadradená strana už pozná. Fungujú obe; len jedno zodpovedá miere kontroly, ktorú máte nad nadradenou stranou.

Smerovanie si zaslúži prvý pokus, pretože udržiava adresu klienta viditeľnú pre resolver a vyhýba sa druhej vrstve prekladu. Keď je nadradená strana mimo vašej kontroly, preklad zdroja na konkrétnom výstupnom rozhraní je praktická voľba.

Vymedzte ten preklad rovnako tesne ako presmerovanie, inak sa pravidlo stane NAT na všeobecné použitie pre všetko, čo mu náhodou zodpovedá:

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

Sledovanie spojení udržiava mapovanie spárované, takže odpoveď sa pri ceste späť prepíše späť na pôvodný tuple klienta. Bez výstupného pravidla posiela resolver svoju odpoveď na súkromnú adresu, na ktorú nedosiahne, a klient vidí vypršanie namiesto chyby.

Píšte pravidlá užšie, než úloha vyzerá

Povolenie preposielania patrí do rovnakého rozsahu. Povoľte tok od klienta k resolveru a spätnú prevádzku, ktorú conntrack už rozpoznáva, namiesto toho, aby ste prijali každé DNAT spojenie na stroji. Plošné povolenie tiež autorizuje presmerovania portov, ktoré nemajú nič spoločné s DNS.

Vlastný resolver brány je iná cesta kódu. Dotaz vydaný lokálne prechádza cez OUTPUT, takže testovanie zo shellu brány necvičí ani pravidlo PREROUTING, ani politiku preposielania. Preto môže lokálny test prejsť, kým každý klient zlyhá, a opak je rovnako častý.

Nič tu nepokrýva DNS cez HTTPS na porte 443 ani DNS cez TLS na porte 853 a nič nepokrýva IPv6. Klient s nastaveným resolverom IPv6 celé usporiadanie s chuťou ignoruje.

Čo dokazuje čerstvý dotaz

Sledovanie spojení si pamätá skoršie mapovania, takže dotaz odoslaný pred zmenou pravidla môže byť zodpovedaný zo starého stavu a nové pravidlo potom vyzerá pokazené. Začnite novým zdrojovým portom a tam, kde klient cachuje odpovede, novým názvom.

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

Prvý príkaz ukazuje, či sa klientska cesta vôbec vyrieši, a druhý ukazuje preklad, ktorý brána skutočne nainštalovala, vrátane oboch smerov tuple. Mapovanie ukazujúce na správny resolver s počítadlom odpovedí zaseknutým na nule je problém spiatočnej cesty, nie filtrovania.

Skôr než čokoľvek presmerujete, potvrďte, že resolver pozná názvy, ktoré očakávate. Náhrada, ktorá odpovedá na verejné názvy, ale nie na vašu súkromnú zónu premení fungujúce hľadanie na NXDOMAIN, ktorý vyzerá ako pokazený tunel. Otestujte resolver priamo, z brány, skôr než sa zapojí klientska cesta. A referencia rozšírení iptables dokumentuje sémantiku DNAT a masquerade, na ktorej tieto pravidlá závisia.

Súvisiace články