नेटवर्क टोपोलॉजी में केंद्रीकृत फ़ायरवॉल फिट करने की कोशिश कर रहा है


11

मैं अपने नेटवर्क को ओवर-हाऊलिंग करने की प्रक्रिया में हूं, जिस मुद्दे को मैं वापस ले रहा हूं, वह है: परत 3 को कोर में लाने की कोशिश करना, जबकि अभी भी एक केंद्रीकृत फ़ायरवॉल है।

मेरे पास मुख्य मुद्दा यह है कि "मिनी कोर" स्विच जो मैं हमेशा देख रहा हूं उनमें हार्डवेयर एसीएल सीमाएं कम हैं, जो कि हमारे वर्तमान आकार पर भी हम जल्दी से हिट कर सकते हैं। मैं वर्तमान में (उम्मीद है) कोर के लिए EX4300-32Fs की एक जोड़ी खरीद रहा हूं, लेकिन मैंने जुनिपर और ब्रोकेड के आईसीएक्स रेंज के अन्य विकल्पों पर ध्यान दिया है। उन सभी को एसीएल की समान सीमाएं लगती हैं।

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

हालाँकि, हम ज्यादातर पूरी तरह से प्रबंधित सर्वर करते हैं, और एक केंद्रीकृत (स्टेटफुल) फ़ायरवॉल उस प्रबंधन के साथ बहुत मदद करता है - क्योंकि हम ग्राहकों को सीधे एक दूसरे से बात नहीं कर सकते हैं। मैं इसे उस तरह से रखना चाहूंगा यदि हम कर सकते हैं, लेकिन मुझे लगता है कि हालांकि अधिकांश आईएसपी नेटवर्क इस तरह का काम नहीं करेंगे, इसलिए ज्यादातर मामलों में यह कोर में राउटिंग करने के लिए सीधे-आगे होगा।

संदर्भ के लिए, यहाँ टोपोलॉजी है जो मैं आदर्श रूप से करना चाहूंगा (लेकिन निश्चित रूप से एफडब्ल्यू स्पष्ट रूप से फिट नहीं होना चाहिए)।

नेटवर्क

करंट सॉल्यूशन

अभी, हमारे पास एक राउटर-ऑन-ए-स्टिक कॉन्फ़िगरेशन है। यह हमें NAT, स्टेटफुल फायरवॉल और वीएलएएन सब एक ही स्थान पर रूट करने में सक्षम बनाता है। बहुत आसान।

मैं सीमा नेटवर्क को "टॉप" करने के लिए L2 को सभी तरह से बढ़ाकर (लगभग) उसी समाधान के साथ जारी रख सकता हूं। लेकिन फिर मैं वायर-स्पीड रूटिंग के सभी लाभों को खो देता हूं जो कोर मुझे दे सकते हैं।

IIRC कोर स्विच राउटिंग के 464 Gbps कर सकता है, जबकि मेरे बॉर्डर रूटर्स 10 या 20 Gbps की पेशकश कर पाएंगे, अगर मैं भाग्यशाली हूं। यह अभी तकनीकी रूप से समस्या नहीं है, लेकिन विकास का मुद्दा है। मुझे लगता है कि अगर हम आर्किटेक्चर को मूल मार्ग क्षमता का लाभ उठाने के लिए डिज़ाइन नहीं करते हैं, तो यह सब कुछ फिर से करने के लिए दर्दनाक होने वाला है जब हम बड़े होते हैं और उस क्षमता का लाभ उठाने की आवश्यकता होती है। मैं नहीं बल्कि यह पहली बार मिल जाएगा।

संभव समाधान

लेयर 3 से एक्सेस

मुझे लगा कि शायद मैं एल 3 को एक्सेस स्विच तक बढ़ा सकता हूं, और इस तरह फ़ायरवॉल नियमों को छोटे सेगमेंट में तोड़ सकता हूं जो तब एक्सेस स्विच एसीएल की हार्डवेयर सीमा पर फिट होंगे। परंतु:

  • जहां तक ​​मुझे पता है, ये स्टेटफुल एसीएल नहीं होंगे
  • मेरे लिए एल 3, बहुत अधिक अनम्य लगता है। अन्य मंत्रिमंडलों के लिए सर्वर चाल या वीएम माइग्रेशन अधिक दर्दनाक होगा।
  • अगर मैं प्रत्येक रैक (उनमें से केवल छह) के शीर्ष पर एक फ़ायरवॉल का प्रबंधन करने जा रहा हूं, तो मैं शायद वैसे भी स्वचालन चाहता हूं। तो उस बिंदु पर यह मेजबान स्तर पर फायरवॉल के प्रबंधन को स्वचालित करने के लिए एक छलांग नहीं है। इस प्रकार पूरे मामले से बचना।

एक्सेस / कोर के बीच प्रत्येक अपलिंक पर ब्रिजेड / पारदर्शी फायरवॉल

इसमें कई फ़ायरवॉल बॉक्स को शामिल करना होगा, और आवश्यक हार्डवेयर को महत्वपूर्ण रूप से बढ़ाना होगा। और बड़े कोर राउटर खरीदने की तुलना में अधिक महंगा हो सकता है, यहां तक ​​कि फायरवॉल के रूप में सादे पुराने लिनक्स बक्से का उपयोग करना।

विशाल कोर रूटर्स

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

कोई केंद्रीकृत फ़ायरवॉल नहीं

चूंकि मैं हुप्स के माध्यम से कूद रहा हूं, शायद यह प्रयास के लायक नहीं है। यह हमेशा एक अच्छी बात रही है, और कई बार उन ग्राहकों के लिए एक विक्रय बिंदु जो "हार्डवेयर" फ़ायरवॉल चाहते हैं।

लेकिन ऐसा लगता है कि आपके "संपूर्ण" नेटवर्क के लिए एक केंद्रीकृत फ़ायरवॉल होना संभव नहीं है। मैं सोच रहा हूँ, तब, आईएसपी समर्पित सर्वरों के साथ ग्राहकों को हार्डवेयर फ़ायरवॉल समाधान की पेशकश कर सकते हैं, जब उनके पास सैकड़ों या हजारों होस्ट होते हैं?

क्या कोई इस मुद्दे को हल करने के तरीके के बारे में सोच सकता है? या तो कुछ मैं पूरी तरह से याद किया है, या ऊपर विचारों में से एक पर एक बदलाव?

अद्यतन 2014-06-16:

@ रॉन के सुझाव के आधार पर, मैंने इस लेख पर ठोकर खाई, जो इस मुद्दे को अच्छी तरह समझाता है, और समस्या को हल करने का एक अच्छा तरीका है।

जब तक अन्य सुझाव न हों, मैं कहूंगा कि यह अब एक उत्पाद सिफारिश प्रकार की समस्या है, इसलिए मुझे लगता है कि इसका अंत है।

http://it20.info/2011/03/the-93-000-firewall-rules-problem-and-why-cloud-is-not-just-orchestration/


क्या आप नेटवर्क में वीआरएफ-लाइट या एमपीएलएस का उपयोग कर रहे हैं? कोर स्विच किस ब्रांड के हैं?
डेनियल डिब

@DanielDib अभी तक VRF या MPLS का उपयोग नहीं कर रहा है, लेकिन मैं इसे इस साइट और किसी अन्य साइट के बीच तैनात करने की योजना बना रहा हूं। ब्रांड अभी तक निश्चित नहीं है (अभी भी खरीद सूची का पता लगा रहा है) ... लेकिन अभी ज्यादातर जुनिपर EX4300-32F या ब्रोकेड ICX 6610-48-PE
Geekman

1
मैंने बंद करने के लिए मतदान किया है; कारण यह है कि आप जो सवाल पूछ रहे हैं, वह आपके समाधान के लिए बहुत ही विशिष्ट विवरण में है जैसे कि कौन सा विक्रेता / मॉडल चुनने और बजट की कमी आदि के लिए मॉडल बनाता है, यह आपके ग्राहकों के लिए आपके उत्पाद की पेशकश को कैसे बदल देगा ... यह सब यहां उपयुक्त नहीं है। , वे व्यावसायिक निर्णय हैं। आप पूछ सकते हैं कि प्रत्येक टोपोलॉजी के प्रो और कोन क्या हैं, लेकिन कोई भी वास्तव में आपको यह नहीं बता सकता है कि आपके लिए सबसे अच्छा क्या है।
jwbensley

1
आपकी स्थिति पर मेरी दो पेंस है; क्या आपने फ़ायरवॉल पर विचार किया है जो सिस्को एएसएएस जैसे संदर्भों का समर्थन करता है, या सिर्फ आभासी फ़ायरवॉल भी है? कुछ वीएम होस्ट करें जो आप प्रत्येक ग्राहक के लिए दो इंटरफेस के साथ फायरवॉल स्पिन कर सकते हैं, एक जिसे आप ग्राहक वीएलएएन में डिफ़ॉल्ट गेटवे के रूप में छोड़ते हैं और एक जिसे आप अपने किनारे के राउटर की ओर वीएलएएन का सामना कर रहे सार्वजनिक में डुबोते हैं। बस एक विचार (मैं आभासी फ़ायरवॉल पसंद करता हूं)।
jwbensley

2
मैं सिस्को एएसए 1000V या कैटबर्ड (catbird.com) जैसे आभासी रूप से फायरवॉल को गंभीरता से देखूंगा। इस तरह, आप प्रत्येक व्रोक पर एक फ़ायरवॉल रख सकते हैं। अपनी पहुंच सूचियों को अपने कोर राउटर से दूर रखें।
रॉन ट्रंक

जवाबों:


5

मैं दो विकल्पों में से एक चुनूँगा:

व्यक्तिगत प्रति-किरायेदार वर्चुअल फ़ायरवॉल

पेशेवरों:

  • क्षैतिज रूप से स्केलेबल
  • स्पिन-अप और स्पिन-डाउन
  • भावी टोपोलॉजी / डिजाइन परिवर्तनों के लिए अपेक्षाकृत प्रतिरक्षा
  • पूर्ण ग्राहक अलगाव / अलगाव

विपक्ष:

  • जब तक आप एक मानक टेम्पलेट लागू नहीं करते हैं, तब आपके पास प्रबंधन करने के लिए n व्यक्तिगत फायरवॉल है
  • अब आपके पास मॉनिटर करने के लिए n अलग-अलग फायरवॉल हैं
  • अब आपके पास पैच करने के लिए अलग-अलग फायरवॉल हैं

एक राउटर-इंस्टेंस / संदर्भ प्रति किरायेदार के साथ बड़े फ़ायरवॉल चेसिस / क्लस्टर

अपने कोर के किनारे पर लटक रहे एक बड़े केंद्रीय फ़ायरवॉल (क्लस्टर) को तैनात करें, और ट्रैफ़िक को रूट करने और उस पर वापस जाने के लिए एक आंतरिक और बाहरी रूटिंग-इंस्टेंस का उपयोग करें (जैसे: आंतरिक उदाहरण पर डिफ़ॉल्ट गेटवे फ़ायरवॉल, डिफ़ॉल्ट गेटवे है फ़ायरवॉल कोर पर आपका बाहरी उदाहरण है और बाहरी उदाहरण के लिए डिफ़ॉल्ट आपकी सीमा है।)

पेशेवरों:

  • प्रबंधन और कॉन्फ़िगर करने के लिए एकल बॉक्स
  • मॉनिटर करने के लिए सिंगल बॉक्स
  • पैच करने के लिए सिंगल बॉक्स
  • ग्राहक अलग करना

विपक्ष:

  • दिन एक लागत अधिक हो जाएगा
  • नीचे कोई स्केलिंग नहीं
  • कॉन्फ़िगरेशन के आधार पर अंतर-ग्राहक ट्रैफ़िक आपके बॉर्डर राउटरों में रूट करना शुरू कर सकता है

0

आप कौन से कोर स्विच चला रहे हैं? नीतियां आमतौर पर वितरण परत पर की जाती हैं, यदि आप ढह चुके कोर डिज़ाइन के साथ जा रहे हैं, तो कोर को आपकी आवश्यकताओं को संभालने में सक्षम होना चाहिए। इसके अलावा, क्या आप स्टेटफुल इंस्पेक्शन या सिर्फ एक्सेल के लिए पसंद कर रहे हैं। यदि आपके पास कोई पालन करने की आवश्यकता है, तो एसेल्स पर्याप्त नहीं हो सकते हैं।

व्यक्तिगत रूप से, मैं एक फ़ायरवॉल के साथ जाऊंगा, शायद एक की तलाश करें जिसे क्लस्टर किया जा सकता है ताकि आप एक-दूसरे को क्लस्टर कर सकें और केंद्र के प्रबंधित नियम को बनाए रख सकें, जैसे कि एक स्रोत फ़ायरवॉल।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.