OpenVPN प्रोफाइल घरमा किन काम गर्छ तर होटलमा असफल हुन्छ

अफिसको Wi-Fi र होटलको कोठाले एउटै ल्यापटपलाई दुई पूर्ण रूपमा फरक नेटवर्क दिन सक्छन्, र बीचको प्रोफाइललाई त्यसबारे केही थाहा छैन। घरमा काम गर्ने कुराले उदार अपलिंक, काम गर्ने नाम-समाधान र टनेलले बोक्ने कुनै पनि कुरासँग नटकराउने स्थानीय सबनेट मानेको हुन्छ। यी प्रत्येक अनुमान छुट्टै रूपमा असफल हुन सक्छ।

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

चार नेटवर्क तथ्य स्थानअनुसार फरक पर्छन्

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

दोस्रो नाम-समाधान हो। DNS अवरोध गर्ने पोर्टलले प्रत्येक प्रश्नको उत्तर आफ्नै ठेगानाले दिन्छ, त्यसैले VPN होस्टनेम पोर्टलमा समाधान हुन्छ र क्लाइन्ट वेब पृष्ठसम्म टनेल बनाउन प्रयास गर्छ।

तेस्रो यातायात फिल्टरिङ हो। ब्राउजिङमात्र अनुमति दिन चाहने नेटवर्कहरूले TCP 443 लाई जुनसुकै गन्तव्यमा जान दिन्छन् र UDP सहित लगभग सबै कुरा फ्याँक्छन्।

चौथो ठेगाना-विन्यास हो। स्थानीय सबनेट टनेलपछाडिको नेटवर्कसँग ओभरल्याप हुन सक्छ, वा अपलिंकले कुनै पनि उपयोगी IPv4 मार्ग दिँदैन।

नाम-समाधान र क्याप्टिभ पोर्टल

प्रोफाइलको होस्टनेम सर्भरको सङ्ख्यात्मक ठेगानाले बदलेर फेरि प्रयास गर्नुहोस्। IP जोडियो तर नाम जोडिएन भने दोष नाम-समाधानको हो, र प्रोफाइल आफै ठीक छ।

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

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

यातायात फिल्टरिङ: पहिले UDP, ब्याकअपका रूपमा TCP 443

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

TCP 443 विश्वसनीय ब्याकअप हो किनकि नेटवर्कले यसलाई सामान्य HTTPS बाट छुट्याउन सक्दैन। अपरेटरको TCP प्रोफाइल भए त्यही प्रयोग गर्नुहोस्, किनकि सर्भरले पनि त्यही यातायात र पोर्टमा सुन्नुपर्छ; क्लाइन्ट मात्र बदल्दा अर्को प्रकारको असफलता हुन्छ। TCP प्रोफाइल छैन भने पोर्ट सम्पादन गरेर नयाँ बनाउनुको सट्टा अपरेटरलाई सोध्नुहोस्। सर्भर पक्ष पनि सहमत हुनुपर्छ, र बेमेल फेरि फायरवाल समस्याजस्तै देखिन्छ।

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

ठेगाना ठोक्किने समस्या र IPv4 नभएका अपलिंक

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

स्थायी समाधान टाढाको LAN लाई असामान्य निजी दायरामा सार्नु हो। घरमा कसैले प्रयोग नगर्ने दायरा छान्ने, जस्तै 10.42.0.0/24, ले समस्या एउटाको सट्टा हरेक भावी स्थानका लागि रोक्छ। स्थानीय उपाय त्यो होटल, हटस्पट वा राउटरबाट बच्नु हो, जुन समाधान नै होइन।

मोबाइल अपलिंकले दुई भिन्नता थप्छ। क्यारियर-ग्रेड NAT भनेको भित्र आउने जडान पुग्दैन भन्ने हो, जुन सर्भर होस्ट गर्दा महत्त्वपूर्ण हुन्छ तर बाहिर जाने क्लाइन्टका लागि होइन। NAT64 अनुवादसहित IPv6 मात्र भनी मिलाइएको APN ले वास्तविक IPv4 मार्गमा जोड दिने क्लाइन्टलाई असफल बनाउन सक्छ, र सामान्य उपचार APN प्रोटोकल IPv4 वा दोहोरो स्ट्याकमा बदल्नु हो।

टनेल उठेपछिका लक्षण

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

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