यह सार्वजनिक VPN नोड वास्तव में कौन-से प्रोटोकॉल देता है?

सॉफ़्टवेयर इसका समर्थन करता है, इसलिए नोड इसे देता है। यह अनुमान इतनी बार गलत होता है कि एक नियम बन जाए: SoftEther परिनियोजन अपने संगत कनेक्शन तरीकों का कोई भी उपसमुच्चय सक्षम कर सकता है, और सार्वजनिक नोड एक ऐसा परिनियोजन है जिसका स्वामी और कॉन्फ़िगरेशन होता है। आप किससे जुड़ सकते हैं यह उस नोड पर निर्भर करता है, उस परियोजना की सुविधा-सूची पर नहीं जिसे वह चलाता है। इन दोनों के बीच का अंतर ही वह जगह है जहाँ ज़्यादातर “प्रोटोकॉल टूटा हुआ है” टिकट वास्तव में रहते हैं।

परियोजना की सूची वास्तव में क्या वादा करती है

परियोजना के प्रोटोकॉल फ़ंक्शन बताते हैं कि सर्वर क्या करने में सक्षम है। कोई दिया गया नोड उन श्रोताओं में से कुछ को सक्षम करता है और कुछ को नहीं, और ऑपरेटर सॉफ़्टवेयर संस्करण को छुए बिना वह समुच्चय बदल सकता है। इसलिए एक ही बिल्ड के दो नोड अलग व्यवहार करते हैं, और एक के विरुद्ध काम करने वाली प्रोफ़ाइल अगले लक्ष्य के बारे में कुछ सिद्ध नहीं करती। कहाँ जुड़ना है यह चुनते समय नोड की अपनी सूची परियोजना पृष्ठ से अधिक महत्व रखती है।

सूची को मेन्यू की तरह नहीं, पाँच क्षेत्रों की तरह पढ़ें: एंडपॉइंट, पोर्ट, परिवहन, प्रोटोकॉल परिवार और प्रमाणीकरण विधि। जो सार्वजनिक नोड SSTP का विज्ञापन करता है, उसने आपको पोर्ट पर एक श्रोता के बारे में बताया है; उसने यह नहीं बताया कि वह कौन-सा प्रमाणपत्र प्रस्तुत करता है या आपका खाता वहाँ काम करता है या नहीं। उन पाँच क्षेत्रों की अपनी प्रोफ़ाइल से तुलना करना क्लाइंट के किसी भी मात्रा में पुनःस्थापन से तेज़ है, और यह एक लिखित अपेक्षा बनाती है जिसे आप बाद में जाँच सकते हैं।

प्रोफ़ाइल को उसके द्वारा नामित एंडपॉइंट से मिलाएँ

मूल SoftEther प्रविष्टि स्वतः OpenVPN कॉन्फ़िगरेशन नहीं होती, तब भी जब दोनों एक ही शीर्षक के अंतर्गत एक ही प्रदाता पृष्ठ पर दिखाई दें। जब कोई नोड OpenVPN के लिए TCP और UDP दोनों श्रोता प्रकाशित करता है, तो उन्हें दो एंडपॉइंट मानें: एक से दूसरे में संपादित प्रोफ़ाइल ऐसे श्रोता की ओर इशारा करती है जिसे किसी ने सक्षम नहीं किया। फ़ाइल में परिवहन लेबल पते का हिस्सा है, सजावटी सेटिंग नहीं।

क्लाइंट द्वारा आयातित फ़ाइल स्वीकार किया जाना सिद्ध करता है कि फ़ाइल पार्स होती है। यह इस बारे में कुछ नहीं कहता कि दूसरे सिरे पर कोई दूरस्थ श्रोता प्रतीक्षा कर रहा है या नहीं, इसलिए पहला कनेक्शन प्रयास ही असली परीक्षा है। प्रोटोकॉल को दोष देने से पहले प्रोफ़ाइल की रिमोट पंक्ति की तुलना नोड के घोषित होस्ट और पोर्ट से करें।

उस चरण की जाँच करें जो विफल होता है

वेब ट्रैफ़िक का उत्तर देने वाले होस्ट में भी इच्छित VPN सेवा नहीं हो सकती, और जो होस्ट एक प्रोटोकॉल को अस्वीकार करता है वह ज़रूरी नहीं कि सभी के लिए बंद हो। ये दो गलतियाँ लोगों को उसी दोपहर विपरीत दिशाओं में भेजती हैं। एक ऐसे फ़ायरवॉल का पीछा करता है जो ठीक है; दूसरा ऐसे क्लाइंट को फिर से स्थापित करता है जो कभी समस्या नहीं था। हर पथ को अलग-अलग जाँचें ताकि उत्तर पूरे होस्ट के बजाय एक श्रोता का वर्णन करे।

ये पाँच जाँचें सामान्य सार्वजनिक नोड विधियों को कवर करती हैं। उन्हें उसी नेटवर्क से चलाएँ जिसका क्लाइंट उपयोग करता है, क्योंकि फ़िल्टर किया गया पोर्ट दूर से अनुपस्थित श्रोता जैसा ही दिखता है।

nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example

कुछ भी बदलने से पहले हर देखी गई त्रुटि को उसकी पंक्ति से जोड़ें। TLS पहचान विफलता सिद्ध करती है कि श्रोता मौजूद है, इसलिए प्रोफ़ाइल को दूसरे प्रोटोकॉल में फिर से लिखना काम करता प्रमाण त्याग देगा। अस्वीकृत कनेक्शन केवल यह सिद्ध करता है कि इस पोर्ट ने उत्तर नहीं दिया, जो “नोड OpenVPN का समर्थन नहीं करता” से कहीं अधिक संकीर्ण कथन है।

कुछ भी बदलने से पहले त्रुटि सुरक्षित रखें

सटीक परिणाम लिखें: समय समाप्ति, प्रमाणपत्र पहचान विफलता, खाता अस्वीकृति और अनुप्रयोग-स्तरीय इनकार चार अलग परिणाम हैं। केवल पहला प्रोटोकॉल के अनुपलब्ध होने के बारे में है, और केवल अंतिम सफल कनेक्शन के बाद अनुमति के बारे में है। क्लाइंट को रीसेट करना या प्रोटोकॉल बदलना उस भेद को नष्ट कर देता है, क्योंकि अगली विफलता अलग इतिहास के साथ और तुलना के लिए किसी आधार-रेखा के बिना आती है।

असंगत प्रोफ़ाइल को काम करता दिखाने के लिए सत्यापन कमज़ोर न करें। निष्क्रिय प्रमाणपत्र जाँच स्पष्ट पहचान विफलता को ऐसी चीज़ से कनेक्शन में बदल देती है जहाँ आप पहुँचने का इरादा नहीं रखते थे, और परिणामी सफलता मूल त्रुटि से बदतर है क्योंकि यह छिपा देती है कि कौन-सा चरण गलत था।

हर नोड के लिए हर बार फिर से जाँचें

सार्वजनिक नोड सूची पर मूल SSL, OpenVPN, L2TP/IPsec और SSTP विकल्प उस क्षण उस नोड के कॉन्फ़िगरेशन का वर्णन करते हैं। वही सॉफ़्टवेयर कहीं और अलग समुच्चय प्रस्तुत कर सकता है, और प्रदाता आपके बुकमार्क और आपके अगले प्रयास के बीच किसी श्रोता को हटा सकता है। पुरानी टिप्पणियाँ पुराने परिनियोजनों का वर्णन करती हैं।

सत्यापित प्रोफ़ाइल को उसके एंडपॉइंट और विधि के साथ दर्ज करें, फिर जब नोड बदले या कनेक्शन विफल होने लगे तो जाँच दोहराएँ। SoftEther प्रोटोकॉल विनिर्देश इस बात का संदर्भ है कि सॉफ़्टवेयर क्या कर सकता है; नोड की अपनी सूची इस बात का संदर्भ है कि वह क्या करता है। दोनों दस्तावेज़ों को अलग रखें और निदान छोटा हो जाता है।