Cloudflare प्रॉक्सी एक नाम पर OpenVPN क्यों नहीं ले जा सकता

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

दो नाम, दो परिवहन

वेबसाइट को प्रॉक्सी वाला रिकॉर्ड दें ताकि उसका HTTP और HTTPS यातायात Cloudflare से गुज़रे। VPN को केवल-DNS रिकॉर्ड दें जो सीधे सार्वजनिक VPN प्रवेश पर हल हो, और क्लाइंट को वही UDP या TCP पोर्ट इस्तेमाल करने दें जिसके लिए वह कॉन्फ़िगर है।

दोनों नाम एक ही मूल मशीन पर पहुँच सकते हैं। अंतर यह है कि क्लाइंट और उस मशीन के बीच क्या होता है, और यही अंतर बँटवारे का उद्देश्य है।

Cloudflare का नेटवर्क-पोर्ट संदर्भ सूचीबद्ध करता है कि सामान्य वेब प्रॉक्सी कौन-से पोर्ट स्वीकार करता है। वह सूची उन पोर्ट पर HTTP और HTTPS के बारे में है, न कि संख्या साझा करने वाले मनमाने प्रोटोकॉल के बारे में।

पोर्ट प्रोटोकॉल नहीं है

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

अगर आवश्यकता वास्तव में VPN डेटा पथ में Cloudflare उत्पाद डालने की है, तो उसका मूल्यांकन करें जो आपके ज़रूरी प्रोटोकॉल के समर्थन का दस्तावेज़ीकरण करता हो। यह न मानें कि नारंगी बादल सामान्य TCP या UDP सुरंग है, क्योंकि यह विशिष्ट काम वाले वेब यातायात के लिए उल्टा प्रॉक्सी है।

केवल-DNS रिकॉर्ड वह उबाऊ उत्तर है जो काम करता है, और पहले उसी की ओर हाथ बढ़ाना चाहिए।

एक मशीन को अब भी दो श्रोता चाहिए

अलग नाम दो प्रक्रियाओं को एक ही समय में एक ही पता, पोर्ट और परिवहन बाँधने नहीं देते। अगर वेब सर्वर पहले से सभी पतों पर TCP 443 रखता है, तो OpenVPN इंस्टेंस सोच-समझकर की गई व्यवस्था के बिना उसे भी नहीं ले सकता।

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

प्रमाणपत्र उस संबंध का पीछा करते हैं जिसकी वे रक्षा करते हैं

ब्राउज़र का Cloudflare से TLS कनेक्शन और Cloudflare का आपके मूल से कनेक्शन दो अलग प्रमाणपत्रों वाले दो अलग संबंध हैं। ब्राउज़र किनारे का प्रमाणपत्र देखता है। मूल Cloudflare को अपना प्रमाणपत्र प्रस्तुत करता है, और Cloudflare Origin CA प्रमाणपत्र ठीक उसी दूसरे संबंध के लिए है।

Cloudflare उस मूल प्रमाणपत्र पर Full (strict) मोड में भरोसा करता है और वह सामान्य रूप से विश्वसनीय ब्राउज़र प्रमाणपत्र नहीं है। अगर कोई केवल-DNS मेज़बान-नाम पर सीधे जाता है और चेतावनी पाता है, तो यह बदले हुए भरोसे के रास्ते का अपेक्षित परिणाम है, एन्क्रिप्शन रुकने का प्रमाण नहीं।

इसलिए सीधे देखी जाने वाली वेबसाइट को ऐसी प्रमाणपत्र श्रृंखला चाहिए जिस पर उसके ब्राउज़र भरोसा करें। यह ऐसी प्रॉक्सी वाली साइट के साथ सह-अस्तित्व में रह सकता है जिसके मूल पर जाना ही नहीं है।

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

उजागर नाम का पीछा करता है

केवल-DNS VPN रिकॉर्ड उस पते को प्रकाशित करता है जिस पर वह इंगित करता है। अगर वही पता वेब मूल भी है, तो मूल छिपा नहीं है, और दूसरा नाम प्रॉक्सी वाला होने के कारण उसे छिपा कहना ऐसी भूल है जो तब तक बनी रहती है जब तक कोई उसे स्कैन न करे।

तय करें कि कौन-से वेब अनुरोध मूल तक सीधे पहुँच सकते हैं और इसे मूल पर लागू करें, फिर VPN श्रोता को उसकी अपनी शर्तों पर अनुमति दें। प्रबंधन पृष्ठ, प्रोफ़ाइल डाउनलोड और डेटा श्रोता तीन अलग उजागर आवश्यकताएँ रख सकते हैं, भले ही एक पैकेज तीनों देता हो।

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

काम का क्रम: साइट के लिए प्रॉक्सी वाला नाम, VPN के लिए केवल-DNS नाम, अलग श्रोता, हर संबंध के लिए प्रमाणपत्र, और फिर एक परीक्षण जो साबित करे कि हर नाम केवल उसी सेवा तक पहुँचता है जहाँ पहुँचना चाहिए।