WireGuard DNS DNAT: de Wee vun der Äntwert funktiounsfäeg halen

D'DNS-Ufro vun engem WireGuard-Client op en aneren Resolver ze riichten, gesäit aus wéi eng Reegel a verhält sech wéi dräi Entscheedungen. D'Zil muss ëmgeschriwwe ginn, de Pak muss weidergeleet ginn, an d'Äntwert muss hire Wee zréck duerch den Iwwersetzungszoustand fannen, deen d'Gateway ugeluecht huet. Loosst den Drëtten aus, an d'Ufro geet propper fort, wärend de Client fir ëmmer waart.

Hëlt d'Beispill vun autoriséierte Clienten an 10.77.0.0/24, déi iwwer wg0 kommen, d'annoncéiert Adress 10.77.0.1 froen an e Resolver op 203.0.113.53 brauchen. D'Upstream-Adress ass en Dokumentatiouns-Platzhalter an keen funktionéierende Service.

Eng Ufro ëmleeden ännert just hiert Zil

Eng Zil-NAT-Reegel am PREROUTING schreift d'Adress ëm, ier d'Routing-Entscheedung gefall gëtt, sou datt de Pak duerno op dat neit Zil amplaz vum ale gerout gëtt. D'Quelladress vum Client gëtt duerch déi Operatioun net beréiert. Dofir kann eng Reegel, déi komplett ausgesäit, nach ëmmer Stille produzéieren: d'Ufro reest elo zu engem Resolver, dee nach ni vum private Beräich vum Client héieren huet. D'Gateway huet ee Feld iwwersat an en zweet Problem geierft.

Béid DNS-Transporten brauchen passend Reegelen, well e Client op TCP zréckfält, wann eng Äntwert ofgeschnidden gëtt.

D'Reegele hei drënner wielen een agaange Schnittstelle, ee Clientberäich an eng ursprénglech Ziladress. Nichts anescht op der Gateway gëtt beaflosst, an eng Ufro vun der Gateway selwer passt guer net.

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

De Wee vun der Äntwert ass eng eegen Entscheedung

Zwee Arrangementer loossen d'Äntwert zréckkommen, an ee fréi ze wielen spuert eng Debugging-Sessioun. Entweder huet den Upstream-Resolver eng Route zréck op 10.77.0.0/24 iwwer dës Gateway, oder d'Gateway iwwersetzt d'Quell um Ausgang sou datt d'Äntwert op enger Adress ukommt, déi den Upstream schonn kennt. Béides funktionéiert; just eng passt zu der Kontroll, déi Dir iwwer den Upstream hutt.

Routing verdéngt den éischten Versuch, well et d'Adress vum Client fir de Resolver siichtbar hält an eng zweet Iwwersetzungsschicht vermeit. Wann den Upstream baussent Ärer Kontroll läit, ass d'Quelliwwersetzung op der spezifescher Ausgangsschnittstelle déi praktesch Wiel.

Begrenzt déi Iwwersetzung esou enk wéi d'Ëmleedung, soss gëtt d'Reegel en Allzweck-NAT fir alles, wat zufälleg dozou passt:

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

D'Verbindungsverfolgung hält d'Mapping gepaart, sou datt d'Äntwert um Zréckwee erëm op den ursprénglechen Tuple vum Client ëmgeschriwwe gëtt. Ouni d'Ausgangsreegel schéckt de Resolver seng Äntwert op eng privat Adress, déi hien net erreeche kann, an de Client gesäit en Timeout amplaz vun engem Feeler.

Schreift d'Reegele méi enk wéi d'Aufgab ausgesäit

D'Weiderleeungsberechtegung gehéiert zum selwechte Beräich. Erlaabt de Flux vum Client zum Resolver an de Réckverkéier, deen conntrack schonn erkennt, amplaz all DNAT-Verbindung op der Maschinn ze akzeptéieren. Eng allgemeng Akzeptanz autoriséiert och Portweiderleeungen, déi näischt mat DNS ze dinn hunn.

Den eegene Resolver vun der Gateway ass en anere Codewee. Eng Ufro, déi lokal erausgëtt, geet duerch OUTPUT, sou datt Testen aus der Gateway-Shell weder d'PREROUTING-Reegel nach d'Weiderleeungspolitik übt. Dofir kann en lokalen Test duerchgoen, wärend all Client feelt, an de Géigendeel ass genee esou heefeg.

Näischt hei deckt DNS iwwer HTTPS op Port 443 oder DNS iwwer TLS op Port 853 of, an näischt deckt IPv6 of. E Client mat engem konfiguréierten IPv6-Resolver ignoréiert gär dat ganzt Arrangement.

Wat eng frësch Ufro beweist

D'Verbindungsverfolgung erënnert sech un fréier Mappings, dofir kann eng Ufro, déi virun enger Reegelännerung geschéckt gouf, aus dem ale Zoustand beäntwert ginn an déi nei Reegel als futti ausgesinn. Fänkt mat engem neie Quellport un a, wou de Client Äntwerten cachet, mat engem neien Numm.

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

Den éischte Kommando weist, ob de Clientwee iwwerhaapt opgeléist gëtt, an den zweeten weist d'Iwwersetzung, déi d'Gateway tatsächlech installéiert huet, inklusiv béide Richtunge vum Tuple. Eng Mapping, déi op de richtege Resolver weist an där hire Äntwertzähler op Null hänke bliwwen ass, ass e Problem vum Zréckwee an net vun der Filterung.

Bestätegt, datt de Resolver d'Nimm kennt, déi Dir erwaart, ier Dir eppes ëmleedt. En Ersatz, deen op ëffentlech Nimm äntwert, awer net op Är privat Zon verwandelt eng funktionéierend Sich an en NXDOMAIN, deen ausgesäit wéi en futti Tunnel. Testt de Resolver direkt, vun der Gateway aus, ier de Clientwee dobäi ass. An Referenz zu den iptables-Erweiderungen dokumentéiert d'DNAT- an d'Masquerade-Semantik, op déi dës Reegelen sech stäipen.