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 पर टाइमआउट होती है, तो चर सर्वर नहीं, मार्ग है। यदि वह हर जगह विफल होती है, तो चर प्रोफ़ाइल या एंडपॉइंट है। यदि वह दिन के किसी एक समय ही विफल होती है, तो समय-चिह्न दर्ज करें और लोड के बारे में कुछ मानने से पहले उसकी तुलना सर्वर-पक्ष की घटनाओं से करें।
आप जिस सेवा का प्रबंधन करते हैं, उसके लिए निर्णायक तुलना यह है कि प्रयास आख़िर पहुँचता है या नहीं। जो कनेक्शन श्रोता तक पहुँचकर फिर अटक जाता है वह बातचीत चरण का है; जो श्रोता की दृष्टि में कभी नहीं दिखता वह परिवहन या हल होने की समस्या है, और पुनः प्रयास का कोई भी ट्यूनिंग उसे नहीं हिलाएगा। सर्वर लॉग अस्वीकृत लॉगिन को शांत गिरावट से भी अलग करते हैं, जो पहचान सुधार और फ़ायरवॉल सुधार के बीच का अंतर है।
क्लाइंट संस्करण, प्रोफ़ाइल का नाम, समय क्षेत्र के साथ प्रयास का समय और अंतिम डिस्कनेक्ट पंक्ति के बजाय पहली उपयोगी त्रुटि दर्ज करें। अंश साझा करने से पहले कुंजियाँ और क्रेडेंशियल वाली सामग्री हटा दें। फिर एक अर्थपूर्ण सुधार करें और दोबारा प्रयास करें, क्योंकि लंबी समय-सीमा केवल दस्तावेज़ीकृत धीमी क्रिया की मदद करती है और गलत पते या अवरुद्ध पोर्ट के लिए कुछ नहीं करती।