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