राउटरचा स्वतःचा 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 एंडपॉइंटशिवाय अन्यत्रून येणारे उत्तर स्वतःच गळती नाही; कॉन्फिगरेशनने तो मार्ग अपघाताने निवडल्यावरच ते गळती होते।