DNS रीडायरेक्ट के बाद dnsmasq क्वेरीज़ VPN से बाहर क्यों निकल जाती हैं

LAN क्लाइंट अपने VPN तक ठीक से पहुँचता है, फिर भी उसकी DNS क्वेरीज़ गलत अपलिंक पर दिखाई देती हैं। यह सामान्य अर्थ में लीक नहीं है; यह तब होता है जब राउटर क्वेरी को आगे भेजना बंद कर देता है और स्वयं उसका उत्तर देता है। इंटरसेप्शन गंतव्य को स्थानीय सॉकेट में फिर से लिखता है, और फिर रिज़ॉल्वर अपने स्वयं के स्रोत पते और अपने स्वयं के रूटिंग निर्णय के साथ दूसरी, असंबंधित बातचीत खोलता है। क्लाइंट के फ़्लो पर लगाए गए मार्क पहली बातचीत का वर्णन करते हैं और दूसरी के बारे में कुछ भी नहीं।

मार्क क्वेरी के साथ यात्रा नहीं करता

पैकेट मार्क conntrack प्रविष्टि पर और उड़ान में पैकेट पर रहते हैं। एक REDIRECT नियम उस उड़ान को समाप्त करता है: पेलोड स्थानीय सॉकेट को सौंपा जाता है, और मूल प्रविष्टि अपना काम कर चुकी होती है। इसके बाद राउटर से जो निकलता है वह रिज़ॉल्वर प्रक्रिया द्वारा बनाया गया नया सॉकेट है, जिसका स्रोत राउटर का अपना पता है।

इसीलिए LAN क्लाइंट के पते पर आधारित पॉलिसी रूट कभी अपस्ट्रीम क्वेरी से नहीं मिलता। नया सॉकेट क्लाइंट का नहीं बल्कि dnsmasq का है, और कर्नेल राउटर के अपने ट्रैफ़िक के लिए रूट का मूल्यांकन करता है। स्रोत नियम, इंटरफ़ेस नियम और मार्क नियम सभी एक अलग टपल देखते हैं। यह मानना कि मार्क आगे फैलता है, इस सेटअप में सबसे आम गलती है, और क्लाइंट-साइड कैप्चर में यह अदृश्य रहती है।

दोनों बातचीतें वास्तव में एक नाम और एक समय साझा करती हैं, और यही उन्हें कैप्चर को जल्दी से देखने पर एक ही फ़्लो जैसा बना देता है।

कहाँ फ़ॉरवर्डिंग स्थानीय रिज़ॉल्यूशन बन जाती है

पहले यह पता करें कि पोर्ट 53 रीडायरेक्ट हो रहा है, किसी दूसरे होस्ट पर अनुवादित हो रहा है, या यूँ ही छोड़ा गया है, क्योंकि तीनों स्थितियाँ अलग व्यवहार करती हैं। स्थानीय पोर्ट पर रीडायरेक्ट फ़ॉरवर्डिंग समाप्त कर देता है, जबकि किसी दूसरी मशीन पर अनुवाद पैकेट को चलायमान रखता है और क्लाइंट के टपल को अर्थपूर्ण रखता है।

दोनों प्रोटोकॉल देखें। UDP और TCP पर पहुँचने योग्य रिज़ॉल्वर का दोनों पर परीक्षण होगा, और केवल UDP को कवर करने वाला नियम-समूह बड़े उत्तरों के लिए एक शांत छेद छोड़ देता है। राउटर के अपने कॉन्फ़िगरेशन मैनेजर द्वारा बनाए गए नियम भी गिने जाते हैं, और बनाई गई फ़ाइल में संपादन आमतौर पर अगली रीलोड से हार जाता है।

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'

ये आउटपुट क्रम से तीन प्रश्नों का उत्तर देते हैं: क्वेरी को क्या फिर से लिखता है, उसे क्या प्राप्त करता है, और सुनने वाले सॉकेट का स्वामी कौन-सी प्रक्रिया है। स्वामी ज्ञात होने के बाद अपस्ट्रीम पॉलिसी के पास रहने की जगह होती है।

रिज़ॉल्वर को उसकी अपनी इग्रेस पॉलिसी दें

डोमेन-विशिष्ट अपस्ट्रीम सबसे स्वच्छ उपकरण है जब केवल कुछ नामों को टनल चाहिए। dnsmasq डोमेन तक सीमित server पंक्ति स्वीकार करता है, साथ में वैकल्पिक इंटरफ़ेस या स्रोत पता जो क्वेरी को चुने गए उपकरण से बाहर ले जाता है। यही मार्गदर्शन दूसरी बातचीत को VPN का अनुसरण कराता है।

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

ऊपर दिया गया डोमेन, पता और इंटरफ़ेस आपके अपने मानों के लिए प्लेसहोल्डर हैं। डोमेन चयन और इग्रेस नियंत्रण अलग निर्णय रहते हैं: रूट का होना आवश्यक है, स्रोत पते को अपस्ट्रीम रिज़ॉल्वर की अनुमति होनी चाहिए, और फ़ायरवॉल को उत्तर की अनुमति देनी चाहिए। केवल इंटरफ़ेस मार्गदर्शन fail-closed नहीं है, क्योंकि गायब हो चुकी टनल रिज़ॉल्वर को किसी दूसरे मार्ग पर गिरने दे सकती है। किसी भी सार्वजनिक फ़ॉलबैक को ऐसे नामस्थान से दूर रखें जिसे निजी ही रहना चाहिए।

पंक्ति को बनाई गई फ़ाइल में नहीं बल्कि उस कॉन्फ़िगरेशन स्वामी में रखें जिसे राउटर समर्थित करता है, वरना अगली रीलोड सुधार को मिटा देगी।

साझा कैश क्या सुरक्षित नहीं रख सकता

एक कैश वाला एक फ़ॉरवर्डर हर LAN क्लाइंट की सेवा करता है, और यह उस भेद को ढहा देता है जिसकी कुछ नेटवर्कों को आवश्यकता होती है। यदि दो क्लाइंटों को एक ही नाम अलग-अलग हल करना हो, तो साझा सॉकेट के पास यह पुनः प्राप्त करने का कोई तरीका नहीं है कि किसने पूछा। प्रति-क्लाइंट पॉलिसी अलग रिज़ॉल्वर इंस्टेंस में या पहचान बनाए रखने वाली फ़ॉरवर्डिंग सुविधा में रहनी चाहिए।

कैश किया गया उत्तर भी नए मार्ग के बारे में प्रमाण नहीं है। उत्तर स्मृति से आ सकता है जबकि अपस्ट्रीम रूट टूटा रहता है।

पोर्ट 53 के नियम उन अनुप्रयोगों के बारे में कुछ नहीं कहते जो DNS को HTTPS या TLS पर बोलते हैं। वे क्वेरीज़ कभी रीडायरेक्ट तक नहीं पहुँचतीं, इसलिए केवल पोर्ट 53 पर बनी पॉलिसी ट्रैफ़िक का एक उपसमुच्चय वर्णित करती है और उसे उपसमुच्चय के रूप में प्रलेखित किया जाना चाहिए।

दूसरी बातचीत सत्यापित करें, पहली नहीं

उस नाम से परीक्षण करें जिसे आप नियंत्रित करते हैं और दोनों पक्ष देखें। क्लाइंट-साइड कैप्चर सिद्ध करता है कि क्वेरी ने LAN छोड़ दिया; केवल राउटर पक्ष सिद्ध करता है कि वह आगे कहाँ गई।

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

हर प्रयास से पहले कैश फ़्लश करें, क्योंकि गर्म उत्तर टूटे अपस्ट्रीम को छिपा देता है। TCP पर दोहराएँ, फिर टनल बंद करके दोहराएँ ताकि देख सकें कि रिज़ॉल्वर अपना पसंदीदा मार्ग जाने पर क्या करता है। वही अंतिम व्यवहार तय करता है कि डिज़ाइन fail-closed है या केवल भाग्यशाली।