WireGuard DNS DNAT: udržte zpáteční cestu funkční

DNAT přepisuje cíl, ne zdroj. Rozhodněte, jak může upstream resolver odpovědět, ještě před přidáním pravidla, a každou shodu držte úzce vymezenou.

Nasměrovat DNS dotaz klienta WireGuard na jiný resolver vypadá jako jedno pravidlo a chová se jako tři rozhodnutí. Cíl je třeba přepsat, paket je třeba předat dál a odpověď si musí najít cestu zpět přes stav překladu, který brána vytvořila. Vynechejte třetí a dotaz čistě odejde, zatímco klient čeká navěky.

Vezměte příklad autorizovaných klientů v 10.77.0.0/24, kteří přicházejí přes wg0, dotazují se na inzerovanou adresu 10.77.0.1 a potřebují resolver na 203.0.113.53. Upstream adresa je dokumentační zástupný údaj, nikoli fungující služba.

Přesměrování dotazu mění jen jeho cíl

Pravidlo cílového NAT v PREROUTING přepíše adresu dříve, než se rozhodne o směrování, takže paket je pak směrován k novému cíli místo k původnímu. Zdrojová adresa klienta touto operací zůstává nedotčena. Proto pravidlo, které vypadá úplně, může stále produkovat ticho: požadavek nyní putuje k resolveru, který o privátním rozsahu klienta nikdy neslyšel. Brána přeložila jedno pole a zdědila druhý problém.

Oba DNS transporty potřebují odpovídající pravidla, protože klient přechází na TCP, když je odpověď zkrácena.

Pravidla níže vybírají jedno příchozí rozhraní, jeden rozsah klientů a jednu původní cílovou adresu. Nic jiného na bráně není zasaženo a dotaz samotné brány vůbec neodpovídá.

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

Zpáteční cesta je samostatné rozhodnutí

Dvě uspořádání umožňují návrat odpovědi a včasná volba jednoho ušetří jedno ladící sezení. Buď má upstream resolver cestu zpět do 10.77.0.0/24 přes tuto bránu, nebo brána překládá zdroj na výstupu, aby odpověď dorazila na adresu, kterou upstream už zná. Fungují obě; jen jedno odpovídá míře kontroly, kterou nad upstreamem máte.

Směrování si zaslouží první pokus, protože udržuje adresu klienta viditelnou pro resolver a vyhýbá se druhé vrstvě překladu. Když je upstream mimo vaši kontrolu, překlad zdroje na konkrétním výstupním rozhraní je praktická volba.

Vymezte ten překlad stejně těsně jako přesměrování, jinak se pravidlo stane NAT pro obecné použití pro cokoli, co mu náhodou odpovídá:

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

Sledování spojení udržuje mapování spárované, takže odpověď se při cestě dovnitř přepíše zpět na původní tuple klienta. Bez výstupního pravidla posílá resolver svou odpověď na privátní adresu, na kterou nedosáhne, a klient vidí vypršení místo chyby.

Pište pravidla úžeji, než úkol vypadá

Povolení předávání patří do stejného rozsahu. Povolte tok od klienta k resolveru a zpětný provoz, který conntrack už rozpoznává, místo abyste přijali každé DNAT spojení na stroji. Plošné přijetí také povoluje přesměrování portů, která s DNS nemají nic společného.

Vlastní resolver brány je jiná cesta kódu. Dotaz vydaný lokálně prochází přes OUTPUT, takže testování z shellu brány necvičí ani pravidlo PREROUTING, ani politiku předávání. Proto může lokální test projít, zatímco každý klient selhává, a opak je stejně častý.

Nic zde nepokrývá DNS přes HTTPS na portu 443 ani DNS přes TLS na portu 853 a nic nepokrývá IPv6. Klient s nastaveným IPv6 resolverem celé uspořádání s chutí ignoruje.

Co dokazuje čerstvý dotaz

Sledování spojení si pamatuje dřívější mapování, takže dotaz odeslaný před změnou pravidla může být zodpovězen ze starého stavu a nové pravidlo pak vypadá rozbité. Začněte novým zdrojovým portem a tam, kde klient odpovědi cachuje, novým jménem.

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

První příkaz ukazuje, zda se klientská cesta vůbec vyřeší, a druhý ukazuje překlad, který brána skutečně nainstalovala, včetně obou směrů tuple. Mapování ukazující na správný resolver s čítačem odpovědí zaseknutým na nule je problém zpáteční cesty, nikoli filtrování.

Než cokoli přesměrujete, potvrďte, že resolver zná jména, která očekáváte. Náhrada, která odpovídá na veřejná jména, ale ne na vaši privátní zónu promění fungující vyhledání v NXDOMAIN, který vypadá jako rozbitý tunel. Otestujte resolver přímo, z brány, než se zapojí klientská cesta. A reference rozšíření iptables dokumentuje sémantiku DNAT a masquerade, na níž tato pravidla závisí.

Související články