राउटरको आफ्नै 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 एन्डपोइन्टबाहेक अन्त कतैबाट आउने जवाफ आफैँमा चुहावट होइन; कन्फिगरेसनले त्यो मार्ग संयोगले छान्दा मात्र त्यो चुहावट बन्छ।