TLS OpenVPN भित्र कहाँ बस्छ र केले आकार बदल्छ

OpenVPN साँच्चै TLS प्रयोग गर्छ, र मानिसहरूले यसलाई नसक्ने दाबीसम्म विस्तार गर्छन्: टनेल त्यसैले साइट हेर्ने ब्राउजरजस्तो देखिन्छ भनेर। पहिलो भाग सत्य हो। दोस्रो होइन। यहाँ TLS नियन्त्रण च्यानलको हो जो OpenVPN को आफ्नै कन्टेनरभित्र यात्रा गर्छ, साथै पूर्ण रूपमा फरक क्रिप्टोग्राफी भएको पेलोड च्यानल छ, त्यसैले सुरुका बाइट जाँच्नेले OpenVPN देख्छ।

एउटै खामभित्र दुई कुराकानी

सत्रलाई एउटै खाम बाँड्ने दुई कुराकानीको रूपमा सोच्नुहोस्। एउटाले प्रमाणपत्र प्रमाणित गर्छ र कुञ्जी सामग्री निकाल्छ। अर्कोले तपाईंले साँच्चै पठाइरहेको कुरा पहिलोले उत्पादन गरेको कुराले इन्क्रिप्ट गर्छ।

खाम नै प्रोटोकल हो। हरेक प्याकेट आफ्नो प्रकार बताउने सानो हेडरबाट सुरु हुन्छ, र त्यो हेडर अरू सबैभन्दा पहिले आउँछ।

साँच्चै पहिले के आउँछ

त्यो क्रमका कारण तारमा पहिलो कुरा TLS रेकर्ड होइन। त्यो OpenVPN को हेडर हो, त्यसपछि हेडरले घोषणा गर्ने च्यानलको सामग्री आउँछ। त्यहाँ ClientHello छ, तर शून्य बाइटमा होइन। फरक देख्न कुनै डिक्रिप्सन आवश्यक छैन, किनकि आकारले नै यसलाई खोलिदिन्छ।

डिफल्ट पनि यहाँ महत्त्वपूर्ण छन्। प्रोफाइलले TCP नरोजेसम्म प्रवाह UDP बाट 1194 मा जान्छ। दुवै अवस्थामा बाहिरी रूप टनेल हो, वेब अनुरोध होइन।

आकार बदल्ने तीन इमानदार तरिका

stunnel जस्तो TLS टर्मिनेटरले दुवै छेउमा एउटा पोर्टमा TLS स्वीकार्छ र डिक्रिप्ट भएको प्रवाह स्थानीय रूपमा OpenVPN लाई दिन्छ, त्यसैले नेटवर्कले त्यो पोर्टतिर TLS देख्छ। पहिलो बाइटबाटै TLS हुने प्रोटोकल फेरि फरक व्यवहार गर्छ: ocserv ले लागू गर्ने AnyConnect-मिलनसार आदानप्रदान धेरै नेटवर्कले पहिले नै अपेक्षा गर्ने कर्पोरेट टाढा पहुँचजस्तो देखिन्छ। Windows सँग आउने SSTP अर्को उत्पादनमा त्यही गुण राख्छ।

Linux मा, SSH को -w विकल्पले SSH सत्रभित्र बिन्दु-देखि-बिन्दु लिङ्क बोक्छ, जुन SSH मात्र अनुमत प्रोटोकल हुँदा उपयोगी हुन्छ। त्यो नेटवर्कबाट SSH पहिले नै चल्छ भने चारमध्ये सबैभन्दा सस्तो, र नचल्ने भए सबैभन्दा कम उपयोगी।

तीमध्ये कुनैले नबदल्ने कुरा

यीमध्ये कुनैले पनि टनेल कहाँसम्म पुग्न सक्छ भन्ने बदल्दैन। तिनले अवरुद्ध ठेगानालाई पुग्नयोग्य बनाउँदैनन्, कसैलाई प्रमाणित गर्दैनन्, र मार्गहरू तय गर्दैनन्।

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

पहिले निदान गर्नुहोस्, त्यसपछि छान्नुहोस्

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

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

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

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