आपके शाखा नेटवर्क के लिए कौन-सा Sophos RED मोड उपयुक्त है?
RED दूरस्थ साइट की भूमिका है, प्रोटोकॉल नहीं। शाखा का गेटवे और DHCP किसके पास है, उसके अनुसार Standard/Unified, Standard/Split या Transparent/Split चुनें।
Sophos RED कोई VPN प्रोटोकॉल नहीं, दूरस्थ साइट की भूमिका है, इसलिए IPsec या OpenVPN से इसकी तुलना गलत प्रश्न का उत्तर देती है। यह उपकरण एक केंद्रीय फ़ायरवॉल के नियंत्रण को शाखा तक बढ़ाता है, और आप जो मोड चुनते हैं वह तय करता है कि शाखा का गेटवे कौन देता है, पते कौन बाँटता है और कौन-सा ट्रैफ़िक सुरंग से गुज़रता है। ये तीन उत्तर मोड के नामों से अधिक मायने रखते हैं। इन्हें पहले लिख लेना उत्पाद के चयन को डिज़ाइन निर्णय बना देता है।
RED भूमिका है, प्रोटोकॉल नहीं
एक RED उपकरण शाखा को केंद्रीय Sophos Firewall से जोड़ता है, और फ़ायरवॉल का कॉन्फ़िगरेशन तय करता है कि शाखा क्या बनेगी। सुरंग उस जुड़ाव का कार्यान्वयन विवरण है, कोई सामान्य उद्देश्य वाला VPN अंतिम बिंदु नहीं जिसे किसी भी सहकर्मी की ओर लक्षित किया जा सके।
यह ढाँचा महत्वपूर्ण है क्योंकि RED किसी भी IPsec सहकर्मी के साथ अदला-बदली योग्य नहीं है। यह अपेक्षा करता है कि केंद्रीय फ़ायरवॉल इसे प्रबंधित करे, और समर्थित मोड बताते हैं कि यह शाखा का कितना हिस्सा संभालता है। इसे सामान्य सुरंग अंतिम बिंदु मानने से ऐसी अपेक्षाएँ बनती हैं जो उत्पाद ने कभी नहीं दीं। इसे भूमिका मानने से वे प्रश्न बनते हैं जो वास्तव में डिज़ाइन तय करते हैं।
नीचे की तीन शर्तें उत्तर बदलती हैं, और वे सब स्वामित्व की हैं, एन्क्रिप्शन की नहीं।
मोड चुनने वाली तीन शर्तें
पूछें कि शाखा का गेटवे किसका है, शाखा के क्लाइंट के लिए DHCP और DNS कौन चलाता है, और क्या स्थानीय इंटरनेट आउटलेट को सुरंग टूटने पर भी चलते रहना चाहिए।
Standard/Unified तीनों का एक ही उत्तर देता है: केंद्रीय फ़ायरवॉल शाखा का LAN रखता है, गेटवे और DHCP के दायित्वों सहित, और ट्रैफ़िक सुरंग से गुज़रता है। Standard/Split केंद्रीय प्रबंधन रखता है और केवल कॉन्फ़िगर किए गए नेटवर्क सुरंग से भेजता है। Transparent/Split मौजूदा शाखा नेटवर्क को उसका अपना गेटवे और पते संभालने देता है, और केवल चुना हुआ ट्रैफ़िक सुरंग में मोड़ता है। तीन मोड, तीन अलग मालिक।
| Mode | Branch gateway and DHCP | Traffic through the tunnel |
|---|---|---|
| Standard/Unified | Central firewall owns both | All branch traffic |
| Standard/Split | Central firewall owns both | Only the configured networks |
| Transparent/Split | The existing branch router keeps both | Only the selected flows |
पहले बीच का स्तंभ पढ़ें, क्योंकि वह तय करता है कि सुरंग जाने पर शाखा का कितना हिस्सा अब भी काम करता है।
शाखा का गेटवे और DHCP किसका है
एकीकृत व्यवस्था में शाखा का कोई स्वतंत्र गेटवे नहीं होता, जो कॉन्फ़िगरेशन सरल करता है और विफलता को एक जगह केंद्रित करता है। यह केंद्रीकरण तब ठीक है जब शाखा छोटी हो और केंद्रीय फ़ायरवॉल उच्च उपलब्धता वाला हो।
पारदर्शी परिनियोजन में शाखा अपना राउटर रखती है और चुना हुआ ट्रैफ़िक मोड़ने के लिए RED मार्ग में बैठता है। इससे स्थानीय नियंत्रण बना रहता है और ऐसा उपकरण जुड़ता है जिसकी मार्ग में स्थिति अब हर मोड़े गए प्रवाह के लिए मायने रखती है। यह कहाँ बैठता है, दर्ज करें, क्योंकि बाद में शाखा के राउटर में बदलाव इसे चुपचाप बचा सकता है। कोई भी व्यवस्था सामान्य रूप से नहीं जीतती; वे ज़िम्मेदारी अलग तरह से बाँटती हैं।
पतों का स्वामित्व वह हिस्सा है जो लिखा जाना चाहिए, क्योंकि एक ही खंड पर दो DHCP सर्वर रुक-रुक कर खराबी पैदा करते हैं जिन्हें VPN समस्या बताया जाता है।
सुरंग टूटने पर क्या होता है
Split संचालन को अक्सर यह वादा समझा जाता है कि सुरंग विफल होने पर भी स्थानीय इंटरनेट चलता रहता है, और यह पढ़ना सुरक्षित नहीं है। सटीक व्यवहार चुने गए मोड, फ़र्मवेयर और उपकरण पर निर्भर करता है, इसलिए उसका स्थान स्वीकृति मानदंडों में है, किसी अनुमान में नहीं।
तय करें कि सुरंग के बिना शाखा को अब भी क्या करना है: स्थानीय प्रिंटर तक पहुँचना, नाम हल करना, भुगतान लेना, या कुछ भी नहीं। फिर उस स्थिति को जानबूझकर जाँचें, सुरंग अवरुद्ध करके और शाखा को देखकर। जो शाखा चुपचाप DNS खो देती है वह ज़ोर से विफल होने वाली शाखा से बुरी है, क्योंकि सहायता डेस्क का फ़ोन घंटों बाद आता है। देखा गया परिणाम डिज़ाइन रिकॉर्ड में लिखें।
केंद्रीय निर्भरता हर मोड में एक जैसी है: किसी को उपकरण के अपने पुनर्प्राप्ति मार्ग का स्वामी होना चाहिए।
परिनियोजन से पहले शाखा अनुबंध लिखें
शाखा अनुबंध एक पृष्ठ में आ जाता है: मालिक, पता स्रोत, सुरंग से जाने वाले प्रीफ़िक्स, आउटलेट नीति और वह व्यवधान व्यवहार जो आपने स्वीकार किया।
फिर इच्छित नहीं, परिनियोजित परिणाम जाँचें। शाखा के क्लाइंट का पता, उसका डिफ़ॉल्ट गेटवे, कौन-से प्रीफ़िक्स सुरंग से हल होते हैं और सुरंग अवरुद्ध होने पर क्या अब भी उत्तर देता है, देखें। संगतता, पहुँच और लाइसेंसिंग सबको सटीक मॉडल के लिए विक्रेता के वर्तमान दस्तावेज़ के सामने जाँचना ज़रूरी है, क्योंकि उत्पाद का नाम किसी मोड की गारंटी नहीं देता। वह पृष्ठ उपकरण रिकॉर्ड के साथ रखें ताकि अगले अभियंता को आरेख नहीं, निर्णय विरासत में मिलें।
ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.exampleसुरंग अवरुद्ध रखकर वह ब्लॉक दोहराएँ, और दोनों रनों का अंतर वही व्यवधान व्यवहार है जो आपने वास्तव में खरीदा।