WireGuard DNS DNAT: hou die antwoordpad aan die gang

Om 'n WireGuard-kliënt se DNS-navraag na 'n ander resolver te rig, lyk soos een reël en gedra hom soos drie besluite. Die bestemming moet herskryf word, die pakket moet aangestuur word, en die antwoord moet terugvind deur die vertaalingstoestand wat die gateway geskep het. Slaan die derde oor en die navraag vertrek netjies terwyl die kliënt vir ewig wag.

Neem die voorbeeld van gemagtigde kliënte in 10.77.0.0/24 wat op wg0 aankom, die geadverteerde adres 10.77.0.1 bevraag, en 'n resolver by 203.0.113.53 nodig het. Die opstroom-adres is 'n dokumentasie-plekhouer eerder as 'n werkende diens.

Om 'n navraag te herlei verander net sy bestemming

'n Bestemming-NAT-reël in PREROUTING herskryf die adres voordat die routeringsbesluit geneem word, so die pakket word daarna na die nuwe bestemming gerig in plaas van die oue. Die kliënt se bronadres word nie deur daardie bewerking geraak nie. Dit is waarom 'n reël wat volledig lyk steeds stilte kan lewer: die versoek reis nou na 'n resolver wat nog nooit van die kliënt se private reeks gehoor het nie. Die gateway het een veld vertaal en 'n tweede probleem geërf.

Albei DNS-vervoerwyses het passende reëls nodig, want 'n kliënt val terug na TCP wanneer 'n antwoord afgekap word.

Die reëls hieronder kies een inkomende koppelvlak, een kliëntreeks en een oorspronklike bestemmingsadres. Niks anders op die gateway word geraak nie, en 'n navraag van die gateway self pas glad nie.

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

Die antwoordpad is 'n aparte besluit

Twee reëlings laat die antwoord terugkeer, en om een vroeg te kies spaar 'n ontspanningsessie. Óf die opstroom-resolver het 'n roete terug na 10.77.0.0/24 deur hierdie gateway, óf die gateway vertaal die bron by uitgang sodat die antwoord by 'n adres aankom wat die opstroom al ken. Albei werk; net een daarvan pas by die beheer wat jy oor die opstroom het.

Roetering verdien die eerste poging, want dit hou die kliënt se adres sigbaar vir die resolver en vermy 'n tweede vertaallaag. Wanneer die opstroom buite jou beheer is, is bronvertaling op die spesifieke uitgang-koppelvlak die praktiese keuse.

Beperk daardie vertaling net so streng soos die herleiding, anders word die reël 'n algemene NAT vir enigiets wat toevallig pas:

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

Verbindingnasporing hou die kartering gepaard, so die antwoord word op die terugpad na die kliënt se oorspronklike tuple herskryf. Sonder die uitgangreël stuur die resolver sy antwoord na 'n private adres wat hy nie kan bereik nie, en die kliënt sien 'n tydsverloop eerder as 'n fout.

Skryf die reëls smaller as wat die taak lyk

Aanstuurtoestemming hoort by dieselfde omvang. Laat die vloei van kliënt na resolver en die terugkeerverkeer wat conntrack reeds herken toe, eerder as om elke DNAT-verbinding op die kas te aanvaar. 'n Algehele aanvaarding magtig ook poortaansture wat niks met DNS te doen het nie.

Die gateway se eie resolver is 'n ander kodebaan. 'n Navraag wat plaaslik uitgereik word, gaan deur OUTPUT, so om vanaf die gateway-dop te toets, oefen nóg die PREROUTING-reël nóg die aanstuurbeleid. Dit is waarom 'n plaaslike toets kan slaag terwyl elke kliënt misluk, en die omgekeerde is net so algemeen.

Niks hier dek DNS oor HTTPS op poort 443 of DNS oor TLS op poort 853 nie, en niks hier dek IPv6 nie. 'n Kliënt met 'n IPv6-resolver opgestel sal die hele reëling gerus ignoreer.

Wat 'n vars navraag bewys

Verbindingnasporing onthou vroeër karterings, so 'n navraag wat voor 'n reëlverandering gestuur is, kan uit die ou toestand beantwoord word en die nuwe reël laat lyk asof dit stukkend is. Begin met 'n nuwe bronpoort en, waar die kliënt antwoorde kas, 'n nuwe naam.

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

Die eerste opdrag wys of die kliëntpad hoegenaamd oplos, en die tweede wys die vertaling wat die gateway werklik geïnstalleer het, insluitend albei rigtings van die tuple. 'n Kartering wat na die regte resolver wys met 'n antwoordteller wat op nul vassteek, is 'n terugpadprobleem eerder as 'n filterprobleem.

Bevestig dat die resolver die name ken wat jy verwag voordat jy enigiets herlei. 'n Vervanging wat openbare name beantwoord, maar nie jou private sone nie verander 'n werkende opsoek in 'n NXDOMAIN wat soos 'n stukkende tonnel lyk. Toets die resolver direk, vanaf die gateway, voordat die kliëntpad betrokke is. Die iptables-uitbreidingsverwysing dokumenteer die DNAT- en masquerade-semantiek waarop hierdie reëls berus.