proto udp या tcp-client: आपका सर्वर किसे सुनता है?

पिछले महीने चलने वाली प्रोफ़ाइल अब समय-सीमा पर पहुँच रही है, और कोई proto udp को proto tcp-client से बदलने का सुझाव देता है। कभी-कभी यह सही कदम होता है, और कभी-कभी ऐसा क्लाइंट बनता है जो ऐसे पोर्ट से जुड़ता है जहाँ कोई नहीं सुन रहा, क्योंकि सर्वर को कभी दूसरे ट्रांसपोर्ट के लिए कॉन्फ़िगर ही नहीं किया गया। यह निर्देश बताता है कि आपका सिरा कैसे बोलता है; यह दूसरे सिरे पर श्रोता नहीं बना सकता। दोनों में से कोई भी बदलने से पहले प्रोफ़ाइल और सर्वर को साथ पढ़ें।

चुने गए कनेक्शन द्वारा इस्तेमाल किया जाने वाला ट्रांसपोर्ट पढ़ें

एक प्रोफ़ाइल में कई remote प्रविष्टियाँ हो सकती हैं, और हर एक अपना ट्रांसपोर्ट बता सकती है। क्लाइंट उन्हें क्रम से पार करता है, इसलिए जो पंक्ति आप पहले देखते हैं वह ज़रूरी नहीं कि लागू होने वाली हो।

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

अगर फ़ाइल में ऊपर एक proto पंक्ति है और उसके नीचे कई remote प्रविष्टियाँ हैं, तो वह पंक्ति हर ऐसे remote के लिए डिफ़ॉल्ट है जो उसे ओवरराइड नहीं करता। डिफ़ॉल्ट में स्थानीय बदलाव उस remote प्रविष्टि के लिए कुछ नहीं करता जो अपना ट्रांसपोर्ट बताती है।

grep -nE '^(remote|proto)\b' client.ovpn

UDP और TCP गति की सेटिंग नहीं हैं

UDP क्रमबद्ध स्ट्रीम बनाए बिना डेटाग्राम भेजता है, इसलिए टनल का अपना ट्रैफ़िक दूसरे भरोसेमंद ट्रांसपोर्ट के भीतर नहीं लपेटा जाता। TCP आपको ऐसे नेटवर्क से रास्ता देता है जो UDP गिराते या ब्लॉक करते हैं, पर इसकी कीमत नेस्टेड पुनःप्रेषण है जो हानि वाले लिंक को और बुरा महसूस करा सकता है।

यह पहुँच का सौदा है, कोई सार्वभौमिक रैंकिंग नहीं। सही चुनाव वही है जो क्लाइंट के सामने का नेटवर्क अनुमति देता है। जो रास्ता VPN पोर्ट पर UDP गिराता है वह कभी बातचीत नहीं करेगा, प्रोफ़ाइल कितनी भी अच्छी लिखी हो। रास्ता जाँचें, फिर ट्रांसपोर्ट चुनें।

उनके बीच केवल माप के आधार पर चुनना गलती है, क्योंकि उत्तर इस पर निर्भर करता है कि आपके सामने का नेटवर्क क्या अनुमति देता है। कोई होटल या कॉर्पोरेट प्रॉक्सी 443 पर केवल बाहरी TCP अनुमति दे सकता है और कुछ नहीं, इसलिए प्रदाता वह संस्करण देते हैं। पोर्ट संख्या परिचित होने पर भी यह उस पोर्ट पर OpenVPN कनेक्शन ही रहता है, HTTPS सत्र नहीं।

tcp-client का वास्तव में क्या अर्थ है

क्लाइंट-साइड निर्देश TCP कनेक्शन शुरू करने वाले सिरे का नाम देता है। सर्वर-साइड अपना सुनने का रूप इस्तेमाल करता है, और क्लाइंट का शब्द सर्वर कॉन्फ़िगरेशन में नकल करने से ऐसा श्रोता बनता है जो कॉल किए जाने की अपेक्षा करता है, स्वीकार करने वाला नहीं।

मेल खाने का अर्थ है कि दोनों सिरे ट्रांसपोर्ट पर सहमत हैं, यह नहीं कि वे एक ही स्ट्रिंग साझा करते हैं।

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

प्रोफ़ाइल को गलत मानने से पहले सर्वर से पूछें कि वह किस पर सुन रहा है। UDP श्रोता TCP सॉकेट सूची में नहीं दिखता, और उल्टा भी सच है, इसलिए सामान्य दृश्य के बजाय प्रोटोकॉल-विशिष्ट दृश्य देखें।

जब प्रोफ़ाइल आयात होती है पर कभी जुड़ती नहीं

तुरंत समय-सीमा पर पहुँचने वाली आयातित प्रोफ़ाइल आमतौर पर किसी भी प्रमाणीकरण से पहले विफल हो जाती है। पैकेट ऐसे पोर्ट पर जाता है जहाँ श्रोता नहीं है, या नेटवर्क उसे चुपचाप गिरा देता है।

रास्ते को सबसे सरल तरीके से जाँचें: विफल हो रहे क्लाइंट जैसे ही नेटवर्क से, प्रोफ़ाइल द्वारा दावा किए गए ट्रांसपोर्ट के साथ उसी होस्ट और पोर्ट से जुड़ें।

अगर UDP जाँच को कुछ नहीं मिलता और TCP जाँच जुड़ जाती है, तो सर्वर दूसरा ट्रांसपोर्ट दे रहा है और प्रोफ़ाइल बस पुरानी है। अगर कोई भी उत्तर नहीं देता, तो समस्या ट्रांसपोर्ट चुनाव से ऊपर है और प्रोफ़ाइल में कोई भी संपादन उसे ठीक नहीं करेगा। इन दो स्थितियों में अंतर करना एक मिनट लेता है और उस घंटे भर के प्रमाणपत्र डिबगिंग से बचाता है जो कभी प्रासंगिक ही नहीं था।

काम करने वाला ट्रांसपोर्ट दर्ज करें

जब कोई संयोजन काम करे, तो उसे सर्वर, पोर्ट और प्रोटोकॉल के साथ लिख लें, और नोट करें कि किस नेटवर्क से उसकी जाँच की गई।

वरना समय-सीमा से टकराने वाला अगला व्यक्ति वही प्रयोग उल्टी दिशा में दोहराएगा, और संभवतः ऐसे सर्वर को बदल देगा जो ठीक था।

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