DNS रिडिरेक्ट पछि dnsmasq क्वेरीहरू VPN बाट किन बाहिर जान्छन्

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

चिन्ह क्वेरीसँगै यात्रा गर्दैन

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

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

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

कहाँ अगाडि पठाउने काम स्थानीय समाधान बन्छ

पोर्ट 53 रिडिरेक्ट भइरहेको छ, अर्को होस्टमा अनुवाद भइरहेको छ, वा यथावत् राखिएको छ भनी पत्ता लगाएर सुरु गर्नुहोस्, किनकि तीनवटै अवस्था फरक व्यवहार गर्छन्। स्थानीय पोर्टमा रिडिरेक्टले अगाडि पठाउने काम अन्त्य गर्छ, तर अर्को मेसिनमा अनुवादले प्याकेट चलायमान राख्छ र क्लाइन्टको tuple अर्थपूर्ण राख्छ।

दुवै प्रोटोकल हेर्नुहोस्। 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 हो वा केवल भाग्यशाली भन्ने निर्णय गर्छ।