UDP हमेशा तेज़ नहीं होता: OpenVPN ट्रांसपोर्ट चुनना

हर गाइड कहती है कि OpenVPN के लिए UDP, TCP से बेहतर है, और यह सलाह एक डिफ़ॉल्ट है, माप नहीं। ट्रांसपोर्ट यह बदलता है कि पैकेट कैसे पहुँचाए जाते हैं और जब पथ उन्हें गिरा देता है तो क्या होता है, यह नहीं कि सुरंग कैसे एन्क्रिप्ट होती है। कैप्टिव पोर्टल या केवल पोर्ट 443 की अनुमति देने वाले प्रॉक्सी के पीछे, धीमा विकल्प वही है जो आख़िरकार जुड़ता है। आगे यह अलग किया गया है कि प्रोटोकॉल क्या करता है और आपका एक्सेस नेटवर्क क्या अनुमति देता है।

ट्रांसपोर्ट वास्तव में क्या बदलता है

TCP एक विश्वसनीय, क्रमबद्ध बाइट स्ट्रीम देता है और जो खो जाता है उसे दोबारा भेजता है, जैसा RFC 9293 निर्दिष्ट करता है। UDP डेटाग्राम नेटवर्क को सौंपता है, और OpenVPN उस सॉकेट पर अपनी विश्वसनीयता परत चलाता है। TCP को TCP के भीतर एनकैप्सुलेट करने से दो रिकवरी लूप ढेर हो जाते हैं, इसलिए एक खोया सेगमेंट भीतरी स्ट्रीम को रोक सकता है जब तक बाहरी पुनःप्रेषण न पहुँचे। यही अंतःक्रिया UDP के पक्ष में असली तर्क है, और यह थ्रूपुट के बजाय विलंबता के रूप में दिखती है।

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

इसमें से कोई भी गोपनीयता या अखंडता को नहीं छूता। TLS हैंडशेक और डेटा-चैनल सिफ़र दोनों ट्रांसपोर्ट के लिए एक ही हैं, इसलिए बदलने से कमज़ोर सिफ़र सूट नहीं बच सकता।

TCP अपनी जगह कहाँ कमाता है

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

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

अस्वीकृत लॉगिन ट्रांसपोर्ट की समस्या नहीं है। कनेक्शन को ज़बरदस्ती निकालने के लिए प्रमाणपत्र सत्यापन बंद करना एक अलग बदलाव है जिसका परिणाम बहुत बुरा है।

TCP प्रोफ़ाइल तैयार रखना व्यावहारिक समझौता है। अधिकांश क्लाइंट दोनों संग्रहीत करते हैं और नेटवर्क द्वारा UDP पथ अस्वीकार किए जाने पर बदलने देते हैं, जिसकी ज़रूरत पड़ने तक कुछ ख़र्च नहीं होता। आपको जो नहीं करना चाहिए वह है अलग-अलग एंडपॉइंट की ओर इशारा करने वाली दो प्रोफ़ाइल भेजना, क्योंकि तब आपकी तुलना सर्वरों को मापती है।

जाँचें कि आपके पास वास्तव में कौन-सा श्रोता है

प्रदर्शन की तुलना से पहले पुष्टि करें कि दोनों सिरे ट्रांसपोर्ट और पोर्ट पर सहमत हैं। क्लाइंट फ़ाइल में proto udp को proto tcp में बदलने से सर्वर श्रोता नहीं बनता। सर्वर को उस प्रोटोकॉल के लिए कॉन्फ़िगर होना चाहिए, और प्रोफ़ाइल को उससे मेल खाना चाहिए।

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep वह प्रिंट करता है जो सर्वर को उपयोग करने के लिए कहा गया था, जबकि दो सॉकेट सूचियाँ दिखाती हैं कि वह किससे बँधा है। UDP श्रोता केवल पहली सूची में और TCP श्रोता केवल दूसरी में दिखता है, इसलिए गुम लाइन ऐसी प्रोफ़ाइल खोजने का सबसे तेज़ तरीका है जो कभी लागू नहीं हुई। पोर्ट की भी तुलना करें, क्योंकि 1194 पर TCP प्रोफ़ाइल अधिकांश एक्सेस नेटवर्क में 443 वाली से अलग व्यवहार करती है। बदलाव के बाद सेवा पुनः आरंभ करें और बाइंडिंग की सूचना देने वाली लॉग लाइन पढ़ें।

क्लाइंट पक्ष पर पुष्टि सस्ती है: कनेक्शन को --verb 4 के साथ चलाएँ और लॉग में ट्रांसपोर्ट लाइन पढ़ें। अगर क्लाइंट UDP कहता है जबकि सर्वर TCP पर सुन रहा है, हैंडशेक कभी शुरू नहीं होता और कोई भी ट्यूनिंग मदद नहीं करेगी।

कार्यभार की तुलना करें, ट्रांसपोर्ट के लेबल की नहीं

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

हर रन के लिए तीन परिणाम दर्ज करें: सुरंग बनती है या नहीं, टिकती है या नहीं और कार्य पूरा होता है या नहीं। छोटे अनुरोध काम करें और बड़े स्थानांतरण अटकें तो यह ट्रांसपोर्ट नहीं, पैकेट आकार और MTU की ओर संकेत करता है। बार-बार पुनःकनेक्ट पथ या मध्यवर्ती बॉक्स के समय-समाप्ति की ओर संकेत करते हैं।

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