UDP सधैं छिटो हुँदैन: OpenVPN ट्रान्सपोर्ट छान्ने

हरेक मार्गदर्शकले OpenVPN का लागि UDP, TCP भन्दा राम्रो भन्छ, र त्यो सल्लाह पूर्वनिर्धारित हो, मापन होइन। ट्रान्सपोर्टले प्याकेट कसरी पुर्‍याइन्छ र मार्गले तिनीहरूलाई फ्याँक्दा के हुन्छ भन्ने परिवर्तन गर्छ, टनेल कसरी इन्क्रिप्ट हुन्छ भन्ने होइन। क्याप्टिभ पोर्टल वा पोर्ट 443 मात्र अनुमति दिने प्रोक्सीको पछाडि, ढिलो विकल्प नै वास्तवमा जोडिने हो। अगाडिको भागले प्रोटोकलले के गर्छ र तपाईंको पहुँच सञ्जालले के अनुमति दिन्छ भन्ने छुट्याउँछ।

ट्रान्सपोर्टले वास्तवमा के परिवर्तन गर्छ

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

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

यीमध्ये केहीले पनि गोपनीयता वा अखण्डतालाई छुँदैन। TLS ह्यान्डशेक र डेटा-च्यानल साइफर दुवै ट्रान्सपोर्टका लागि उही हुन्, त्यसैले बदल्नाले कमजोर साइफर सुइट बचाउन सक्दैन।

TCP ले आफ्नो ठाउँ कहाँ कमाउँछ

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

मार्ग स्थिर तर बीचका बक्सहरू शत्रुतापूर्ण हुँदा पनि TCP सहयोग गर्छ। केही सञ्जालले सामान्य वेब ट्राफिकजस्तो देखिने TCP सत्र सहन्छन् तर लामो UDP प्रवाह रिसेट गर्छन्। त्यो समानता सफल हुन्छ कि हुँदैन भन्ने विशेष सञ्जालको गुण हो, र कुनै मार्गदर्शकले सबैका लागि वाचा गर्न सक्दैन। प्रोटोकललाई दोष दिनुअघि असफल हुने सञ्जालभित्रै परीक्षण गर्नुहोस्।

अस्वीकृत लगइन ट्रान्सपोर्टको समस्या होइन। जबरजस्ती जडान पार गराउन प्रमाणपत्र प्रमाणीकरण बन्द गर्नु अर्को परिवर्तन हो, जसको नतिजा धेरै नराम्रो हुन्छ।

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 तर्फ संकेत गर्छ। बारम्बार पुनःजडानले मार्ग वा बीचको बक्सको समयसीमातर्फ संकेत गर्छ।

वास्तवमा भेटिने परिस्थितिमा चल्ने प्रोफाइल राख्नुहोस् र अर्को सुरक्षित राख्नुहोस्। छनोट व्यक्तिको होइन, सञ्जालको हो, त्यसैले कुनै एकल पूर्वनिर्धारित उत्तर कतै गलत हुन्छ।