VPN जोडिएको छ तर इन्टरनेट छैन? चार तह जाँच्नुहोस्
हरियो सूचकले टनेल माथि आयो भन्ने मात्र बुझाउँछ। पहिले पहुँच सञ्जाल, DNS, प्रोफाइलको उद्देश्य र सर्भरको निकास जाँच्नुहोस्।
क्लाइन्ट जोडिएको भन्छ, ब्राउजर घुम्छ, र हरेक साइट समय सकिएर अन्त्य हुन्छ। यो संयोजन सामान्य छ र विरोधाभास होइन: जोडिएको भन्नाले टनेलले वार्ता गर्यो, त्यसभन्दा बढी होइन। नाम समाधान, राउटिङ र सर्भरको आफ्नै निकास प्रत्येक आफ्नै तरिकाले असफल हुन्छ, र प्रत्येकको फरक मालिक हुन्छ। तहहरू क्रममा जाँच्नुहोस् र पहिलो असफल हुनेमा रोक्नुहोस्।
तपाईं आएको सञ्जालबाट सुरु गर्नुहोस्
क्लाइन्टको आफ्नै डिस्कनेक्ट नियन्त्रणले टनेल तल झार्नुहोस्, त्यसपछि नीतिले अनुमति दिए दुई असम्बन्धित HTTPS साइट प्रयास गर्नुहोस्। त्यो परीक्षणको अवधिभर संवेदनशील काम बन्द राख्नुहोस्। सामान्य पहुँच पनि असफल भयो भने VPN पहिलो शंकास्पद होइन।
टनेल छुनुअघि Wi-Fi लिंक, राउटर र लगइन माग्ने कुनै पनि पोर्टल पृष्ठ हेर्नुहोस्। किल स्विचले डिजाइनअनुसार डिस्कनेक्ट हुँदा ट्राफिक रोक्न सक्छ, त्यसैले सञ्जाल मर्यो भनी ठान्नुको सट्टा त्यसको अभिलेखित परीक्षण प्रक्रिया पालना गर्नुहोस्। अर्को विश्वसनीय सञ्जाल उपयोगी तुलना हो, र नयाँ VPN निकासले म्याद सकिएको होटल लगइन पूरा गर्दैन। खुला सञ्जाल चल्यो र टनेल चलेन भने सञ्जाल निर्दोष छ र अर्को तह तपाईंको हो।
असफलता नाम समाधानको हो कि होइन निर्णय गर्नुहोस्
त्रुटिको पाठ लेख्नुहोस्, किनकि समाधान असफलता, समय सकिनु र प्रमाणपत्र चेतावनी प्रत्येकले फरक ठाउँ देखाउँछ। चाँडै समात्नुपर्ने ढाँचा भनेको कहिल्यै नदेखेको होस्टनाम असफल हुनु हो, जबकि खुला सत्रको एप चलिरहन्छ। यो ढाँचा नयाँ खोजीबारे हो, टनेलले प्याकेट बोक्छ कि बोक्दैन भन्नेबारे होइन। एउटा खोजीले रिजोल्भर के फर्काउँछ देखाउँछ, र चलाउन एक सेकेन्ड लाग्छ। दोस्रो नाम पनि प्रयास गर्नुहोस्, ताकि एउटा क्यास गरिएको उत्तर वा एउटा बिग्रिएको रेकर्डले निदान तय नगरोस्।
nslookup example.com
HTTPS ठेगाना पट्टीमा जथाभावी IP DNS परीक्षण होइन, किनकि प्रमाणपत्र र भर्चुअल होस्ट सामान्यतया नाममा निर्भर हुन्छन्। आन्तरिक नामलाई सार्वजनिक विकल्पको सट्टा संस्थाको रिजोल्भर चाहिन सक्छ, र आफ्नै सुरक्षित रिजोल्भर भएको ब्राउजरले अपरेटिङ सिस्टमको खोजीभन्दा फरक उत्तर दिन सक्छ। दुवै फरक हुँदा प्रयोगकर्ताले अनुभव गर्ने ब्राउजरको रिजोल्भर हो, र त्यो भिन्नता टिकटको हो।
पूर्ण टनेल कि कम्पनी सबनेट मात्र
केही प्रोफाइल कम्पनीका केही सबनेटमा पुग्न मात्र हुन्छन्; अरू सबै बोक्न बनाइएका हुन्छन् र तिनका पछाडि चल्ने निकास चाहिन्छ। सूचकले हरेक एप र हरेक ठेगाना परिवार ढाक्छ भनी मान्नुअघि अभिलेखित उद्देश्य पढ्नुहोस्। निजी सञ्जाल प्रोफाइल ठ्याक्कै डिजाइनअनुसार चल्न सक्छ, जबकि त्यो प्रयोग गर्नै नपर्ने ब्राउजर अझै असफल हुन्छ। राउट तालिका नबदली पढ्नुहोस्, र IPv6 समावेश गर्नुहोस्, किनकि चल्ने IPv4 मार्गले अर्को परिवारबारे केही भन्दैन।
अझ विशिष्ट राउटले पूर्वनिर्धारित राउट हुँदाहुँदै जित्न सक्छ, त्यसैले तालिका अनुमान नगरी पढ्नुपर्छ। प्रतिस्पर्धी भर्चुअल एडाप्टरले पनि तपाईंले अन्त कतै अपेक्षा गरेको ट्राफिक राख्न सक्छन्, विशेषगरी दोस्रो VPN क्लाइन्ट स्थापना गरी बिर्सिएपछि। प्रयोगका रूपमा पूर्वनिर्धारित राउट नमेट्नुहोस्; त्यसले निदानलाई दोस्रो अवरोध बनाउँछ।
चल्ने साइटहरूमध्ये एउटा असफल साइट त्यो साइटको समस्या हो, र यसले टनेलले ट्राफिक बोकिरहेको पनि प्रमाणित गर्छ। ठूला स्थानान्तरणमा मात्र देखिने अड्कावले पहुँचलाई होइन, प्याकेट आकारलाई संकेत गर्छ।
सर्भरले कहिल्यै केही फर्वार्ड नगर्दा
हरेक गन्तव्य दुई उपकरण र दुई पहुँच सञ्जालमा असफल भयो भने, टनेल माथि छ र निकास फर्वार्ड गर्दैन। यही जोडीले सर्भर-पक्षको असफलतालाई एकै ठाउँमा गलत कन्फिगर गरिएको एक उपकरणबाट छुट्याउँछ। अपरेटरलाई सूचकको स्क्रिनसट होइन, फर्वार्डिङ, NAT र फिर्ती मार्गका प्रश्न पठाउनुहोस्।
ती तीनले सर्भर-पक्षका अधिकांश कारण ढाक्छन्, र जवाफ दिने काम अपरेटरको हो। OpenVPN जडान समस्या समाधान पृष्ठ मा सर्भरको पक्षबाट तीही प्रश्नहरू छन्, त्यसैले त्यो टिकटसँगै दिनुहोस्। हरियो सूचकको स्क्रिनसटले तीमध्ये कुनैको जवाफ दिँदैन।
लगइनपछिको क्लाइन्ट लगमा राउट, DNS सेटिङ वा भर्चुअल एडाप्टर लागू गर्ने असफलता खोज्नुहोस्। त्यो चरणका त्रुटिले सर्भर होइन, उपकरण देखाउँछन्। लगमा कहिल्यै नदेखिने त्रुटि पनि त्यत्तिकै जानकारीपूर्ण हुन्छ, किनकि यसले शंकालाई अर्को पट्टि सार्छ।
एकपटकमा एउटा तह जाँच्नुहोस्
केही बदलेपछि फेरि जोडिनुहोस् र असफल भएको त्यही एप दोहोर्याउनुहोस्। एउटा पृष्ठ लोड हुनु प्रोफाइल जसका लागि बनाइयो ती स्रोतसम्मको दोहोर्याउन सकिने मार्गभन्दा कम प्रमाण हो। दुई आदेशले समाधानलाई पहुँचबाट छुट्याउँछन्, र दोस्रो होस्ट-विशिष्ट हुन्छ। curl लाइन जहाँ पनि चलाउनुहोस्, त्यसपछि तपाईंको अगाडिको होस्टसँग मिल्ने राउट आदेश चलाउनुहोस्।
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4 # Windows
ip -4 route show # Linux
netstat -rn | head # macOS
सङ्ख्यात्मक अनुरोध चल्यो र नाम चलेन भने DNS मा रहनुहोस्। दुवैमध्ये कुनै पनि नचले राउट तालिकालाई टनेलको अपेक्षित पूर्वनिर्धारितसँग तुलना गर्नुहोस्, र तपाईंले साँच्चै परीक्षण गरिरहेको परिवार जाँच्नुहोस्। राउट ठीक भए पनि अनुरोध अझै निकासमा मर्छ भने बाँकी प्रश्न अपरेटरको हो, र तपाईंले राखेको प्रमाण नै टिकट हो।