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 मार्ग उघडा ठेवतो।
तुम्ही थांबलेल्या चार उत्तरांची आणि प्रत्येकाला सिद्ध करणाऱ्या निरीक्षणाची नोंद करा। तुम्ही वर्णन करू शकता तो ट्रान्झिट मार्ग म्हणजे पुढच्या घटना आढाव्यात तुम्ही समर्थन करू शकता तोच।