WireGuard DNS DNAT: saglabāt atbildes ceļu darboties spējīgu

DNAT pārraksta galamērķi, nevis avotu. Izlemiet, kā augšupējais resolveris var atbildēt, pirms pievienojat noteikumu, un turiet katru atbilstību šauru.

WireGuard klienta DNS vaicājuma novirzīšana uz citu resolveri izskatās kā viens noteikums, bet uzvedas kā trīs lēmumi. Galamērķis ir jāpārraksta, pakete ir jāpārsūta, un atbildei jāatrod ceļš atpakaļ caur tulkošanas stāvokli, ko izveidojusi gateway. Izlaidiet trešo un vaicājums aiziet tīri, kamēr klients gaida mūžīgi.

Ņemiet piemēru ar autorizētiem klientiem 10.77.0.0/24 tīklā, kas ierodas pa wg0, vaicā izziņoto adresi 10.77.0.1 un viņiem vajag resolveri 203.0.113.53 adresē. Augšupējā adrese ir dokumentācijas vietturis, nevis strādājošs pakalpojums.

Vaicājuma novirzīšana maina tikai tā galamērķi

Galamērķa NAT noteikums PREROUTING pārraksta adresi pirms maršrutēšanas lēmuma pieņemšanas, tāpēc pakete pēc tam tiek maršrutēta uz jauno galamērķi, nevis veco. Klienta avota adrese šīs darbības laikā netiek aizskarta. Tāpēc noteikums, kas izskatās pabeigts, joprojām var radīt klusumu: pieprasījums tagad dodas pie resolvera, kas nekad nav dzirdējis par klienta privāto diapazonu. Gateway iztulkoja vienu lauku un mantoja otru problēmu.

Abiem DNS transportiem vajag atbilstošus noteikumus, jo klients atgriežas pie TCP, kad atbilde tiek saīsināta.

Tālāk minētie noteikumi izvēlas vienu ienākošo saskarni, vienu klientu diapazonu un vienu sākotnējo galamērķa adresi. Nekas cits uz gateway netiek ietekmēts, un pašas gateway vaicājums nemaz neatbilst.

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

Atbildes ceļš ir atsevišķs lēmums

Divi izkārtojumi ļauj atbildei atgriezties, un viena agrīna izvēle ietaupa atkļūdošanas sesiju. Vai nu augšupējam resolverim ir atgriešanās maršruts uz 10.77.0.0/24 caur šo gateway, vai arī gateway iztulko avotu izejā, lai atbilde nonāktu adresē, ko augšupējais jau zina. Darbojas abi; tikai viens atbilst jūsu kontrolei pār augšupējo.

Maršrutēšana ir pelnījusi pirmo mēģinājumu, jo tā saglabā klienta adresi redzamu resolverim un izvairās no otrā tulkošanas slāņa. Kad augšupējais ir ārpus jūsu kontroles, avota tulkošana konkrētajā izejas saskarnē ir praktiskā izvēle.

Ierobežojiet šo tulkošanu tikpat stingri kā novirzīšanu, citādi noteikums kļūst par vispārējas nozīmes NAT visam, kas tam nejauši atbilst:

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

Savienojumu izsekošana uztur kartējumu pāros, tāpēc atbilde atpakaļceļā tiek pārrakstīta atpakaļ klienta sākotnējā kortežā. Bez izejas noteikuma resolveris sūta savu atbildi uz privātu adresi, kuru nevar sasniegt, un klients redz noildzi, nevis kļūdu.

Rakstiet noteikumus šaurāk, nekā izskatās uzdevums

Pārsūtīšanas atļauja pieder tai pašai jomai. Atļaujiet plūsmu no klienta uz resolveri un atgriezenisko trafiku, ko conntrack jau atpazīst, nevis pieņemiet katru DNAT savienojumu mašīnā. Vispārēja atļauja arī atļauj portu pārsūtīšanu, kam nav nekāda sakara ar DNS.

Pašas gateway resolveris ir cits koda ceļš. Lokāli izsniegts vaicājums iet caur OUTPUT, tāpēc testēšana no gateway čaulas neizpilda ne PREROUTING noteikumu, ne pārsūtīšanas politiku. Tāpēc lokāls tests var izturēt, kamēr katrs klients cieš neveiksmi, un pretējais ir tikpat bieži.

Nekas šeit neaptver DNS pār HTTPS 443 portā vai DNS pār TLS 853 portā, un nekas neaptver IPv6. Klients ar konfigurētu IPv6 resolveri labprāt ignorēs visu izkārtojumu.

Ko pierāda svaigs vaicājums

Savienojumu izsekošana atceras iepriekšējos kartējumus, tāpēc vaicājums, kas nosūtīts pirms noteikuma maiņas, var tikt atbildēts no vecā stāvokļa un likt jaunajam noteikumam izskatīties salauztam. Sāciet ar jaunu avota portu un, kur klients kešo atbildes, ar jaunu nosaukumu.

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

Pirmā komanda parāda, vai klienta ceļš vispār tiek atrisināts, un otrā parāda tulkojumu, ko gateway faktiski instalēja, ieskaitot abus korteža virzienus. Kartējums, kas norāda uz pareizo resolveri ar atbilžu skaitītāju, kas iestrēdzis uz nulles, ir atgriešanās ceļa problēma, nevis filtrēšanas.

Pirms kaut ko novirzīt pārliecinieties, ka resolveris zina nosaukumus, kurus gaidāt. Aizstājējs, kas atbild uz publiskiem nosaukumiem, bet ne uz jūsu privāto zonu pārvērš strādājošu meklēšanu par NXDOMAIN, kas izskatās kā salauzts tunelis. Pārbaudiet resolveri tieši, no gateway, pirms iesaistās klienta ceļš. Un iptables paplašinājumu uzziņa dokumentē DNAT un masquerade semantiku, uz kuras šie noteikumi balstās.

Saistītie raksti