VPN कनेक्ट आहे पण इंटरनेट नाही? चार थर तपासा

क्लायंट कनेक्ट आहे असे सांगतो, ब्राउझर फिरतो, आणि प्रत्येक साइट टाइमआउटवर संपते. हे संयोजन सामान्य आहे आणि विरोधाभास नाही: कनेक्ट म्हणजे टनेलने बोलणी केली, इतकेच. नाव विश्लेषण, राउटिंग आणि सर्व्हरचा स्वतःचा एग्झिट प्रत्येक आपल्या पद्धतीने अयशस्वी होतो, आणि प्रत्येकाचा वेगळा मालक आहे. थर क्रमाने तपासा आणि पहिला अयशस्वी होणाऱ्यावर थांबा.

ज्या नेटवर्कवरून आला तिथून सुरुवात करा

क्लायंटच्या स्वतःच्या डिस्कनेक्ट नियंत्रणाने टनेल खाली उतरवा, नंतर धोरण परवानगी देत असेल तर दोन असंबद्ध 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 वर रहा. दोन्हीपैकी एकही चालले नाही तर राउट टेबलची टनेलच्या अपेक्षित डीफॉल्टशी तुलना करा, आणि तुम्ही खरोखर जे कुटुंब तपासत आहात ते पहा. राउट बरोबर असूनही विनंती अजूनही एग्झिटवर मरत असेल तर उरलेला प्रश्न ऑपरेटरचा आहे, आणि तुम्ही ठेवलेला पुरावा हेच तिकीट आहे.