VPN पोर्ट 53 मा अवरुद्ध छ भन्ने रिपोर्टहरूले फरक-फरक कारणले असफल हुने तीन अवलोकनहरू मिसाउँछन्। इन्डपोइन्टको नाम समाधान कुनै टनेल बन्नुअघि हुन्छ, इन्क्रिप्टेड ट्रान्सपोर्ट छुट्टै कुराकानी हो, र त्यसपछि गरिने DNS प्रश्नहरू तेस्रो हो। प्रत्येकको आफ्नै असफलताको चिन्ह छ, र तीमध्ये एउटा मात्र DNS सँग सम्बन्धित छ।

केही बदल्नुअघि प्याकेटहरूलाई उद्देश्यअनुसार छुट्याउनुहोस्, किनकि समाधान चरणलाई पछ्याउँछ।

तीन कुराकानी, एउटा पोर्ट नम्बर

पहिलो कुराकानी इन्डपोइन्टका लागि नाम खोज हो: तपाईंको मेसिनले आफ्नो कन्फिगर गरिएको रिजोल्भरलाई vpn.example.com कहाँ छ भनेर सोध्छ, र त्यो उत्तर क्लाइन्टले एउटै टनेल प्याकेट पठाउनुअघि सामान्य DNS मार्फत आउँछ। दोस्रो OpenVPN ट्रान्सपोर्ट आफै हो, जसले खोजले दिएको ठेगानामा प्रोफाइलले भनेको प्रोटोकल र पोर्टमा जोडिन्छ। तेस्रो टनेल उठेपछि हुन्छ, जब एप्लिकेसनहरू नाम माग्छन् र पठाइएका रिजोल्भर सेटिङहरूले कसले जवाफ दिने निर्धारण गर्छन्।

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

ConversationWhen it happensWhat has to be true
Endpoint lookupBefore the client contacts a hostnameAn underlying resolver path can answer for the endpoint name
OpenVPN transportDuring tunnel establishmentThe gateway listens on its configured transport, address and port, and nothing filters it
Application DNSDuring or after the protected sessionA resolver the client can reach, plus routing that carries its queries

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

पोर्ट नम्बरले एप्लिकेसनको नाम दिँदैन

पोर्ट 53 ले परम्पराअनुसार DNS बोक्छ, र OpenVPN अपरेटरले त्यहाँ श्रोता पनि प्रकाशित गर्न सक्छ, त्यसैले यो नम्बर कमजोर पहिचान हो। UDP 53 मा OpenVPN सत्र अझै OpenVPN सत्र हो, र पोर्ट 53 को सर्भरमा गरिएको DNS प्रश्नले टनेललाई अनुमति छ कि छैन भन्नेबारे केही भन्दैन। प्रोफाइलका proto र remote लाइनहरूले बाह्य इन्डपोइन्ट परिभाषित गर्छन्; पोर्ट नम्बर आफैले केही परिभाषित गर्दैन।

निदान गर्दा यो दुवैतर्फ लागू हुन्छ: पोर्ट 53 मा सामान्य UDP परीक्षणले पोर्टले जवाफ दिन्छ भनी प्रमाणित गर्छ, VPN सेवाले जवाफ दिन्छ भनेर होइन। वास्तविक क्लाइन्ट र वास्तविक प्रोफाइलसँग परीक्षण गर्नुहोस्, किनकि सेवाले अपेक्षा गर्ने ह्यान्डशेक अभ्यास गर्ने त्यही मात्र हो।

नेटवर्कलाई दोष दिनुअघि श्रोता प्रमाणित गर्नुहोस्

सर्भरमा ss -lunp | grep 53 प्रयोग गरी के बाँधिएको छ जाँच्नुहोस् र प्रोफाइलको प्रोटोकल र पोर्टसँग तुलना गर्नुहोस्। क्लाइन्टको नेटवर्कबाट, क्लाइन्टलाई बढी विवरणसहित चलाउनुहोस् ताकि लगले कुन ठेगाना र ट्रान्सपोर्ट प्रयास गर्यो देखाओस्। यदि सर्भर सुनिरहेको छ र क्लाइन्टका प्याकेट आइपुग्दैनन् भने मार्ग वा नीतिले तिनलाई अस्वीकार गरिरहेको छ, र त्यो नेटवर्क मालिकसँगको कुराकानी हो, पोर्ट बदल्ने कारण होइन।

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

टनेलपछि DNS छुट्टै जाँच्नुहोस्

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

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

सम्बन्धित लेखहरू