निजी DNS नामहरू VPN क्लाइन्टमा किन असफल हुन्छन् र कहाँ जाँच्ने

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

कुनै पनि प्रोफाइल सम्पादन गर्नुअघि क्लाइन्टले नामसँग के गर्छ भनी पुष्टि गर्नुहोस्। Linux मा resolvectl query files.corp.example ले कुन लिङ्क र कुन रिजोल्भरले उत्तर बनाए भनी देखाउँछ। Windows मा Resolve-DnsName files.corp.example ले जवाफ दिने सर्भर र फर्काइएको ठेगाना देखाउँछ।

केही बदल्नुअघि उत्तर पढ्नुहोस्

नाम केही मिलिसेकेन्डमा NXDOMAIN को रूपमा फर्केर आयो भने प्रश्न कहिल्यै तपाईंको जोनसम्म पुगेन र कुनै सार्वजनिक वा होटेल रिजोल्भरले जवाफ दियो। लामो विरामपछि फर्केर आयो भने बाटोमा केहीले UDP पोर्ट 53 फालिरहेको छ र क्लाइन्ट अन्ततः विकल्पमा झर्यो। सही ठेगानासहित जवाफ दिन्छ तर जडान अझै अड्किन्छ भने खोज ठीक छ र तपाईंको समस्या मार्गनिर्देशनमा वा सेवामै छ।

यो तीन भागको विभाजनले एक घण्टाको अनुमान बचाउँछ। यसले VPN लाई छुनु पर्छ कि पर्दैन पनि बताउँछ: सही निजी ठेगानामा हल हुने नामले रिजोल्भरको बाटो पहिले नै प्रमाणित गरिसकेको छ, त्यसैले बाँकी काम डेटाको बाटोमा छ।

रिजोल्भर सुरुङभित्रबाट बाँड्नुहोस्

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

OpenVPN पहिलो समूहमा छ। सर्भरमा push "dhcp-option DNS 10.8.0.53" र push "dhcp-option DOMAIN corp.example" नियन्त्रण च्यानलबाट तल जान्छन्, तर तब मात्र जब क्लाइन्टको कन्फिगरेसनमा pull अझै सक्रिय छ। हातले सम्पादन गरिएको र pull-filter ignore "dhcp-option" बोकेको क्लाइन्टले ती कहिल्यै देख्ने छैन, र त्यही एउटा लाइनले अचम्मलाग्दो धेरै यस्ता घटनाको व्याख्या गर्छ कि «सर्भरले धकेल्छ तर मेरो ल्यापटप मान्दैन»।

WireGuard दोस्रो समूहमा छ, किनकि प्रोटोकलमा विकल्पको कुनै वार्ता नै छैन। रिजोल्भर र खोज डोमेन क्लाइन्टको आफ्नै [Interface] ब्लकमा DNS = 10.8.0.53, corp.example को रूपमा जान्छन्। wg-quick ले त्यो resolvconf वा systemd-resolved मार्फत लागू गर्छ, र Windows मा आधिकारिक क्लाइन्टले NRPT का ती नियम स्थापना गर्छ जो सुरुङ उभिएसम्म मात्र हुन्छन्: Get-DnsClientNrptPolicy ले तिनलाई सूचीबद्ध गर्छ, जसले क्लाइन्टले तपाईंको फाइल कहिल्यै लागू गर्यो कि भनी हेर्ने छिटो तरिका बनाउँछ।

IPsec/IKEv2 बीचमा छ। strongSwan को attr प्लगइनले पोखरीबाट निकालेको DNS सर्भर फर्काउन सक्छ, र Windows क्लाइन्टले सामान्यतः स्वीकार गर्छ, तर आफ्नै नाम सर्भर जमाउने प्रोफाइलले गेटवेले दिने जे सुकैलाई जित्छ। Linux क्लाइन्टमा बराबरको हाते कदम resolvectl dns wg0 10.8.0.53 र त्यसपछि resolvectl domain wg0 '~corp.example' हो; दुवै इन्टरफेससँगै हराउँछन्, जुन सुरुङमा सीमित सेटिङका लागि ठ्याक्कै त्यही हो जुन तपाईं चाहनुहुन्छ।

हरेक प्रश्न निल्नुभन्दा प्रत्यय सीमित गर्नुहोस्

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

भित्र केवल निजी प्रत्यय पठाउनुहोस्। systemd-resolved मा ~ बाट सुरु हुने डोमेन केवल मार्गनिर्देशनका लागि हो, त्यसैले ~corp.example को अर्थ त्यो प्रत्ययमुनिका प्रश्न त्यही लिङ्कका सर्भरतिर जान्छन् जबकि बाँकी सबै भौतिक सञ्जाल प्रयोग गरिरहन्छ। Windows ले यही काम नामस्थानमा सीमित NRPT नियमले गर्छ, र macOS ले /etc/resolver/ मुनिको थप रिजोल्भर फाइलले।

मल्टिकास्ट नामहरू आफ्नै उत्तरका हकदार छन्। .local नामहरू रचनाले link-local हुन् (RFC 6762) र बिन्दु-देखि-बिन्दु tun इन्टरफेसले त्यो मल्टिकास्ट समूह बोक्दैन, त्यसैले सार्वजनिक रिजोल्भर थप्दा ती प्रकाशित हुँदैनन् र आन्तरिक unicast रिजोल्भरलाई तिनको बारेमा सोध्दा NXDOMAIN फर्कन्छ। avahi जस्तो परावर्तक परावर्तन मोडमा दुई खण्ड जोड्न सक्छ, तर त्यो सर्भर पक्षको निर्णय हो जुन कुनै क्लाइन्टले माग्न सक्दैन। यदि प्रिन्टर वा NAS नामले पहुँचयोग्य हुनैपर्ने हो भने, त्यसको सट्टा आफ्नो जोनमा त्यसलाई A रेकर्ड दिनुहोस्।

उत्तर फर्कन सक्छ भनी प्रमाणित गर्नुहोस्

पहुँच नहुने ठेगानातिर संकेत गर्ने सही उत्तर ठ्याक्कै रिजोल्भरको समस्याजस्तै देखिन्छ जबसम्म तपाईं मार्ग जाँच्नुहुन्न। कर्नेललाई सोध्नुहोस् उत्तर कहाँ जान्छ: ip route get 10.20.5.20 ले इन्टरफेस र अझ उपयोगी रूपमा त्यसले प्रयोग गर्ने स्रोत ठेगाना बताउँछ।

रिजोल्भरको ठेगानामै नजर राख्नुहोस्। जसको DNS = 10.8.0.53 सँगै AllowedIPs = 10.20.0.0/16 छ त्यस्तो क्लाइन्टले आफ्ना प्रश्न भौतिक NIC बाट बाहिर पठाउँछ, जहाँ ती चुपचाप मर्छन्, किनकि रिजोल्भर सुरुङले दाबी गर्ने कुनै पनि प्रिफिक्सभित्र छैन। यही असंगति यो सम्पूर्ण क्षेत्रमा सबैभन्दा सामान्य एक-कारण खराबी हो, र DNS सेटिङको अनुमत प्रिफिक्ससँग लाइन-दर-लाइन तुलना नगरेसम्म यो अदृश्य रहन्छ।

अतिव्यापी दायराले उल्टो खराबी ल्याउँछ। उत्तर सही छ, मार्ग अवस्थित छ, र त्यो गलत होस्टतिर संकेत गर्छ, किनकि घरमा 192.168.0.0/24 त्यही दायरातिर जाने सुरुङको मार्गभन्दा बढी विशिष्ट छ। एउटा पक्ष पुनः क्रमाङ्कन गर्नुहोस् वा साँघुरो मार्ग धकेल्नुहोस्, त्यसपछि सेवा होस्टको फायरवाल र फर्कने मार्ग पुष्टि गर्नुहोस्; strongSwan का अग्रेषण बारेका टिप्पणीले त्यो मार्गको sysctl पक्ष समेट्छन्।

प्रमाणपत्रहरू अलग पहिचान जाँच हुन् जसको दोष मानिसहरूले DNS मा लगाउँछन्। ब्राउजरले हल हुने त्रुटिको सट्टा नामको असंगति जनायो भने खोज पहिले नै चलेको छ र प्रमाणपत्रको SAN नै सुधार्नुपर्ने कुरा हो। HTTPS नाममा परीक्षण गर्नुहोस्, कहिल्यै नाङ्गो IP मा होइन।

गेटवेबाट होइन, क्लाइन्टबाट फेरि जाँच्नुहोस्

प्रयोगकर्ताले गुनासो गर्ने एपभित्रै जाँच्नुहोस्, किनकि कमाण्ड लाइनको खोजले ब्राउजर त्यही बाटो जान्छ भनी प्रमाणित गर्दैन। Chrome को सुरक्षित DNS र Firefox को network.trr.mode ले प्रणालीको रिजोल्भर पूरै बाइपास गर्न सक्छन्, र जब त्यसो गर्छन् तब निजी नाम या त असफल हुन्छ या सार्वजनिक रिजोल्भरतिर चुहिन्छ। resolvectl query लाई हातले चलाइएको dig @10.8.0.53 files.corp.example सँग तुलना गर्दा कुन भयो भन्ने थाहा हुन्छ।

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

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