Zergatik ihes egiten dute dnsmasq-eko kontsultek VPN-tik DNS birbideraketa baten ondoren

LANeko bezeroa zuzen iristen da bere VPN-ra, eta hala ere bere DNS kontsultak okerreko goranzko estekan agertzen dira. Hori ez da ohiko zentzuan ihes bat; hori gertatzen da routerrak kontsulta bat birbidaltzeari uzten dionean eta berak erantzuten dionean. Interzeptzioak helburua socket lokal batera birmoldatzen du, eta gero resolverrak bigarren elkarrizketa bat irekitzen du, aurrekoarekin zerikusirik ez duena, bere iturburu helbidearekin eta bere bideratze-erabakiarekin. Bezeroaren fluxuari aplikatutako markek lehen elkarrizketa deskribatzen dute eta bigarrenari buruz erabat ezer ez.

Marka ez da kontsultarekin batera joaten

Pakete-markak conntrack sarrera batean eta hegaldian dagoen paketean bizi dira. REDIRECT arau batek hegaldi hori amaitzen du: karga socket lokal bati ematen zaio eta jatorrizko sarrerak bere lana egin du. Ondoren routerretik irteten dena resolver prozesuak sortutako socket berria da, routerraren beraren helbidea iturburu duelarik.

Horregatik LANeko bezeroaren helbidean giltzarritutako politika-bide bat ez dator inoiz bat goranzko kontsultarekin. Socket berria dnsmasq-i dagokio, ez bezeroari, eta kernelak routerraren beraren trafikoarentzat ebaluatzen du bidea. Iturburu-arauak, interfaze-arauak eta marka-arauak denek tuple desberdin bat ikusten dute. Marka hedatzen dela suposatzea da konfigurazio honetako akats ohikoena, eta ikusezina da bezeroaren aldeko kaptura batean.

Bi elkarrizketek izen bat eta denbora bat partekatzen dituzte, eta horixe da kaptura bat azaletik begiratzean fluxu bakar bat ematen dutena.

Non bihurtzen den birbidalketa tokiko ebazpen

Hasi 53 ataka birbideratzen den, beste ostalari batera itzultzen den edo ukitu gabe uzten den zehazten, hiru kasuek desberdin jokatzen dutelako. Ataka lokal baterako birbideraketak birbidalketa amaitzen du, eta beste makina baterako itzulpenak paketea mugimenduan eta bezeroaren tuplea esanguratsuan mantentzen ditu.

Begiratu bi protokoloak. UDP eta TCP bidez irisgarria den resolver bat bien bidez probatuko da, eta UDP soilik estaltzen duen arau-multzo batek zulo isil bat uzten du erantzun handientzat. Routerraren beraren konfigurazio-kudeatzaileak sortutako arauak ere zenbatzen dira, eta sortutako fitxategi bat editatzek normalean galtzen du hurrengo birkargaren aurrean.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Irteera horiek hiru galderari erantzuten diete ordenan: zer den kontsulta birmoldatzen duena, zer den hura jasotzen duena eta zein prozesuk duen entzuten ari den socketaren jabea. Jabea ezagututa, goiko politikak badu non bizi.

Eman resolverrari bere irteera-politika

Domeinu zehatzeko goiko esteka bat tresnarik garbiena da izen batzuek bakarrik tunela behar dutenean. dnsmasq-k domeinu batera mugatutako server lerro bat onartzen du, aukerako interfaze edo iturburu helbide batekin, kontsulta aukeratutako gailutik kanpora bideratzen duena. Bideratze horrek egiten du bigarren elkarrizketa VPN-a jarraitzea.

server=/corp.example/10.30.0.53@tun_work
log-queries

Goiko domeinua, helbidea eta interfazea zure balioetarako leku-markak dira. Domeinuaren hautaketa eta irteeraren kontrola erabaki bereiziak izaten jarraitzen dute: bidea egon behar da, goiko resolverrak iturburu helbidea onartu behar du eta suebakiak erantzuna baimendu behar du. Interfazearen bideratze soila ez da fail-closed, desagertutako tunel batek resolverra beste bide batera eroraraz baititzake. Eduki ezazu edozein ordezko publiko pribatu izaten jarraitu behar duen izen-espaziotik urrun.

Jarri lerroa routerrak onartzen duen konfigurazio-jabean, sortutako fitxategi batean beharrean, bestela hurrengo birkargak ezabatzen du konponketa.

Zer ezin duen cache partekatu batek gorde

Birbidaltzaile bat cache batekin LANeko bezero guztiak zerbitzatzen ditu, eta horrek sare batzuek behar duten bereizketa hondatzen du. Bi bezerok izen bera modu desberdinean ebatzi behar badute, socket partekatuak ez du modurik zein bezerok galdetu zuen berreskuratzeko. Bezero bakoitzeko politikak resolver instantzia bereizietan edo nortasuna gordetzen duen birbidaltze-ezaugarri batean bizi behar du.

Cachean gordetako erantzun bat ere ez da bide berriaren froga. Erantzuna memoriarik etor daiteke goiko bidea hautsita jarraitzen duen bitartean.

53 atakako arauek ez dute ezer esaten DNS HTTPS edo TLS bidez hitz egiten duten aplikazioei buruz. Kontsulta horiek ez dira inoiz birbideraketara iristen, beraz 53 atakan soilik eraikitako politika batek trafikoaren azpimultzo bat deskribatzen du eta azpimultzo gisa dokumentatu beharko litzateke.

Egiaztatu bigarren elkarrizketa, ez lehena

Probatu kontrolatzen duzun izen batekin eta begiratu bi aldeak. Bezeroaren aldeko kaptura batek frogatzen du kontsulta LANA utzi zuela; routerraren aldeak soilik frogatzen du hurrena nora joan zen.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Garbitu cachea saiakera bakoitzaren aurretik, erantzun epel batek goiko esteka hautsi bat ezkutatzen baitu. Errepikatu TCP bidez, gero errepikatu tunela itzalita resolverrak zer egiten duen ikusteko bere bide hobetsia desagertu denean. Azken portaera horrek erabakitzen du diseinua fail-closed den edo zortea besterik ez duen.