VPN मा आन्तरिक नामहरू असफल हुन्छन् तर सार्वजनिक साइटहरू राम्ररी खुल्छन्

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

एउटै गडबडी नभएका दुई लक्षण

आन्तरिक नाम समाधान नहुनुको अर्थ प्रश्न त्यहाँ पुग्यो जहाँ त्यसको जवाफ छैन। सुरुङबाट बाहिर जाने क्वेरीको अर्थ जवाफ उपलब्ध हुँदा पनि प्रश्न गलत ठाउँमा पुग्यो। ती विपरीत गडबडी हुन्: एउटा छुटेको जवाफ हो, अर्को थप गन्तव्य।

जाल यो हो कि जताततै कार्यालयको रिजोल्भर थप्दा पहिलो ठीक हुन्छ र दोस्रो निश्चित हुन्छ। जताततै सार्वजनिक रिजोल्भर थप्दा उल्टो हुन्छ।

दुवै अवलोकन समयछापसहित लेख्नुहोस्, त्यसपछि तलका चार जाँच क्रममा गर्नुहोस्।

कुन एडाप्टरको रिजोल्भरले प्रश्न पाउँछ

Windows मा DNS क्लाइन्टले एडाप्टर बाइन्डिङ क्रमअनुसार सर्भर छान्छ, र सुरुङ एडाप्टर स्वतः पहिलो हुँदैन। एडाप्टरको उन्नत सेटिङ खोल्नुहोस् र रिमोट एक्सेस जडानलाई भौतिक एडाप्टरभन्दा माथि सार्नुहोस्, त्यसपछि पुनः जडान गर्नुहोस् ताकि परिवर्तन नयाँ सत्रमा लागू होस्।

बाइन्डिङ क्रम आधा मात्र हो। क्लाइन्टले कुन नामहरू त्यो एडाप्टरका हुन् भन्ने पनि जान्नुपर्छ, र त्यो क्रमको प्रश्न नभई सुफिक्सको प्रश्न हो।

चलिरहेको मेसिनको ipconfig /all लाई ल्यापटपको छेउमा राख्नुहोस्, दुवै सुरुङ खुला हुँदा लिइएका। चलिरहेको मेसिनले आफ्नो कार्यालय एडाप्टरमा जडान-विशिष्ट DNS सुफिक्स देखाउँछ, र ल्यापटपले सुरुङमा कुनै नदेखाउन सक्छ। त्यो भिन्नताले सर्भर त्यहीँ छ तर नाम अझै असफल हुन्छ भन्ने रिपोर्टहरूको एउटा पूरा वर्ग व्याख्या गर्छ, किनभने सुफिक्स बिना छोटो नाम कार्यालय रिजोल्भरले सेवा गर्ने जोनमा कहिल्यै पूरा हुँदैन।

छोटो नामलाई रुटभन्दा पहिले सुफिक्स चाहिन्छ

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

चलिरहेको मेसिनको सुफिक्स DNS ट्याबमा VPN एडाप्टरको IPv4 गुणहरूमा प्रतिलिपि गर्नुहोस्, त्यसपछि पुनः जडान गर्नुहोस्। Linux मा यसको समानान्तर सुरुङ लिंकको खोज डोमेन हो, जुन systemd-resolved ले विश्वव्यापी होइन, प्रत्येक लिंकका लागि देखाउँछ।

दुई सेटिङ आफ्ना टिप्पणीहरूमा अलग राख्नुहोस्। सुफिक्सले के सोधिन्छ भन्ने बदल्छ; रिजोल्भर ठेगानाले कोसँग सोधिन्छ भन्ने बदल्छ। एउटा ठीक गर्दा अर्को गलत भयो भने नतिजा अनियमित देखिन्छ।

पहिले रिजोल्भरलाई सिधै सोध्नुहोस्, त्यसपछि नाम

कार्यालय रिजोल्भरमा सिधा क्वेरी ले नामको समस्यालाई मार्गको समस्याबाट अलग गर्छ, किनभने यसले क्लाइन्टको रिजोल्भर छनोटलाई पूर्ण रूपमा बाइपास गर्छ।

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

पहिलो आदेशले विशेष सर्भरसँग पूर्ण योग्य नाम माग्छ। यदि यसले जवाफ दिन्छ भने रिजोल्भर र त्यहाँसम्मको रुट ठीक छन् र गडबडी छनोट वा सुफिक्समा छ। यदि समय सकिन्छ भने ठेगाना गलत वा पुग्न नसकिने छ र समस्या DNS होइन, राउटिङ हो। दोस्रो आदेशले छोटो नामसँग के हुन्छ देखाउँछ, र तेस्रोले systemd होस्टमा प्रत्येक लिंकको रिजोल्भर कन्फिगरेसन देखाउँछ।

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

Linux मा /etc/resolv.conf पुनःलेखन गर्ने VPN क्लाइन्टले स्थानीय रिजोल्भरहरू पूर्ण रूपमा प्रतिस्थापन गर्छ। vpnc ले त्यो रोक्न DNSUpdate no दिन्छ, र systemd-resolved ले सूचीबद्ध डोमेनहरू मात्र सुरुङ लिंकमा रुट गर्न सक्छ। दुवै दृष्टिकोणले सार्वजनिक नामहरू स्थानीय रिजोल्भरमा राख्छन् भने आन्तरिक नामहरू कार्यालयमा पठाउँछन्।

लिकहरू नियम हुन्, चेकबक्स होइनन्

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

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

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

त्यो अन्तिम भाग देखिन्छ भन्दा बढी महत्त्वपूर्ण छ। route-nopull सहित OpenVPN सुरु गर्नुहोस् र पुश गरिएको DNS विकल्प रुटहरूसँगै हराउँछ, जबसम्म पुल फिल्टरलाई त्यो राख्न फराकिलो बनाइएन। dhcp-option DNS बेवास्ता गर्ने क्लाइन्टले पहिले जे थियो त्यही प्रयोग गरिरहन्छ। सर्भर पक्षको कुनै पनि परिवर्तनलाई प्रभाव पार्न नयाँ सत्र चाहिन्छ, किनभने रिजोल्भर सूची सुरुङ खुल्दा दिइन्छ र पुरानो सत्रले पुरानै अवस्था देखाइरहन्छ।

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