OpenWrt नीति राउटिङ: स्थानीय DNS समात्ने चेन

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

दुई फ्लो, एउटा रिजोल्भर ठेगाना

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

दोस्रो फ्लो कहिल्यै कतैबाट आउँदैन। राउटरले यसलाई बनाउँछ, त्यसैले आउने प्याकेट छैन र मिलाउन फर्वार्डिङ चरण पनि छैन।

दुवैले एउटै रिजोल्भर ठेगानालाई लक्ष्य गर्न सक्छन्, र त्यसैले फरक छुटाउन सजिलो छ। एउटै गन्तव्य, फरक उत्पत्ति, फरक चेन। उत्पत्ति देख्ने बित्तिकै बाँकी निदान पछ्याउँछ।

फर्वार्ड गरिएका र स्थानीय रूपमा बनेका प्याकेट फरक तरिकाले प्रवेश गर्छन्

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

स्थानीय रूपमा बनेको ट्राफिक राउटरमा रहेको प्रक्रियाले बनाउँछ र यसको सट्टा आउटपुट मार्गमा प्रवेश गर्छ। राउटरको आफ्नै निर्णयले यसलाई राउट गर्छ र नीतिले त्यो चेन ढाकेमा मात्र नीतिसँग भेट्छ। मिलाउन आउने इन्टरफेस छैन र अवलोकन गर्न फर्वार्डिङ निर्णय पनि छैन।

यो प्याकेटहरू कहाँ जन्मन्छन् भन्ने गुण हो, कुनै विशेष प्याकेजको होइन। एउटा चेनका लागि लेखिएको नियमको अर्कोबारे साधारणतः कुनै राय हुँदैन। कुनै पनि नियम ट्युनिङले यो बदल्दैन।

आउटपुट चेन छान्नुहोस्, त्यसपछि मिलान साँघुरो पार्नुहोस्

उपाय भनेको त्यही मनसाय आउटपुट चेनमा पनि जोड्नु, वा राउटरकै क्वेरी महत्त्वपूर्ण भएमा नियम त्यहाँ सार्नु हो। नीति राउटिङ प्याकेजमा बनेको OpenWrt सेटअपमा यसको अर्थ नियमको चेन सेटिङमा prerouting को सट्टा output छान्नु हो। दुवै जनसंख्यालाई कभरेज चाहिएमा दुवै नियम राख्नुहोस्।

त्यसपछि नियमले केसँग मिल्छ त्यो साँघुरो पार्नुहोस्। रिजोल्भरले वास्तवमा प्रयोग गर्ने पोर्टमा गन्तव्य रिजोल्भर ठेगानाहरू, राउटरले बनाउने सबै टनेलमा पठाउनुभन्दा धेरै सानो निर्णय हो।

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

टनेलको आफ्नै यातायात नियमबाहिर राख्नुहोस्

टनेलको बाहिरी जडान पनि राउटरले बनाउँछ। स्थानीय रूपमा बनेको सबै ट्राफिक टनेलमा पठाउने नियमले टनेललाई यसैको मार्गबाट राउट गर्छ, र यो अत्ति नै उठ्दैन।

व्यवस्थापन पहुँच दोस्रो शिकार हो। राउटरबाट उत्पन्न प्रशासनिक सत्रहरू, वा तिनका जवाफहरू, धेरै फराकिलो स्थानीय नियमले टनेलमा तानिन सक्छन् र LAN बाट पुग्न नसकिने हुन सक्छन्।

टनेलको अन्त्य बिन्दुलाई मिलानबाट बाहिर राख्नुहोस्, र नियमलाई रिजोल्भर ठेगानामा सीमित राख्नुहोस्। त्यो DNS आवश्यकताका लागि पर्याप्त छ र यसबारे सोच्न पर्याप्त सानो छ।

एउटा होइन, दुवै जनसंख्याको परीक्षण गर्नुहोस्

राउटरले आफ्नै क्वेरी गरेको हेर्नुहोस् र कुन इन्टरफेसले बोकेको थियो नोट गर्नुहोस्। LAN होस्टबाट लुकअप दोहोर्याउनुहोस् र यसले लिएको मार्ग नोट गर्नुहोस्। नीति नियमका काउन्टरहरूले अनुमान नगरी दुवै जवाफ देखाउँछन्।

नतिजालाई दुई अलग खोजका रूपमा लिनुहोस्। टनेलबाट समाधान गर्ने क्लाइन्टले राउटरबारे केही भन्दैन, र ठीकसँग समाधान गर्ने राउटरले अर्को श्रोतामा रहेको क्लाइन्टबारे केही भन्दैन। तिनलाई परिवर्तन रेकर्डमा अलग पङ्क्तिका रूपमा लेख्नुहोस्।

पोर्ट पनि जाँच्नुहोस्: गन्तव्य पोर्ट 53 सँग मिल्ने नियमले 853 मा DNS over TLS वा HTTPS अन्त्य बिन्दुबाट पुग्ने रिजोल्भर छुटाउँछ। कन्फिगर गरिएको upstream ले वास्तवमा प्रयोग गर्ने यातायातसँग मिलाउनुहोस्, र चुहावट सही कारणले बन्द हुन्छ।