Bakit lumalabas ang mga query ng dnsmasq sa VPN pagkatapos ng DNS redirect

Tamang nakakarating ang kliyente sa LAN sa VPN nito at gayunma’y lumalabas ang mga query nitong DNS sa maling uplink. Hindi ito pagtagas sa karaniwang kahulugan; ito ang nangyayari kapag tumigil ang router sa pagpapasa ng query at siya mismo ang sumasagot dito. Isinusulat muli ng interception ang destinasyon patungo sa lokal na socket, at pagkatapos ay magbubukas ang resolver ng pangalawa, walang kaugnayang usapan gamit ang sarili nitong address ng pinagmulan at sarili nitong desisyon sa routing. Ang mga markang inilapat sa daloy ng kliyente ay naglalarawan ng unang usapan at wala talagang sinasabi tungkol sa pangalawa.

Hindi naglalakbay kasama ng query ang marka

Nabubuhay ang mga marka ng packet sa isang entry ng conntrack at sa packet na nasa byahe. Tinatapos ng isang tuntunin ng REDIRECT ang byaheng iyon: ibinibigay ang payload sa lokal na socket, at nagawa na ng orihinal na entry ang trabaho nito. Ang umaalis sa router pagkatapos ay isang sariwang socket na ginawa ng proseso ng resolver, na ang address ng router mismo ang pinagmulan.

Kaya’t ang rutang patakaran na nakasusi sa address ng kliyente sa LAN ay hindi kailanman tumutugma sa query sa upstream. Ang bagong socket ay pag-aari ng dnsmasq at hindi ng kliyente, at sinusuri ng kernel ang ruta para sa trapik ng router mismo. Ang mga tuntunin sa pinagmulan, mga tuntunin sa interface at mga tuntunin sa marka ay nakakakita ng ibang tuple. Ang pag-akalang kumakalat ang marka ang pinakakaraniwang pagkakamali sa setup na ito, at hindi ito nakikita sa isang pagkuha sa gilid ng kliyente.

Nagsasalo ang dalawang usapan ng isang pangalan at isang oras, at iyon ang dahilan kung bakit parang isang daloy sila kapag mabilis mong tiningnan ang isang pagkuha.

Saan nagiging lokal na paglutas ang pagpapasa

Magsimula sa pag-alam kung ang port 53 ay inililipat, isinasalin sa ibang host, o hinahayaang gaya ng dati, dahil magkaiba ang pag-uugali ng tatlong kaso. Ang paglilipat patungo sa lokal na port ay nagtatapos sa pagpapasa, samantalang ang pagsasalin patungo sa ibang makina ay nagpapanatili sa packet na gumagalaw at nagpapanatili sa tuple ng kliyente na may kahulugan.

Tingnan ang dalawang protocol. Ang resolver na maaabot sa UDP at TCP ay susubukan sa dalawa, at ang set ng tuntuning sumasakop lamang sa UDP ay nag-iiwan ng tahimik na butas para sa malalaking sagot. Binibilang din ang mga tuntuning nililikha ng sariling tagapamahala ng pagsasaayos ng router, at ang pag-edit ng nilikhang file ay karaniwang natatalo ng susunod na pagkarga.

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'

Sinasagot ng mga output na iyon ang tatlong tanong nang sunud-sunod: ano ang nagsusulat muli ng query, ano ang tumatanggap nito, at aling proseso ang may-ari ng socket na nakikinig. Kapag alam na ang may-ari, may matitirhan na ang patakaran sa upstream.

Bigyan ang resolver ng sarili nitong patakaran sa paglabas

Ang upstream na espesipiko sa domain ang pinakamalinis na kasangkapan kapag iilang pangalan lamang ang kailangan ng tunnel. Tumatanggap ang dnsmasq ng linyang server na nakatali sa isang domain, may opsyonal na interface o address ng pinagmulan na nagdadala ng query palabas mula sa piniling aparato. Ang paggabay na iyon ang dahilan kung bakit sinusunod ng pangalawang usapan ang VPN.

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

Ang domain, address at interface sa itaas ay mga pansamantalang kapalit para sa sarili mong mga halaga. Nananatiling magkahiwalay na desisyon ang pagpili ng domain at kontrol sa paglabas: dapat umiiral ang ruta, dapat pahintulutan ng resolver sa upstream ang address ng pinagmulan, at dapat pahintulutan ng firewall ang sagot. Ang paggabay sa interface lamang ay hindi fail-closed, dahil ang nawalang tunnel ay maaaring mag-iwan sa resolver na mahulog sa ibang landas. Ilayo ang anumang pampublikong kapalit sa isang puwang ng pangalan na dapat manatiling pribado.

Ilagay ang linya sa may-ari ng pagsasaayos na sinusuportahan ng router at hindi sa nilikhang file, kung hindi ay buburahin ng susunod na pagkarga ang pagwawasto.

Ano ang hindi kayang pangalagaan ng pinagsasaluhang cache

Ang isang tagapasa na may isang cache ay naglilingkod sa bawat kliyente sa LAN, at iginigiba nito ang pagkakaibang kailangan ng ilang network. Kung dalawang kliyente ang kailangang lutasin ang parehong pangalan nang magkaiba, walang paraan ang pinagsasaluhang socket upang mabawi kung sino ang nagtanong. Dapat manirahan ang patakaran sa bawat kliyente sa magkahiwalay na instans ng resolver o sa isang tampok sa pagpapasa na nagpapanatili ng pagkakakilanlan.

Ang sagot na naka-cache ay hindi rin katibayan tungkol sa bagong landas. Maaaring dumating ang sagot mula sa memorya habang nananatiling sira ang ruta sa upstream.

Walang sinasabi ang mga tuntunin sa port 53 tungkol sa mga aplikasyong nagsasalita ng DNS sa HTTPS o sa TLS. Hindi kailanman nakakarating sa paglilipat ang mga query na iyon, kaya ang patakarang itinayo lamang sa port 53 ay naglalarawan ng isang subset ng trapik at dapat itong idokumento bilang isang subset.

I-verify ang pangalawang usapan, hindi ang una

Subukan gamit ang isang pangalang kontrolado mo at panoorin ang dalawang panig. Pinatutunayan ng pagkuha sa gilid ng kliyente na umalis ang query sa LAN; ang gilid ng router lamang ang nagpapatunay kung saan ito nagtungo.

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

I-flush ang cache bago ang bawat pagtatangka, dahil itinatago ng mainit na sagot ang sirang upstream. Ulitin sa TCP, pagkatapos ay ulitin nang patay ang tunnel upang makita kung ano ang ginagawa ng resolver kapag wala na ang ginustong landas nito. Ang huling pag-uugali na iyon ang nagpapasya kung ang disenyo ay fail-closed o mapalad lamang.