VPN कनेक्शन टाइमआउट: DNS, वाहतूक, बोलणी की लॉगिन
टाइमआउट म्हणजे फक्त एक मुदत संपली. चार टप्पे, नाव निराकरण, वाहतूक, बोलणी आणि लॉगिन, यांची तुलना करा की कोणता शेवटी पूर्ण झाला.
“कनेक्शनची वेळ संपली” ही VPN क्लायंट छापू शकणारी सर्वात अस्पष्ट त्रुटी आहे. याचा अर्थ एक क्रिया तिची मुदत चुकली, आणि नाव निराकरणापासून लॉगिनच्या उत्तरापर्यंत प्रत्येक टप्प्याला मुदत असते. फक्त अंतिम संदेश दाखवणारे क्लायंट टप्प्यांना एकसारखे दिसू लागतात, म्हणून लोक वेळमर्यादा वाढवतात, पोर्ट बदलतात आणि प्रोफाइल पुन्हा स्थापित करतात, त्याच क्रमाने, काहीही न शिकता. टप्पे तुलना करणे जलद आहे: प्रत्येक वेगळ्या ठिकाणी अयशस्वी होतो, आणि प्रत्येक अयशस्वीता वेगळ्या प्रकारचा पुरावा सोडते.
चार टप्पे, चार वेगळ्या अयशस्वीता
क्लायंट तो लपवला तरी क्रम निश्चित आहे: नाव निराकरणे आवश्यक, परिणामी पत्त्यापर्यंत वाहतूक प्रस्थापित करावी लागते, प्रोटोकॉलने त्याचे मापदंड आणि किल्ल्या बोलणी करावी लागते, आणि खाते प्रमाणित व्हावे लागते. OpenVPN चे कनेक्टिव्हिटी समस्या निवारण मार्गदर्शक त्याच्या स्वतःच्या क्लायंटसाठी तोच क्रम अनुसरते, आणि इतर ते जवळून अनुसरतात. दुसऱ्या टप्प्यातील टाइमआउट आणि चौथ्या टप्प्यातील टाइमआउट यांना स्क्रीनवरील शब्दाशिवाय काहीही सामायिक नाही.
| Stage | Looks like | What it does not prove |
|---|---|---|
| Name resolution | fails in under a second, before any contact | nothing about the server being up |
| Transport | waits the full timeout, then gives up | nothing about the VPN service behind the port |
| Negotiation | connects, then stalls at handshake | nothing about credentials |
| Login | a reply arrives and is rejected or hangs on a prompt | nothing about reachability |
लॉगमध्ये त्रुटीच्या आधीची शेवटची ओळ नाही, तर प्रगती दर्शवणारी शेवटची ओळ वाचा. बहुतेक क्लायंट निराकरण केलेला पत्ता, प्रस्थापित सॉकेट, सुरू झालेला हॅंडशेक किंवा प्रमाणीकरण विनंती असे काहीतरी छापतात, आणि त्या ओळीनंतरचा टप्पा हाच वेळ संपलेला टप्पा असतो.
कोणत्याही संपर्कापूर्वी नाव निराकरण अयशस्वी होते
जर एंडपॉइंट कधीच निराकरण झाला नाही, तर क्लायंटकडे जोडण्यासाठी काहीही नाही आणि कोणतेही वाहतूक कार्य झाले नाही. ती अयशस्वीता सहसा पूर्ण टाइमआउट नसून तात्काळ असते, आणि ती बाकीच्यांपासून वेगळी करण्याचा सर्वात स्वस्त मार्ग आहे. नाव सिस्टम रिझॉल्व्हर आणि दुसऱ्या रिझॉल्व्हरने तपासा, आणि सर्व्हर बंद आहे असा निष्कर्ष काढण्यापूर्वी दोन्ही उत्तरांची तुलना करा.
फोरम पोस्टमधून कॉपी केलेला जुना पत्ता सर्व्हर समस्येसारखा दिसणाऱ्या टाइमआउटचे सामान्य कारण आहे, कारण पत्ता आता दुसऱ्या कशाचा आहे किंवा कशाचाही नाही. आधी काम करणारा पत्ता बदलण्याऐवजी ऑपरेटरचे सध्याचे प्रोफाइल वापरा. ping चे उत्तर न मिळणे कोणत्याही दिशेने पुरावा नाही: अनेक एंडपॉइंट ICMP टाकून देतात आणि तरीही उत्तम सेवा देतात.
वाहतूक सेटअप न येणाऱ्या पॅकेटची वाट पाहतो
DNS ठीक असताना क्लायंट तरीही संपूर्ण वेळमर्यादा जाळत असेल, तर वाहतूक स्तर संशयित आहे. TCP वर तुम्ही पोर्ट थेट तपासू शकता; Test-NetConnection Windows वर किंवा nc -vz Linux वर काहीतरी कनेक्शन स्वीकारते का ते सांगते, आणि ते ping पेक्षा उपयुक्त आहे. UDP वर त्याच पद्धतीने तपासता येत नाही, कारण त्या स्तरावर पूर्ण करण्यासाठी हॅंडशेक नाही, आणि ही विषमता भरपूर चुकीचे निष्कर्ष निर्माण करते.
TCP चाचणी जे सिद्ध करते ते मर्यादित आहे: 443 पोर्ट स्वीकारणारी सेवा VPN श्रोता असेलच असे नाही, आणि फक्त-UDP एंडपॉइंटकडे काहीही स्वीकारण्यासाठी TCP पोर्ट नाही. प्रोफाइल UDP वरून TCP वर पुन्हा लिहिल्याने दुसऱ्या बाजूला श्रोता तयार होत नाही; तुमचा क्लायंट कशाची वाट पाहतो तेच फक्त बदलते. नेटवर्कने प्रोटोकॉल गाळला तर बदल त्याच टप्प्यात वेगळा टाइमआउट निर्माण करतो.
कॅप्टिव्ह पोर्टल या टप्प्यात स्वतःच्या तपासणीला पात्र आहेत. जोपर्यंत पोर्टल डिव्हाइसला अधिकृत करत नाही, तोपर्यंत बाहेर जाणारी रहदारी पोर्टलकडे जाते आणि टनेलचा प्रयत्न फक्त लटकत राहतो. आधी ब्राउझरमध्ये पोर्टल पूर्ण करा, मग पुन्हा प्रयत्न करा, आणि पोर्टल प्रलंबित असताना प्रोफाइल बदलू नका.
बोलणी आणि लॉगिन म्हणजे सर्व्हरने उत्तर दिले
टनेल सर्व्हरपर्यंत पोहोचताच क्लायंट हॅंडशेक सुरू करतो आणि त्रुटीचे स्वरूप बदलते. इथे थांबणे पोहोचण्याबद्दल नसून सुसंगततेबद्दल आहे: न जुळणारी प्रोटोकॉल आवृत्ती, दुसरी बाजू स्वीकारणार नाही असे सायफर किंवा डेटा-चॅनेल सेटिंग, किंवा सर्व्हर देत नाही अशा वैशिष्ट्याची अपेक्षा करणारे प्रोफाइल. OpenVPN ने आपल्या बोलणीचे डीफॉल्ट मुख्य आवृत्त्यांदरम्यान इतक्या वेळा हलवले की एका पिढीसाठी लिहिलेले प्रोफाइल सर्व्हरपर्यंत पोहोचूनही वर येऊ शकत नाही.
प्रमाणीकरण हा शेवटचा टप्पा आहे आणि चुकीचे वाचणे सर्वात सोपे. स्पष्ट नकार हे उत्तर आहे, म्हणजे मार्ग काम करतो आणि समस्या ओळख, प्रमाणपत्र किंवा खात्याच्या स्थितीत आहे. ब्राउझर-आधारित एकल साइन-ऑन प्रवाह तिसरी स्थिती आहे: क्लायंट तुम्ही न केलेल्या कृतीची किंवा सुरू करू न शकणाऱ्या ब्राउझरची वाट पाहत आहे, आणि तो टप्पा पूर्ण करेपर्यंत काहीही येणार नाही.
पुन्हा प्रयत्न बदलण्यापूर्वी पुराव्याची तुलना करा
डिव्हाइस आणि प्रोफाइल स्थिर ठेवा आणि एका वेळी एक गोष्ट बदला, नेटवर्कपासून सुरुवात करून. जर तेच प्रोफाइल फोन हॉटस्पॉटवर जोडले जाते आणि हॉटेल Wi-Fi वर टाइमआउट होते, तर चल सर्व्हर नाही, मार्ग आहे. जर ते सर्वत्र अयशस्वी होते, तर चल प्रोफाइल किंवा एंडपॉइंट आहे. जर ते दिवसाच्या एका विशिष्ट वेळीच अयशस्वी होते, तर वेळेची नोंद घ्या आणि लोडबद्दल काही गृहीत धरण्यापूर्वी सर्व्हर-बाजूच्या घटनांशी त्याची तुलना करा.
तुम्ही व्यवस्थापित करता त्या सेवेसाठी निर्णायक तुलना म्हणजे प्रयत्न अखेर पोहोचतो का. श्रोत्यापर्यंत पोहोचून नंतर थांबणारे कनेक्शन बोलणी टप्प्यातील आहे; श्रोत्याच्या दृष्टीत कधीच न दिसणारे वाहतूक किंवा निराकरणाची समस्या आहे, आणि पुन्हा प्रयत्नाचे कोणतेही ट्यूनिंग ते हलवणार नाही. सर्व्हर लॉग नाकारलेले लॉगिन शांत टाकून देण्यापासून वेगळे करतात, जे ओळख सुधारणा आणि फायरवॉल सुधारणा यांतील फरक आहे.
क्लायंट आवृत्ती, प्रोफाइलचे नाव, टाइम झोनसह प्रयत्नाची वेळ आणि शेवटच्या डिस्कनेक्ट ओळीऐवजी पहिली उपयुक्त त्रुटी नोंदवा. उतारा सामायिक करण्यापूर्वी किल्ल्या आणि क्रेडेन्शियल असलेली सामग्री काढा. नंतर एक अर्थपूर्ण दुरुस्ती करा आणि पुन्हा प्रयत्न करा, कारण लांब मुदत फक्त दस्तऐवजीकृत संथ क्रियेला मदत करते आणि चुकीच्या पत्त्यासाठी किंवा अवरोधित पोर्टसाठी काहीही करत नाही.