خصوصي VPN نومونه ناکامېږي؟ شک د DNS ریباینډ محافظت دی

په دفتر LAN کې داخلي نوم سمدلاسه ځواب ورکوي۔ د VPN د وصلېدو سره سم کار کول بندوي، اپلیکیشن د وخت ختمېدو راپور ورکوي، او ټنل پخپله پرته له شکایت ترافیک تېروي۔ هغه څه چې بدل شول ریزالور دی، او دغه ریزالور د خصوصي پتو په اړه خپل نظر لري۔

د ریباینډ محافظت د یوې ځانګړې چلې د بندولو لپاره شته۔ په قصد سره خپور شوی خصوصي نوم دومره ورته ښکاري چې دفاع فعاله شي۔

له تګلارې مخکې ځواب ولولئ

نوم له هغه ریزالور وپوښتئ چې VPN واقعاً یې توزیع کوي، نه له هغه چې ستاسو لپ ټاپ په کور کې کاروي۔ ځواب له هغه ریکارډ سره پرتله کړئ چې تمه یې لرئ، او ولیکئ چې ځواب خالي دی، رد شوی دی، که د هغو عامه پتو څخه ډک دی چې چا پلان نه و کړی۔

نښې یو پر بل ورګډېږي، نو تشخیص د ځواب بڼه ټاکي۔ NXDOMAIN ورکه ریکارډ دی، REFUSED د لاسرسي قاعده ده، د داخلي نوم لپاره عامه پته د تګلارې یا split-DNS تېروتنه ده، او هغه سمه خصوصي پته چې کلاینټ یې نه شي کارولی، بشپړه بېله ستونزه ده۔ رد شوې اړیکه یا ودرېدلې غوښتنه پخپله هیڅ نه ثابتوي، نو په داسې ټکټونو کې لومړی امر باید پلټنه وي، نه بیا پیلول۔ له هر څه بدلولو مخکې ځواب ولیکئ۔

دفاع واقعاً څه بندوي

DNS ریباینډ په دې کار کوي چې بدلوي چې یو نوم وروسته له هغه چې کلاینټ ورته باور کړی، په کوم ځای حلېږي۔ پاڼه د بریدګر تر کنټرول لاندې نوم څخه پورته کېږي، ځواب خصوصي پتې ته اوړي، او براوزر دوکه کېږي چې په سیمه ییزه شبکه کې له هغه څه سره خبرې وکړي چې هیڅکله به یې مستقیمه اړیکه نه وه منلې۔ دفاع دا ده چې هغه ځوابونه رد کړو چې خصوصي فضا ته اشاره کوي کله چې ریزالور هیڅکله ونه غوښتل شو چې خصوصي نوم فضا ته خدمت وکړي۔ همدا نابرابري ټول برید دی۔

dnsmasq په سمه توګه همدا چلند، د هر ډومین استثناوو سره یوځای مستند کوي۔ په خپل لارښود کې rebind-domain-ok د دې لپاره بیانوي چې هغه ډومینونه ونوموي چې کولای شي قانوناً داسې پتې بیرته راولي۔ دا د دې نښه وګڼئ چې پلان شوی سمون محدوده اجازه ده، نه نړیواله سویچ۔

استثنا د نوم فضا پورې محدوده کړئ

لومړی نوم فضا سمه کړئ، بیا استثنا۔ تایید کړئ چې ناکام نوم د هغه ډومین دی چې سازمان یې کنټرولوي او ریکارډ په قصد سره ساتل کېږي۔ ناڅاپي پته چې یوازې پېژندل شوې LAN لړۍ ته ورته ده، د استثنا نه بلکه د شک وړ ده، نو مخکې له دې چې کومه اجازه ولیکئ د زون مالک وګورئ۔

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

بیا هغه تر ټولو تنګه اجازه اضافه کړئ چې پلان شوي نومونه پوښي: یو ډومین، یا یو ګوښه شوی فرعي ډومین، د هغه ریزالور په تنظیم کې چې VPN کلاینټونه ترې پوښتي۔ د دغه ریزالور په هر نوم محافظت بندول یوځل له ټولو څخه دفاع لرې کوي، له هغو نومونو سره چې هیڅکله یې اړتیا نه درلوده۔

Split DNS په همدې پرېکړه کې راځي۔ که خصوصي نوم فضا باید یوازې په داخلي ریزالور ځواب شي، هلته یې خپره کړئ او عامه ریزالورونو ته یې تویېدل بند کړئ، تر څو استثنا یوه لاره پوښي نه هره لاره۔

سرچینه او دفاع بیا ازموئ

بیا وپوښتئ، بیا له خدمت سره وصل شئ او وګورئ کلاینټ څه ویني۔ سم خصوصي ځواب له روانې ناستې سره مانا دا ده چې استثنا یې ولګېده۔ سم ځواب له ودرېدلې ناستې سره مانا دا ده چې بل شک لاره یا د خدمت هویت دی۔

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

عامه نوم هم د همدې ریزالور له لارې ازموئ۔ محافظت باید د استثنا بهر نومونو لپاره لا سم چلند وکړي، او که دا ازموینه ناکامه شي، بدلون له پلان څخه پراخ و۔ د سندونو تایید تر پایه پورې ونه څنډئ، ځکه سم حل شوی نوم بیا هم باید له هغه سند سره سمون ولري چې خدمت یې وړاندې کوي۔

په ټکټ کې رد شوی ځواب، ډومین، ریزالور او د تګلارې خاوند ولیکئ۔ همدا ریکارډ دی چې یوه مرموزه داخلي خنډ په داسې تنظیمي بدلون بدلوي چې یو څوک یې بیاکتنه کولی شي۔