OpenVPN क्लाइंट्स को Cloudflare से रूट करें? पहले भूमिका जाँचें
डिवाइस क्लाइंट राउटर नहीं है। पुष्टि करें कि Cloudflare भूमिका दूसरे होस्ट के पैकेट फ़ॉरवर्ड करती है, फिर सर्वर की अपनी टनल को उसके पुराने रास्ते पर रखें।
आपके पास एक चलता हुआ OpenVPN सर्वर है और एक होस्ट है जो Cloudflare का डिवाइस सॉफ़्टवेयर भी चलाता है, और अगला स्पष्ट कदम क्लाइंट ट्रैफ़िक को उसकी ओर भेजना लगता है। एक मशीन पर दो चलते कनेक्शन मिलकर ट्रांज़िट गेटवे नहीं बनते। जो कम है वह दूसरे के पैकेट फ़ॉरवर्ड करने के लिए प्रलेखित भूमिका है, और वह नीति जो उन पैकेटों को उनके आने पर वर्गीकृत करती है।
किसी भी नियम से पहले चार प्रश्न आते हैं: कौन-सा ट्रैफ़िक अंदर आता है, वह आगे कहाँ जाता है, उत्तर वापसी का रास्ता कैसे पाते हैं, और जब वह दूसरा रास्ता विफल होता है तो डिज़ाइन क्या करता है। पहले दो क्षमता के प्रश्न हैं।
एक होस्ट पर दो सेवाएँ ट्रांज़िट रास्ता नहीं हैं
डिवाइस क्लाइंट उस मशीन पर पैदा होने वाले ट्रैफ़िक को संभालने के लिए बना है जहाँ वह चलता है। वह नाम-समाधान या चुने हुए एप्लिकेशन ट्रैफ़िक को पकड़ता है और अपनी टनल से भेजता है, और उसकी नीति उस डिवाइस के उपयोगकर्ता और उस डिवाइस की प्रक्रियाओं के लिए लिखी गई है। OpenVPN क्लाइंट से फ़ॉरवर्ड किया गया पैकेट स्थानीय आउटपुट नहीं है, इसलिए वही नियम उसे वर्गीकृत नहीं करते। यह कॉन्फ़िगरेशन की ऐसी बारीकी नहीं है जिसे व्यापक नियम से ढका जा सके, क्योंकि यह तय करती है कि सॉफ़्टवेयर पैकेट को देखता है या नहीं।
इसीलिए डिज़ाइन का प्रश्न क्षमता का प्रश्न है। या तो इंस्टॉल किए गए उत्पाद में दूसरे नेटवर्क के लिए ट्रैफ़िक फ़ॉरवर्ड करने वाली प्रलेखित भूमिका है, या ट्रांज़िट कार्य किसी और जगह का है।
Cloudflare की कौन-सी भूमिका फ़ॉरवर्ड कर सकती है
Cloudflare का डिवाइस क्लाइंट ऐसे मोड देता है जो दायरे में भिन्न हैं: केवल नाम-समाधान, डिवाइस से ट्रैफ़िक, और कभी-कभी दोनों। उनमें से कोई भी मोड होस्ट को ऐसी निजी श्रेणी के लिए राउटर नहीं बनाता जो किसी दूसरी टनल से आती है। समर्पित रूटिंग भूमिका एक अलग उत्पाद है जिसका अपना कनेक्टर, पंजीकरण और नेटवर्क मॉडल है।
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
उसके आसपास रूट डिज़ाइन करने से पहले इंस्टॉल की गई भूमिका जाँचें। पढ़ें कि कनेक्टर कौन-सा इंटरफ़ेस बनाता है, वह विशिष्ट प्रीफ़िक्स या डिफ़ॉल्ट रूट की घोषणा करता है या नहीं, और स्थानीय नीति फ़ॉरवर्ड किए गए पैकेटों पर भी लागू होती है या नहीं। यदि केवल स्थानीय ट्रैफ़िक संभाला जाता है, तो अनुवाद नियम चाहे जैसे लिखा हो, OpenVPN सर्वर ट्रांज़िट बिंदु नहीं हो सकता।
यहीं सार्वजनिक निकास की आवश्यकता को सटीक रूप से कहना होता है। फ़ॉरवर्ड किए गए क्लाइंट ट्रैफ़िक के लिए Cloudflare द्वारा दिया गया निकास एक विशिष्ट उपयोग-मामला है, और इसे उस सेवा के सामने पुष्ट किया जाना चाहिए जो वास्तव में आपके पास है।
बाहरी टनल को नए रूट से स्वतंत्र रखें
जिस क्षण आप नए इंटरफ़ेस की ओर डिफ़ॉल्ट रूट जोड़ते हैं, उसी क्षण सर्वर का अपना आउटबाउंड ट्रैफ़िक उसके लिए प्रतिस्पर्धा करने लगता है, और इसमें OpenVPN क्लाइंट्स को दिए गए उत्तर तथा बॉक्स तक आपका SSH सत्र भी शामिल है। सामान्य लक्षण वह टनल है जो स्थापित होकर मर जाती है, या ऐसा प्रशासक जो बाहर ताला बंद कर दिया जाता है जबकि बदलाव काम करता दिखता है। एंडपॉइंट के लिए ip route get की पहले और बाद में तुलना करें, और सर्वर के अपने परिवहन को जहाँ था वहीं रखने के लिए नीति-आधारित रूटिंग या होस्ट रूट का उपयोग करें। वह तुलना बॉक्स से ही चलाएँ, क्योंकि सर्वर का अपने रूट के विषय में अपना दृष्टिकोण ही मायने रखता है।
सर्वर के सार्वजनिक पते के लिए अपवाद अपने आप में पर्याप्त नहीं है, क्योंकि हर दूरस्थ प्रशासक का वापसी मार्ग अलग प्रवाह है। तय करें कि उन प्रवाहों में से किसे इस बदलाव को झेलना है, फिर पहले वाले के बाकी को ढक लेने की मान्यता के बजाय हर एक को सत्यापित करें।
फ़ॉरवर्डिंग और अनुवाद को एक प्रवाह तक सीमित करें
प्राप्त पैकेट फ़ॉरवर्डिंग पथ का अनुसरण करते हैं, स्थानीय आउटपुट पथ का नहीं, इसलिए महत्वपूर्ण नियम forward हुक में रहता है। जहाँ अगले इंटरफ़ेस को अनुवाद चाहिए, वहाँ स्रोत को क्लाइंट पूल तक, गंतव्य को अनुमत तक और निकास को उस एक इंटरफ़ेस तक सीमित करें। केवल इंटरफ़ेस से बँधा masquerade नियम स्वयं कोई रूट नहीं चुनता और किसी अन्य फ़िल्टर से आगे फ़ॉरवर्डिंग की अनुमति नहीं देता।
विफलता पर बंद होने का व्यवहार पहले से तय करें, फिर उसका परीक्षण करें। आगे का पथ रोकें और पुष्टि करें कि क्लाइंट्स इच्छित निकास खो देते हैं, बजाय चुपचाप सामान्य अपलिंक पर लौट जाने के, क्योंकि यही वह परिणाम है जिसे कोई तब तक नहीं देखता जब तक ट्रैफ़िक गलत दरवाज़े से बाहर न जाने लगे। नाम-समाधान और IPv6 के लिए जाँच दोहराएँ, क्योंकि केवल v4 के लिए नियम-समूह v6 पथ खुला छोड़ देता है।
जिन चार उत्तरों पर आप टिके और जो अवलोकन हर एक को सिद्ध करता है, उन्हें लिख लें। जिस ट्रांज़िट पथ का आप वर्णन कर सकते हैं, वही अगली घटना समीक्षा में आप बचा सकते हैं।