TLS, OpenVPN के भीतर कहाँ बैठता है और आकार क्या बदलता है

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

एक लिफ़ाफ़े में दो बातचीत

किसी सत्र को एक लिफ़ाफ़ा साझा करती दो बातचीत मानिए। एक प्रमाणपत्रों को सत्यापित करती है और कुंजी सामग्री निकालती है। दूसरी वह एन्क्रिप्ट करती है जो आप वास्तव में भेज रहे हैं, पहली के उत्पादित का उपयोग करके।

लिफ़ाफ़ा ही प्रोटोकॉल है। हर पैकेट एक छोटे हेडर से शुरू होता है जो उसका प्रकार बताता है, और वह हेडर बाकी सब से पहले आता है।

वास्तव में पहले क्या आता है

इसी क्रम के कारण तार पर पहली चीज़ TLS रिकॉर्ड नहीं है। वह OpenVPN का हेडर है, और उसके बाद उस चैनल की सामग्री जिसकी घोषणा हेडर करता है। वहाँ एक ClientHello मौजूद है, बस शून्य बाइट पर नहीं। अंतर नोटिस करने के लिए कोई डिक्रिप्शन ज़रूरी नहीं, क्योंकि आकार अकेला ही उसे ज़ाहिर कर देता है।

डिफ़ॉल्ट भी यहाँ मायने रखते हैं। प्रवाह UDP से 1194 पर जाता है जब तक प्रोफ़ाइल TCP न चुने। दोनों हालत में बाहरी रूप टनल है, वेब अनुरोध नहीं।

आकार बदलने के तीन ईमानदार तरीके

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

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

इनमें से कोई क्या नहीं बदलता

इनमें से कोई यह नहीं बदलता कि टनल कहाँ तक पहुँच सकती है। ये किसी अवरुद्ध पते को पहुँचने योग्य नहीं बनाते, किसी का प्रमाणीकरण नहीं करते और मार्ग तय नहीं करते।

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

पहले निदान करें, फिर चुनें

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

जो नेटवर्क केवल वेब पोर्ट की अनुमति देता है, वह चुनाव को 443 पर TLS-आधारित प्रोटोकॉल तक सीमित कर देता है। तीनों को एक साथ लागू करने से ऐसा स्टैक मिलता है जिसे कोई डीबग नहीं कर सकता, इसलिए एक चीज़ बदलें और वही प्रवाह फिर जाँचें।

यदि इनमें से कोई लागू न हो, तो सटीक उत्तर यह है कि यह नेटवर्क आपके लिए टनल नहीं ढोएगा। यह एक निष्कर्ष है, प्रयास की विफलता नहीं। अधिक विकल्पों से गुज़रना ऊपर लिए गए नीति निर्णय को उलटता नहीं।

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