WireGuard DNS DNAT: mantendu erantzunaren bidea lanean

DNATek helmuga berridazten du, ez iturria. Erabaki nola erantzun dezakeen goiko resolverrak araua gehitu aurretik, eta mantendu kointzidentzia bakoitza estu.

WireGuard bezero baten DNS kontsulta beste resolver batera bideratzeak arau bakarra dirudi eta hiru erabaki bezala jokatzen du. Helmuga berridatzi behar da, paketea birbidali behar da, eta erantzunak gatewayak sortutako itzulpen-egoeratik bidea aurkitu behar du. Hirugarrena saltatzen baduzu, kontsultak garbi alde egiten du bezeroa betiko itxaroten duen bitartean.

Hartu 10.77.0.0/24-ko bezero baimenduen adibidea: wg0 bidez iristen dira, iragarritako 10.77.0.1 helbidea galdetzen dute eta 203.0.113.53-n resolver bat behar dute. Goiko helbidea dokumentaziorako leku-marka bat da, ez zerbitzu eraginkor bat.

Kontsulta bat berbideratzeak haren helmuga soilik aldatzen du

PREROUTING-eko helmuga-NAT arau batek helbidea berridazten du bideratze-erabakia hartu aurretik, beraz paketea gero helmuga berrira bideratzen da zaharrera beharrean. Bezeroaren iturburu-helbidea ukitu gabe geratzen da eragiketa horrekin. Horregatik arau osoa dirudienak isiltasuna sor dezake oraindik: eskaera orain bezeroaren barruti pribatuaz inoiz entzun ez duen resolver batera doa. Gatewayak eremu bat itzuli zuen eta bigarren arazo bat heredatu.

Bi DNS garraioek bat datozen arauak behar dituzte, bezeroa TCP-ra itzultzen baita erantzuna mozten denean.

Beheko arauek sarrerako interfaze bat, bezero-barruti bat eta jatorrizko helmuga-helbide bat hautatzen dituzte. Gatewayan beste ezer ez da ukitzen, eta gatewayaren beraren kontsulta bat ez dator bat ere.

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

Erantzunaren bidea erabaki bereizia da

Bi antolamenduk uzten dute erantzuna itzultzen, eta bat goiz aukeratzeak arazketa-saio bat aurrezten du. Edo goiko resolverrak 10.77.0.0/24-ra itzultzeko bidea du gateway honen bidez, edo gatewayak iturria irteeran itzultzen du erantzuna goikoak jada ezagutzen duen helbide batera irits dadin. Biak funtzionatzen dute; bakarra dator goikoaren gainean duzun kontrolarekin bat.

Bideratzeak lehen saiakera merezi du, bezeroaren helbidea resolverrarentzat ikusgai mantentzen duelako eta bigarren itzulpen-geruza bat saihesten duelako. Goikoa zure kontrolpetik kanpo dagoenean, irteerako interfaze zehatzean iturria itzultzea da aukera praktikoa.

Mugatu itzulpen hori berbideratzea bezain estu, bestela araua erabilera orokorreko NAT bihurtuko da harekin bat egiten duen edozertarako:

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

Konexioen jarraipenak mapaketa bikotean mantentzen du, beraz erantzuna bezeroaren hasierako tuplara berridazten da itzultzean. Irteera-araua gabe, resolverrak bere erantzuna iritsi ezin duen helbide pribatu batera bidaltzen du, eta bezeroak denbora-muga ikusten du errore baten ordez.

Idatzi arauak zeregina dirudiena baino estuago

Birbidaltze-baimena esparru berari dagokio. Baimendu bezerotik resolverrako fluxua eta conntrack-ek jada ezagutzen duen itzulera-trafikoa, makinan DNAT konexio bakoitza onartu beharrean. Onarpen orokorrak DNS-rekin zerikusirik ez duten portu-birbidaltzeak ere baimenduko lituzke.

Gatewayaren resolver propioa beste kode-bide bat da. Bertan igorritako kontsulta bat OUTPUT-etik igarotzen da, beraz gatewayaren shell-etik probatzeak ez du PREROUTING araua ezta birbidaltze-politika ere praktikatzen. Horregatik proba lokal batek gaindi dezake bezero guztiek huts egiten duten bitartean, eta alderantzizkoa bezain ohikoa da.

Hemen ez da ezerk estaltzen HTTPS gaineko DNS 443 portuan edo TLS gaineko DNS 853 portuan, ezta IPv6 ere. IPv6 resolver bat konfiguratuta duen bezeroak pozik egingo dio jaramonik ez antolamendu osoari.

Zer frogatzen du kontsulta berri batek

Konexioen jarraipenak aurreko mapak gogoratzen ditu, beraz arau-aldaketa baten aurretik bidalitako kontsulta bat egoera zaharretik erantzun daiteke eta arau berria hautsia dirudite. Hasi iturburu-portu berri batekin eta, bezeroak erantzunak cachean gordetzen dituen lekuan, izen berri batekin.

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

Lehen komandoak bezeroaren bidea nola edo hala ebazten den erakusten du, eta bigarrenak gatewayak benetan instalatu zuen itzulpena, tuplaren bi noranzkoak barne. Resolver zuzena seinalatzen duen mapa batek, erantzun-kontagailua zeroan itsatsita, itzulera-bideko arazoa da eta ez iragazki-arloa.

Egiaztatu resolverrak espero dituzun izenak ezagutzen dituela ezer berbideratu aurretik. Izen publikoak erantzuten dituen baina zure zona pribatua ez duen ordezkoa funtzionatzen duen bilaketa bat tunel hautsia dirudien NXDOMAIN bihurtzen du. Probatu resolverra zuzenean, gatewaytik, bezeroaren bidea tartean sartu aurretik. Eta iptables luzapenen erreferentzia arau hauek oinarri dituzten DNAT eta masquerade semantika dokumentatzen du.

Erlazionatutako artikuluak