Kwa nini maulizo ya dnsmasq yanatoka nje ya VPN baada ya uelekezaji wa DNS

Mteja wa LAN anafikia VPN yake kwa usahihi na bado maulizo yake ya DNS yanaonekana kwenye kiungo cha juu kisicho sahihi. Hii si uvujaji kwa maana ya kawaida; ni kile kinachotokea kipanga njia kinapoacha kusambaza ulizo na kujibu yenyewe. Uingiliaji huandika upya lengwa kwenda soketi ya ndani, kisha kitatuzi hufungua mazungumzo ya pili, yasiyohusiana, yakiwa na anwani yake ya chanzo na uamuzi wake wa uelekezaji. Alama zilizowekwa kwenye mtiririko wa mteja zinaeleza mazungumzo ya kwanza na hakuna kitu kabisa kuhusu ya pili.

Alama haisafiri pamoja na ulizo

Alama za pakiti huishi kwenye ingizo la conntrack na kwenye pakiti iliyo safarini. Kanuni ya REDIRECT humaliza safari hiyo: mzigo hupewa soketi ya ndani, na ingizo la awali limefanya kazi yake. Kinachotoka kwenye kipanga njia baada ya hapo ni soketi mpya iliyoundwa na mchakato wa kitatuzi, ikiwa na anwani ya kipanga njia yenyewe kama chanzo.

Ndiyo sababu njia ya sera iliyofungwa kwenye anwani ya mteja wa LAN hailingani kamwe na ulizo la juu. Soketi mpya ni ya dnsmasq na si ya mteja, na kerneli hutathmini njia kwa trafiki ya kipanga njia yenyewe. Kanuni za chanzo, kanuni za kiolesura na kanuni za alama zote huona tuple tofauti. Kudhani kwamba alama inaenea ni kosa la kawaida zaidi katika mpangilio huu, na halionekani kwenye nakala ya upande wa mteja.

Mazungumzo mawili hushiriki jina na muda, na ndiyo hufanya yaonekane kama mtiririko mmoja unapopitia nakala kwa haraka.

Ambapo usambazaji hugeuka kuwa utatuzi wa ndani

Anza kwa kugundua kama mlango 53 unaelekezwa upya, unatafsiriwa kwenda mwenyeji mwingine, au unaachwa kama ulivyo, kwa sababu hali tatu hutenda tofauti. Uelekezaji kwenda mlango wa ndani humaliza usambazaji, wakati tafsiri kwenda mashine nyingine huiweka pakiti ikienda na kudumisha tuple ya mteja ikiwa na maana.

Angalia itifaki zote mbili. Kitatuzi kinachofikika kwa UDP na TCP kitajaribiwa kwa zote mbili, na seti ya kanuni inayoshughulikia UDP pekee huacha tundu tulivu kwa majibu makubwa. Kanuni zinazozalishwa na msimamizi wa usanidi wa kipanga njia yenyewe pia zinahesabiwa, na kuhariri faili iliyozalishwa kwa kawaida hushindwa na upakiaji upya unaofuata.

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'

Matokeo hayo hujibu maswali matatu kwa mpangilio: ni nini huandika upya ulizo, ni nini huipokea, na ni mchakato upi unamiliki soketi inayosikiliza. Mara mmiliki anapojulikana, sera ya juu ina mahali pa kuishi.

Mpe kitatuzi sera yake ya kutoka

Njia ya juu maalum kwa kikoa ni chombo safi zaidi wakati ni majina machache tu yanahitaji handaki. dnsmasq hukubali mstari wa server uliowekewa kikomo cha kikoa, ukiwa na kiolesura au anwani ya chanzo ya hiari inayoelekeza ulizo kutoka kifaa kilichochaguliwa. Uelekezaji huo ndio hufanya mazungumzo ya pili yafuate VPN.

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

Kikoa, anwani na kiolesura vilivyo juu ni nafasi za thamani zako mwenyewe. Uchaguzi wa kikoa na udhibiti wa kutoka hubaki maamuzi tofauti: njia lazima iwepo, anwani ya chanzo lazima iruhusiwe na kitatuzi cha juu, na ngome lazima iruhusu jibu. Uelekezaji wa kiolesura pekee si fail-closed, kwa sababu handaki iliyotoweka inaweza kumwacha kitatuzi kianguke kwenye njia nyingine. Weka mbali mbadala wowote wa umma na nafasi ya majina inayopaswa kubaki ya faragha.

Weka mstari kwa mmiliki wa usanidi unaoungwa mkono na kipanga njia badala ya kwenye faili iliyozalishwa, vinginevyo upakiaji upya unaofuata hufuta marekebisho.

Kile ambacho hifadhi ya pamoja haiwezi kuhifadhi

Kisambazaji kimoja chenye hifadhi moja huhudumia kila mteja wa LAN, na hilo hubomoa tofauti ambayo baadhi ya mitandao inaihitaji. Ikiwa wateja wawili lazima watatue jina moja kwa namna tofauti, soketi ya pamoja haina njia ya kurejesha ni mteja gani aliuliza. Sera kwa kila mteja lazima iishi katika nakala tofauti za kitatuzi au katika kipengele cha usambazaji kinachohifadhi utambulisho.

Jibu lililohifadhiwa pia si ushahidi kuhusu njia mpya. Jibu linaweza kuja kutoka kumbukumbu wakati njia ya juu inabaki imevunjika.

Kanuni za mlango 53 hazisemi chochote kuhusu programu zinazozungumza DNS kwa HTTPS au kwa TLS. Maulizo hayo hayafiki kamwe kwenye uelekezaji, kwa hiyo sera iliyojengwa kwenye mlango 53 pekee inaeleza sehemu ndogo ya trafiki na inapaswa kuandikwa kama sehemu ndogo.

Thibitisha mazungumzo ya pili, si ya kwanza

Jaribu kwa jina moja unalodhibiti na uangalie pande zote mbili. Nakala ya upande wa mteja inathibitisha ulizo liliondoka LAN; upande wa kipanga njia pekee ndio huthibitisha lilikokwenda baadaye.

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

Futa hifadhi kabla ya kila jaribio, kwa sababu jibu la moto huficha njia ya juu iliyovunjika. Rudia kwa TCP, kisha rudia ukiwa umezima handaki ili uone kitatuzi hufanya nini njia yake inayopendekezwa inapotoweka. Tabia hiyo ya mwisho ndiyo huamua kama muundo ni fail-closed au ni bahati tu.