राउटर का अपना DNS VPN टनल को क्यों बायपास करता है?

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

पैकेट कैप्चर वास्तव में किस प्रवाह का है

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

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

व्यावहारिक जाँच यह है कि दोनों पक्षों को एक साथ देखें। राउटर पर रिज़ॉल्वर का सॉकेट सूचीबद्ध करें, उससे स्थानीय रूप से क्वेरी करें और WAN इंटरफ़ेस कैप्चर करें:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

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

नीति-मार्ग दूसरी क्वेरी को कभी क्यों नहीं देखता

फ़ायरवॉल नियम इंटरफ़ेस, स्रोत, गंतव्य और पोर्ट के विरुद्ध लिखे जाते हैं, और उनका मूल्यांकन उन पैकेटों के लिए होता है जो बॉक्स से गुज़रते हैं। राउटर जो क्वेरी बनाता है वह किसी से नहीं गुज़रती, क्योंकि एक स्थानीय प्रक्रिया उसे सीधे रूटिंग तालिका को सौंप देती है। नीति-रूटिंग और NAT इसलिए केवल फ़ॉरवर्ड किए गए पथ पर लागू होते हैं, और इसी कारण नियमों का समूह पूरा दिख सकता है और फिर भी राउटर के DNS को टनल के बाहर छोड़ सकता है।

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

pfSense रिज़ॉल्वर अपना अपस्ट्रीम पथ कहाँ तय करता है

pfSense इस विभाजन को दृश्य बनाता है। क्लाइंट ट्रैफ़िक को नीति-मार्ग से VPN गेटवे से गुज़ारा जा सकता है, जबकि फ़ायरवॉल का अपना ट्रैफ़िक LAN नियमों के बजाय रिज़ॉल्वर की आउटगोइंग सेटिंग का पालन करता है। वेब इंटरफ़ेस में वह सेटिंग Services > DNS Resolver > Outgoing Network Interfaces के अंतर्गत है, और उसका मान उन इंटरफ़ेसों की सूची है जिन्हें रिज़ॉल्वर अपस्ट्रीम क्वेरी के लिए उपयोग कर सकता है।

वहाँ टनल इंटरफ़ेस का नाम देना, और केवल वही इंटरफ़ेस, वही है जो राउटर की अपनी लुकअप को टनल का पालन करवाता है। डिफ़ॉल्ट पर छोड़ने पर रिज़ॉल्वर रूटिंग तालिका से एग्रेस चुनता है, जो दोहरे WAN या VPN वाले होस्ट पर अक्सर WAN होता है।

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

सेटिंग से पहले विफलता व्यवहार चुनें

जब टनल गिरती है तो दो व्यवहार तर्कसंगत हैं: कुछ भी लीक न हो इसलिए अपस्ट्रीम क्वेरी रोक देना, या ज्ञात पथ पर स्वीकृत रिज़ॉल्वर पर लौट जाना। दोनों नीतियाँ हैं, और डिफ़ॉल्ट में इनमें से कोई नहीं मिलता। इंटरफ़ेस सूची को छूने से पहले तय करें कि नेटवर्क को कौन-सी चाहिए।

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

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

दोनों पथ जाँचें और परिणाम अलग रखें

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

LAN क्लाइंट से राउटर से पहले सार्वजनिक नाम माँगें और फिर निजी नाम, जिसका उत्तर केवल आपका आंतरिक ज़ोन दे। केवल दूसरी क्वेरी में विफलता टनल नहीं बल्कि नाम-फ़ॉरवर्डिंग की ओर संकेत करती है:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

फिर टनल नीचे गिराएँ और दोनों क्वेरी दोहराएँ। अस्वीकृत उत्तरों का अर्थ है कि रिज़ॉल्वर विफलता पर बंद है; सफल उत्तर फ़ॉलबैक रिज़ॉल्वर और उसके उपयोग किए पथ की ओर संकेत करता है। इसकी तुलना अपने लिखे नोट और उसी मिनट में WAN इंटरफ़ेस पर लिए गए कैप्चर से करें।

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