Cloudflare के पीछे origin बचाएँ—साझा प्रमाणपत्र पूरी पहचान नहीं देता

|लेखक: QUASA संपादकीय टीम|6 मिनट पढ़ने का समय
Cloudflare के पीछे origin बचाएँ—साझा प्रमाणपत्र पूरी पहचान नहीं देता

मूल सर्वर को केवल सत्यापित Cloudflare संपर्क से अनुरोध स्वीकार कराने के लिए Authenticated Origin Pulls चालू करें और सर्वर पर क्लाइंट प्रमाणपत्र की जाँच अनिवार्य करें। Cloudflare की तकनीकी व्याख्या के अनुसार यह सर्वर तक जाने वाले TLS संपर्क में अतिरिक्त पहचान जाँच जोड़ता है। नियम लागू होने पर वैध क्लाइंट प्रमाणपत्र के बिना सीधे भेजा गया HTTPS अनुरोध मूल सामग्री प्राप्त नहीं कर पाता।

इस सुरक्षा की सीमा पहले समझ लें: वैश्विक व्यवस्था के निर्देश बताते हैं कि Cloudflare का दिया हुआ क्लाइंट प्रमाणपत्र सभी खातों में साझा है। वह संपर्क के Cloudflare नेटवर्क से आने की पुष्टि करता है, किसी विशेष खाते की नहीं। यदि मूल सर्वर को अपने खाते या किसी खास होस्टनाम की अलग पहचान चाहिए, तो अपने प्रमाणपत्र वाली क्षेत्र या होस्टनाम स्तर की व्यवस्था चुनें।

पहले HTTPS का वास्तविक प्रवेश बिंदु तय करें

जिस होस्टनाम को सुरक्षित करना है, उसका ट्रैफ़िक Cloudflare प्रॉक्सी से होकर मूल सर्वर तक पहुँचना चाहिए। संबंधित क्षेत्र में TLS एन्क्रिप्शन मोड कम से कम Full रखें। इसके बाद पता करें कि Cloudflare से आया HTTPS संपर्क कहाँ समाप्त होता है: सीधे NGINX या Apache पर, अथवा उनके सामने लगी किसी दूसरी प्रॉक्सी पर। क्लाइंट प्रमाणपत्र की जाँच उसी स्थान पर लगानी होगी जहाँ संपर्क स्थापित होता है।

मूल सर्वर का सर्वर प्रमाणपत्र और Authenticated Origin Pulls का क्लाइंट प्रमाणपत्र अलग भूमिकाएँ निभाते हैं। सर्वर प्रमाणपत्र से Cloudflare मूल सर्वर के साथ एन्क्रिप्टेड संपर्क बनाता है; क्लाइंट प्रमाणपत्र से मूल सर्वर सामने वाले पक्ष की पहचान जाँचता है। इसलिए Cloudflare Origin CA का सर्वर प्रमाणपत्र डाउनलोड करके उसे क्लाइंट प्रमाणपत्र की भरोसा सूची में न रखें। सही फ़ाइल और सही प्रवेश बिंदु चुनना आगे की पूरी प्रक्रिया की शर्त है।

भरोसे की फ़ाइल लगाएँ और जाँच वैकल्पिक रखें

वैश्विक व्यवस्था के लिए Cloudflare का Authenticated Origin Pulls प्रमाणपत्र पीईएम फ़ाइल के रूप में डाउनलोड करके उस मशीन पर रखें जहाँ HTTPS संपर्क समाप्त होता है। वेब सर्वर को फ़ाइल पढ़ने की अनुमति दें और उसका वास्तविक पथ दर्ज करें। फ़ाइल रख देने भर से सीधे अनुरोध बंद नहीं होते: सर्वर के विन्यास में उसे भरोसेमंद क्लाइंट प्रमाणपत्र के रूप में चुनना और बाद में जाँच अनिवार्य करना भी आवश्यक है।

NGINX के संबंधित HTTPS सर्वर खंड में ssl_client_certificate /etc/nginx/certs/cloudflare.crt; तथा ssl_verify_client optional; जोड़ें। पहला निर्देश भरोसे की फ़ाइल बताता है और दूसरा प्रमाणपत्र की जाँच को फिलहाल वैकल्पिक रखता है। यहाँ दिया पथ केवल उदाहरण है; उसे अपनी फ़ाइल के वास्तविक पथ से बदलें। विन्यास जाँचकर सर्वर को फिर से लोड करें, ताकि गलत पथ या लिखावट के कारण सेवा बाधित होने का जोखिम पहले ही सामने आ जाए।

Apache के संबंधित HTTPS आभासी होस्ट में SSLCACertificateFile /path/to/origin-pull-ca.pem और SSLVerifyClient optional लगाएँ। Apache के प्रमाणपत्र जाँच संबंधी निर्देश के अनुसार वैकल्पिक अवस्था में क्लाइंट प्रमाणपत्र दे सकता है, जबकि अनिवार्य अवस्था में उसे वैध प्रमाणपत्र देना पड़ता है। यहाँ भी उदाहरण पथ बदलें, विन्यास जाँचें और सर्वर फिर से लोड करें। इस चरण में प्रमाणपत्र के बिना आया संपर्क अभी स्वीकार हो सकता है; इसका उद्देश्य वास्तविक ट्रैफ़िक पर व्यवस्था की जाँच करना है।

Cloudflare चालू करें, फिर प्रमाणपत्र अनिवार्य करें

NGINX में क्लाइंट प्रमाणपत्र की जाँच वैकल्पिक से अनिवार्य करने का अंतर।

Cloudflare के नियंत्रण पटल में Origin Server पृष्ठ खोलें, Authenticated Origin Pulls खंड चुनें और Global व्यवस्था चालू करें। फिर प्रॉक्सी से होकर ऐसा अनुरोध भेजें जो वास्तव में मूल सर्वर तक पहुँचे। यदि प्रतिक्रिया Cloudflare की कैश से पूरी हो गई, तो केवल पृष्ठ खुलना मूल सर्वर पर प्रमाणपत्र पहुँचने का प्रमाण नहीं है। उपलब्ध TLS या अनुरोध अभिलेखों में देखें कि संपर्क मूल सर्वर तक पहुँचा और प्रस्तुत प्रमाणपत्र सत्यापित हुआ।

सत्यापित संपर्क सही चलने पर NGINX में पहले वाले जाँच निर्देश का मान on; करें। Apache में उसी निर्देश का मान require करें। विन्यास फिर जाँचें, सर्वर को पुनः लोड करें और सामान्य Cloudflare होस्टनाम से साइट खोलें। अब इस HTTPS प्रवेश बिंदु पर वैध क्लाइंट प्रमाणपत्र के बिना मूल सामग्री नहीं मिलनी चाहिए। यदि वैध अनुरोध भी रुक जाएँ, तो प्रमाणपत्र फ़ाइल का पथ, पढ़ने की अनुमति, भरोसे की फ़ाइल और सही आभासी होस्ट पर नियम लागू होने की जाँच करें।

सीधा अनुरोध भेजकर रोक की पुष्टि करें

मूल सर्वर का सार्वजनिक आईपी पता मालूम हो तो किसी बाहरी मशीन से curl -v --resolve example.com:443:IP https://example.com/ चलाएँ। यह एक उदाहरण आदेश है: example.com को अपने होस्टनाम और IP को मूल सर्वर के पते से बदलें। आदेश होस्टनाम बनाए रखता है, लेकिन संपर्क दिए हुए आईपी पते पर सीधे भेजता है। इसमें क्लाइंट प्रमाणपत्र नहीं दिया गया है, इसलिए सही ढंग से सुरक्षित प्रवेश बिंदु से वेबसाइट की मूल सामग्री नहीं मिलनी चाहिए। अस्वीकृति TLS संपर्क टूटने या सर्वर की त्रुटि प्रतिक्रिया के रूप में दिख सकती है।

परीक्षण किस कारण असफल हुआ, यह भी देखें। यदि जाँच करने वाली मशीन मूल सर्वर के सर्वर प्रमाणपत्र पर भरोसा न करने के कारण ही रुक गई, तो क्लाइंट प्रमाणपत्र वाला नियम अभी परखा नहीं गया। उपयुक्त सर्वर प्रमाणपत्र प्राधिकारी के साथ अनुरोध दोहराएँ और मूल सर्वर के अभिलेखों में क्लाइंट प्रमाणपत्र की अस्वीकृति देखें। साथ ही सामान्य Cloudflare रास्ते से सफल अनुरोध की पुष्टि करें। यदि सीधा HTTP संपर्क या कोई दूसरा HTTPS आभासी होस्ट वही सामग्री दे रहा है, तो उस प्रवेश मार्ग पर भी अलग से रोक लगानी होगी।

अलग खाते की पहचान कब आवश्यक है

curl से सीधे origin पर भेजा गया बिना क्लाइंट प्रमाणपत्र वाला अनुरोध अस्वीकृत होता है, जबकि Cloudflare का रास्ता चलता है।

वैश्विक साझा प्रमाणपत्र उस आवश्यकता के लिए उपयुक्त हो सकता है जिसमें मूल सर्वर को Cloudflare नेटवर्क के बाहर से आए HTTPS अनुरोध रोकने हैं। अपने खाते की अलग पहचान चाहिए तो क्षेत्र स्तर या होस्टनाम स्तर पर अपना क्लाइंट प्रमाणपत्र लगाएँ और मूल सर्वर को उसी के जारीकर्ता पर भरोसा करने के लिए विन्यस्त करें। अलग होस्टनामों के लिए अलग पहचान चाहिए तो होस्टनाम स्तर चुनें। इन व्यवस्थाओं की सेटिंग स्वतंत्र है; वैश्विक विकल्प बदलने से दूसरी व्यवस्था अपने आप नहीं बदलती।

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

यह भी पढ़ें:

साझा करें:

हमारे न्यूज़लेटर की सदस्यता लें

Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।

0