Cloudflare प्रोक्सीले एउटै नाममा OpenVPN किन बोक्न सक्दैन
प्रोक्सी गरिएको रेकर्डले HTTP र HTTPS हेर्छ। नामहरू छुट्याउनुहोस्, दुई स्रोताहरू राख्नुहोस्, र प्रत्येक जडानलाई उसको सामुन्ने पक्षले साँच्चै विश्वास गर्ने प्रमाणपत्र दिनुहोस्।
एउटै मेसिनले वेबसाइट र 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 मात्र नाम, छुट्टै स्रोताहरू, प्रत्येक सम्बन्धका लागि प्रमाणपत्र, र त्यसपछि प्रत्येक नाम आफू पुग्नुपर्ने सेवामा मात्र पुग्छ भनी प्रमाणित गर्ने एउटा परीक्षण।