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 बाटो खुला राख्छ।
तपाईंले अडेका चार जवाफ र प्रत्येकलाई प्रमाणित गर्ने अवलोकन लेख्नुहोस्। तपाईंले वर्णन गर्न सक्ने ट्रान्जिट बाटो भनेको अर्को घटना समीक्षामा तपाईंले बचाउन सक्ने बाटो हो।