यो लेख "तपाईंको नेटवर्क पूर्वाधारको नियन्त्रण कसरी लिने" लेखहरूको श्रृंखलामा तेस्रो हो। श्रृंखला र लिङ्कहरूमा सबै लेखहरूको सामग्रीहरू फेला पार्न सकिन्छ यहाँ.

सुरक्षा जोखिमहरू पूर्ण रूपमा हटाउने कुरा गर्नुको कुनै अर्थ छैन। सिद्धान्तमा, हामी तिनीहरूलाई शून्यमा घटाउन सक्दैनौं। हामीले यो पनि बुझ्न आवश्यक छ कि हामी नेटवर्कलाई अझ बढी सुरक्षित बनाउन कोसिस गर्दैछौं, हाम्रा समाधानहरू थप महँगो हुँदै गइरहेका छन्। तपाईंले लागत, जटिलता, र सुरक्षा बीचको ट्रेड-अफ फेला पार्न आवश्यक छ जुन तपाईंको नेटवर्कको लागि अर्थपूर्ण हुन्छ।

निस्सन्देह, सुरक्षा डिजाइन समग्र वास्तुकलामा संगठित रूपमा एकीकृत गरिएको छ र प्रयोग गरिएको सुरक्षा समाधानहरूले नेटवर्क पूर्वाधारको स्केलेबिलिटी, विश्वसनीयता, व्यवस्थापन, ... लाई असर गर्छ, जसलाई पनि ध्यानमा राख्नुपर्छ।

तर म तपाईंलाई सम्झाउन चाहन्छु कि अब हामी नेटवर्क बनाउने कुरा गर्दैनौं। हाम्रो अनुसार प्रारम्भिक अवस्थाहरू हामीले पहिले नै डिजाइन छनोट गरिसकेका छौं, उपकरणहरू चयन गरिसकेका छौं, र पूर्वाधार सिर्जना गरेका छौं, र यस चरणमा, यदि सम्भव छ भने, हामीले पहिले नै छनौट गरिएको दृष्टिकोणको सन्दर्भमा "बाँच्न" र समाधानहरू खोज्नुपर्छ।

हाम्रो कार्य अब नेटवर्क स्तर मा सुरक्षा संग सम्बन्धित जोखिम को पहिचान र एक उचित स्तर मा कम गर्न को लागी छ।

नेटवर्क सुरक्षा अडिट

यदि तपाईंको संगठनले ISO 27k प्रक्रियाहरू लागू गरेको छ भने, सुरक्षा अडिटहरू र नेटवर्क परिवर्तनहरू यस दृष्टिकोण भित्रको समग्र प्रक्रियाहरूमा निर्बाध रूपमा फिट हुनुपर्छ। तर यी मापदण्डहरू अझै पनि विशेष समाधानहरूको बारेमा होइन, कन्फिगरेसनको बारेमा होइन, डिजाइनको बारेमा होइन... त्यहाँ कुनै स्पष्ट-कट सल्लाहहरू छैनन्, तपाईंको नेटवर्क कस्तो हुनुपर्छ भनेर विस्तृत रूपमा निर्देशन दिने कुनै मापदण्डहरू छैनन्, यो यस कार्यको जटिलता र सुन्दरता हो।

म धेरै सम्भावित नेटवर्क सुरक्षा अडिटहरू हाइलाइट गर्नेछु:

• उपकरण कन्फिगरेसन अडिट (कठोर)
• सुरक्षा डिजाइन लेखा परीक्षण
• पहुँच अडिट
• प्रक्रिया लेखापरीक्षण

उपकरण कन्फिगरेसन अडिट (कठोर)

यस्तो देखिन्छ कि धेरै जसो केसहरूमा यो तपाईको नेटवर्कको सुरक्षा र अडिट गर्नको लागि उत्तम सुरूवात बिन्दु हो। IMHO, यो Pareto को कानूनको राम्रो प्रदर्शन हो (20% प्रयासले 80% नतिजा उत्पादन गर्छ, र बाँकी 80% प्रयासले मात्र 20% परिणाम दिन्छ)।

मुख्य कुरा यो हो कि हामीसँग सामान्यतया उपकरणहरू कन्फिगर गर्दा सुरक्षाको लागि "उत्तम अभ्यासहरू" सम्बन्धी विक्रेताहरूबाट सिफारिसहरू हुन्छन्। यसलाई "हार्डनिंग" भनिन्छ।

तपाइँ प्राय: यी सिफारिसहरूको आधारमा प्रश्नावली (वा आफैं सिर्जना गर्नुहोस्) फेला पार्न सक्नुहुन्छ, जसले तपाइँलाई तपाइँको उपकरणको कन्फिगरेसनले यी "उत्तम अभ्यासहरू" लाई कत्तिको राम्रोसँग पालन गर्दछ भनेर निर्धारण गर्न मद्दत गर्दछ र परिणाम अनुसार, तपाइँको नेटवर्कमा परिवर्तनहरू गर्नुहोस्। । यसले तपाईंलाई सुरक्षा जोखिमहरू सजिलैसँग कम गर्न अनुमति दिनेछ, वास्तवमा कुनै पनि लागतमा।

केही सिस्को अपरेटिङ सिस्टमका लागि धेरै उदाहरणहरू।

सिस्को आईओएस कन्फिगरेसन हार्डनिङ
सिस्को IOS-XR कन्फिगरेसन हार्डनिङ
सिस्को NX-OS कन्फिगरेसन हार्डनिङ
सिस्को आधारभूत सुरक्षा जाँच सूची

यी कागजातहरूको आधारमा, प्रत्येक प्रकारका उपकरणहरूको लागि कन्फिगरेसन आवश्यकताहरूको सूची सिर्जना गर्न सकिन्छ। उदाहरण को लागी, एक Cisco N7K VDC को लागी यी आवश्यकताहरु जस्तै देखिन सक्छ त्यसैले.

यस तरिकाले, तपाइँको नेटवर्क पूर्वाधारमा विभिन्न प्रकारका सक्रिय उपकरणहरूको लागि कन्फिगरेसन फाइलहरू सिर्जना गर्न सकिन्छ। अर्को, म्यानुअल रूपमा वा स्वचालन प्रयोग गरेर, तपाइँ यी कन्फिगरेसन फाइलहरू "अपलोड" गर्न सक्नुहुन्छ। यस प्रक्रियालाई कसरी स्वचालित गर्ने भनेर अर्केस्ट्रेशन र स्वचालनमा लेखहरूको अर्को श्रृंखलामा विस्तृत रूपमा छलफल गरिनेछ।

सुरक्षा डिजाइन अडिट

सामान्यतया, इन्टरप्राइज नेटवर्कले निम्न खण्डहरू एक फारम वा अर्कोमा समावेश गर्दछ:

• DC (सार्वजनिक सेवा DMZ र इन्ट्रानेट डाटा केन्द्र)
• इन्टरनेट पहुँच
• रिमोट पहुँच VPN
• WAN किनारा
• साखा
• क्याम्पस (कार्यालय)
• कोर

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

यी प्रत्येक खण्डहरूको लागि, सुरक्षा आवश्यकताहरू, जोखिमहरू र, तदनुसार, समाधानहरू फरक हुनेछन्।

सुरक्षा डिजाइनको दृष्टिकोणबाट तपाईंले सामना गर्न सक्ने समस्याहरूको लागि तिनीहरूमध्ये प्रत्येकलाई अलग-अलग हेरौं। निस्सन्देह, म फेरि दोहोर्याउँछु कि यो लेख कुनै पनि हिसाबले पूर्ण भएको बहाना गर्दैन, जुन यो साँच्चै गहिरो र बहुआयामिक विषयमा प्राप्त गर्न सजिलो छैन (यदि असम्भव छैन), तर यसले मेरो व्यक्तिगत अनुभवलाई प्रतिबिम्बित गर्दछ।

त्यहाँ कुनै उत्तम समाधान छैन (कम्तिमा अझै छैन)। यो सधैं एक सम्झौता हो। तर यो महत्त्वपूर्ण छ कि एक वा अर्को दृष्टिकोण प्रयोग गर्ने निर्णय यसको फाइदा र बेफाइदा दुवैको बुझाइका साथ सचेत रूपमा लिइन्छ।

डेटा केन्द्र

सुरक्षा दृष्टिकोणबाट सबैभन्दा महत्वपूर्ण खण्ड।
र, सामान्य रूपमा, यहाँ पनि कुनै विश्वव्यापी समाधान छैन। यो सबै नेटवर्क आवश्यकताहरु मा धेरै निर्भर गर्दछ।

फायरवाल आवश्यक छ कि छैन?

यस्तो देखिन्छ कि जवाफ स्पष्ट छ, तर सबै कुरा स्पष्ट रूपमा यो देखिन्छ जस्तो लाग्दैन। र तपाईंको छनौट मात्र प्रभावित हुन सक्छ मूल्य.

उदाहरण 1। ढिलाइ।

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

उदाहरण 2। प्रदर्शन।

शीर्ष L3 स्विचहरूको थ्रुपुट सामान्यतया सबैभन्दा शक्तिशाली फायरवालहरूको थ्रुपुट भन्दा ठूलो परिमाणको आदेश हो। तसर्थ, उच्च-तीव्रता ट्राफिकको अवस्थामा, तपाईंले यो ट्राफिकलाई फायरवालहरू बाइपास गर्न अनुमति दिनुपर्नेछ।

उदाहरण 3। विश्वसनीयता।

फायरवालहरू, विशेष गरी आधुनिक NGFW (Next-generation FW) जटिल यन्त्रहरू हुन्। तिनीहरू L3/L2 स्विचहरू भन्दा धेरै जटिल छन्। तिनीहरूले सेवाहरू र कन्फिगरेसन विकल्पहरूको एक ठूलो संख्या प्रदान गर्दछ, त्यसैले यो आश्चर्यजनक छैन कि तिनीहरूको विश्वसनीयता धेरै कम छ। यदि सेवा निरन्तरता नेटवर्कको लागि महत्त्वपूर्ण छ भने, तपाईंले राम्रो उपलब्धताको लागि के नेतृत्व गर्ने छ भनेर छनौट गर्नुपर्ने हुन सक्छ - फायरवालको साथ सुरक्षा वा नियमित ACLs प्रयोग गरेर स्विचहरू (वा विभिन्न प्रकारका कपडाहरू) मा निर्मित नेटवर्कको सरलता।

माथिका उदाहरणहरूको मामलामा, तपाईंले प्रायः सम्भवतः (सामान्य रूपमा) सम्झौता खोज्नुपर्छ। निम्न समाधानहरू हेर्नुहोस्:

• यदि तपाइँ डाटा सेन्टर भित्र फायरवालहरू प्रयोग नगर्ने निर्णय गर्नुहुन्छ भने, तपाइँले कसरी सम्भव भएसम्म परिधि वरिपरि पहुँच सीमित गर्ने बारे सोच्न आवश्यक छ। उदाहरणका लागि, तपाईंले इन्टरनेटबाट आवश्यक पोर्टहरू मात्र खोल्न सक्नुहुन्छ (क्लाइन्ट ट्राफिकका लागि) र जम्प होस्टहरूबाट मात्र डाटा सेन्टरमा प्रशासनिक पहुँच। जम्प होस्टहरूमा, सबै आवश्यक जाँचहरू गर्नुहोस् (प्रमाणीकरण/प्राधिकरण, एन्टिभाइरस, लगिङ, ...)
• तपाईंले PSEFABRIC मा वर्णन गरिएको योजना जस्तै खण्डहरूमा डाटा सेन्टर नेटवर्कको तार्किक विभाजन प्रयोग गर्न सक्नुहुन्छ। उदाहरण p002। यस अवस्थामा, राउटिङ यस्तो तरिकाले कन्फिगर गरिनु पर्छ कि ढिलाइ-संवेदनशील वा उच्च-तीव्रता ट्राफिक एक खण्ड (p002, VRF को मामला मा) "भित्र" जान्छ र फायरवाल मार्फत जाँदैन। विभिन्न खण्डहरू बीचको ट्राफिक फायरवाल मार्फत जारी रहनेछ। तपाईंले फायरवाल मार्फत ट्राफिक रिडिरेक्ट गर्नबाट बच्न VRF हरू बीचको मार्ग चुहावट पनि प्रयोग गर्न सक्नुहुन्छ
• तपाईंले पारदर्शी मोडमा फायरवाल प्रयोग गर्न सक्नुहुन्छ र ती VLAN हरूका लागि मात्र जहाँ यी कारकहरू (विलम्बता/कार्यसम्पादन) महत्त्वपूर्ण छैनन्। तर तपाईले प्रत्येक विक्रेताको लागि यस मोडको प्रयोगसँग सम्बन्धित प्रतिबन्धहरू ध्यानपूर्वक अध्ययन गर्न आवश्यक छ
• तपाईं सेवा श्रृंखला वास्तुकला प्रयोग गर्न विचार गर्न सक्नुहुन्छ। यसले फायरवाल मार्फत मात्र आवश्यक ट्राफिकलाई अनुमति दिनेछ। सिद्धान्तमा राम्रो देखिन्छ, तर मैले उत्पादनमा यो समाधान कहिल्यै देखेको छैन। हामीले लगभग 5 वर्ष पहिले Cisco ACI/Juniper SRX/F3 LTM को लागि सेवा श्रृंखला परीक्षण गर्‍यौं, तर त्यो समयमा यो समाधान हामीलाई "कच्चा" जस्तो लाग्यो।

सुरक्षा स्तर

अब तपाईले ट्राफिक फिल्टर गर्न कुन उपकरणहरू प्रयोग गर्न चाहनुहुन्छ भन्ने प्रश्नको जवाफ दिन आवश्यक छ। यहाँ केहि सुविधाहरू छन् जुन सामान्यतया NGFW मा उपस्थित हुन्छन् (उदाहरणका लागि, यहाँ):

• स्टेटफुल फायरवालिङ (पूर्वनिर्धारित)
• आवेदन फायरवालिङ
• खतरा रोकथाम (एन्टिभाइरस, एन्टि-स्पाइवेयर, र जोखिम)
• URL फिल्टरि filter
• डाटा फिल्टरिङ (सामग्री फिल्टरिङ)
• फाइल अवरुद्ध (फाइल प्रकार अवरुद्ध)
• dos संरक्षण

र सबै कुरा स्पष्ट पनि छैन। यस्तो देखिन्छ कि सुरक्षा को उच्च स्तर, राम्रो। तर तपाईले यो पनि विचार गर्न आवश्यक छ

• तपाईंले जति धेरै माथिको फायरवाल प्रकार्यहरू प्रयोग गर्नुहुन्छ, यो स्वाभाविक रूपमा महँगो हुनेछ (लाइसेन्स, अतिरिक्त मोड्युलहरू)
• केही एल्गोरिदमहरूको प्रयोगले फायरवाल थ्रुपुटलाई उल्लेखनीय रूपमा घटाउन सक्छ र ढिलाइ पनि बढाउन सक्छ, उदाहरणका लागि हेर्नुहोस् यहाँ
• कुनै पनि जटिल समाधान जस्तै, जटिल सुरक्षा विधिहरूको प्रयोगले तपाइँको समाधानको विश्वसनीयता कम गर्न सक्छ, उदाहरणका लागि, अनुप्रयोग फायरवालिङ प्रयोग गर्दा, मैले केही धेरै मानक काम गर्ने अनुप्रयोगहरू (dns, smb) को अवरुद्ध सामना गरें।

सधैंको रूपमा, तपाईंले आफ्नो नेटवर्कको लागि उत्तम समाधान खोज्न आवश्यक छ।

कुन सुरक्षा कार्यहरू आवश्यक हुन सक्छ भन्ने प्रश्नको निश्चित रूपमा जवाफ दिन असम्भव छ। पहिलो, किनभने यो पक्कै पनि तपाईंले प्रसारण वा भण्डारण गर्दै र सुरक्षित गर्न प्रयास गरिरहनुभएको डाटामा निर्भर गर्दछ। दोस्रो, वास्तवमा, प्रायः सुरक्षा उपकरणहरूको छनौट विक्रेतामा विश्वास र विश्वासको कुरा हो। तपाईंलाई एल्गोरिदमहरू थाहा छैन, तपाईंलाई थाहा छैन कि तिनीहरू कत्तिको प्रभावकारी छन्, र तपाईंले तिनीहरूलाई पूर्ण रूपमा परीक्षण गर्न सक्नुहुन्न।

त्यसकारण, महत्वपूर्ण खण्डहरूमा, राम्रो समाधान विभिन्न कम्पनीहरूबाट प्रस्तावहरू प्रयोग गर्न हुन सक्छ। उदाहरणका लागि, तपाईंले फायरवालमा एन्टिभाइरस सक्षम गर्न सक्नुहुन्छ, तर स्थानीय रूपमा होस्टहरूमा एन्टिभाइरस सुरक्षा (अर्को निर्माताबाट) प्रयोग गर्नुहोस्।

विभाजन

हामी डाटा केन्द्र नेटवर्क को तार्किक विभाजन को बारे मा कुरा गर्दै छन्। उदाहरणका लागि, VLAN र सबनेटहरूमा विभाजन गर्नु पनि तार्किक विभाजन हो, तर हामी यसको स्पष्टताका कारण विचार गर्दैनौं। FW सुरक्षा क्षेत्रहरू, VRFs (र विभिन्न विक्रेताहरूको सम्बन्धमा तिनीहरूका एनालॉगहरू), तार्किक उपकरणहरू (PA VSYS, Cisco N7K VDC, Cisco ACI टेनेन्ट, ...), ... जस्ता संस्थाहरूलाई ध्यानमा राखेर रोचक विभाजन।

यस्तो तार्किक विभाजन को एक उदाहरण र हाल मा मांग डाटा केन्द्र डिजाइन मा दिइएको छ PSEFABRIC परियोजनाको p002.

तपाईको नेटवर्कको तार्किक भागहरू परिभाषित गरिसकेपछि, तपाईले वर्णन गर्न सक्नुहुन्छ कि कसरी ट्राफिक विभिन्न खण्डहरू बीचमा सर्छ, कुन उपकरणहरूमा फिल्टरिङ प्रदर्शन गरिनेछ र कुन माध्यमबाट।

यदि तपाइँको सञ्जालमा स्पष्ट तार्किक विभाजन छैन र विभिन्न डेटा प्रवाहहरूको लागि सुरक्षा नीतिहरू लागू गर्ने नियमहरू औपचारिक छैनन् भने, यसको मतलब यो हो कि जब तपाइँ यो वा त्यो पहुँच खोल्नुहुन्छ, तपाइँ यो समस्या समाधान गर्न बाध्य हुनुभयो, र उच्च सम्भावनाको साथ तपाइँ। हरेक पटक फरक तरिकाले समाधान गर्नेछ।

प्राय: विभाजन FW सुरक्षा क्षेत्रहरूमा आधारित हुन्छ। त्यसपछि तपाईंले निम्न प्रश्नहरूको जवाफ दिन आवश्यक छ:

• तपाईलाई कुन सुरक्षा क्षेत्र चाहिन्छ
• तपाइँ यी प्रत्येक क्षेत्रहरूमा कुन स्तरको सुरक्षा लागू गर्न चाहनुहुन्छ
• के पूर्वनिर्धारित रूपमा इन्ट्रा-जोन ट्राफिकलाई अनुमति दिइनेछ?
• यदि होइन भने, प्रत्येक क्षेत्र भित्र कुन ट्राफिक फिल्टरिंग नीतिहरू लागू हुनेछन्
• प्रत्येक जोडी क्षेत्र (स्रोत/गन्तव्य) को लागि कुन ट्राफिक फिल्टरिंग नीतिहरू लागू हुनेछन्

TCAM

एक सामान्य समस्या अपर्याप्त TCAM (Ternary Content Addressable Memory), दुबै मार्ग र पहुँचका लागि हो। IMHO, उपकरण छनोट गर्दा यो सबैभन्दा महत्त्वपूर्ण मुद्दाहरू मध्ये एक हो, त्यसैले तपाईंले यो समस्यालाई उचित स्तरको हेरचाहको साथ व्यवहार गर्न आवश्यक छ।

उदाहरण १. फर्वार्डिङ तालिका TCAM।

विचार गरौं पालो अल्टो ७ के फायरवाल
हामी देख्छौं कि IPv4 फर्वार्डिङ तालिका आकार* = 32K
यसबाहेक, मार्गहरूको यो संख्या सबै VSYS को लागि साझा छ।

मानौं कि तपाइँको डिजाइन अनुसार तपाइँ 4 VSYS प्रयोग गर्ने निर्णय गर्नुहुन्छ।
यी प्रत्येक VSYS हरू BGP मार्फत क्लाउडको दुई MPLS PEs मा जडान गरिएको छ जुन तपाईंले BB को रूपमा प्रयोग गर्नुहुन्छ। यसरी, 4 VSYS ले सबै विशिष्ट मार्गहरू एकअर्कासँग साटासाट गर्छन् र लगभग एउटै सेटहरू (तर भिन्न NHs) भएको फर्वार्डिङ तालिका छ। किनभने प्रत्येक VSYS सँग 2 BGP सत्रहरू छन् (एउटै सेटिङहरूसँग), त्यसपछि MPLS मार्फत प्राप्त प्रत्येक मार्गमा 2 NH र तदनुसार, फर्वार्डिङ तालिकामा 2 FIB प्रविष्टिहरू छन्। यदि हामीले डाटा सेन्टरमा यो एक मात्र फायरवाल हो र यसले सबै रुटहरूको बारेमा थाहा पाउनुपर्छ भनी मान्दछौं भने, यसको अर्थ हाम्रो डेटा सेन्टरमा कुल रुटहरूको संख्या ३२K/(४*२) = ४K भन्दा बढी हुन सक्दैन।

अब, यदि हामीसँग २ डाटा सेन्टरहरू छन् (एउटै डिजाइनका साथ), र हामी डाटा केन्द्रहरू (उदाहरणका लागि, vMotion को लागि) बीच VLAN हरू "स्ट्रेच" प्रयोग गर्न चाहन्छौं भने, राउटिंग समस्या समाधान गर्न, हामीले होस्ट मार्गहरू प्रयोग गर्नुपर्छ। । तर यसको मतलब यो हो कि २ डाटा केन्द्रहरूको लागि हामीसँग 2 भन्दा बढी सम्भावित होस्टहरू हुनेछैनन् र निस्सन्देह, यो पर्याप्त नहुन सक्छ।

उदाहरण २. ACL TCAM।

यदि तपाइँ L3 स्विचहरू (वा L3 स्विचहरू प्रयोग गर्ने अन्य समाधानहरू, उदाहरणका लागि, Cisco ACI) मा ट्राफिक फिल्टर गर्ने योजना बनाउनुहुन्छ भने, उपकरण छनोट गर्दा तपाईंले TCAM ACL मा ध्यान दिनुपर्छ।

मानौं कि तपाइँ सिस्को क्याटालिस्ट 4500 को SVI इन्टरफेसहरूमा पहुँच नियन्त्रण गर्न चाहनुहुन्छ। त्यसपछि, बाट देख्न सकिन्छ। यो लेख, इन्टरफेसहरूमा बहिर्गमन (साथै आगमन) ट्राफिक नियन्त्रण गर्न, तपाईंले 4096 TCAM लाइनहरू मात्र प्रयोग गर्न सक्नुहुन्छ। जुन TCAM3 प्रयोग गर्दा तपाईंलाई लगभग 4000 हजार ACEs (ACL लाइनहरू) दिनेछ।

यदि तपाइँ अपर्याप्त TCAM को समस्या संग सामना गर्दै हुनुहुन्छ भने, सबै भन्दा पहिले, अवश्य पनि, तपाइँ अनुकूलन को संभावना विचार गर्न आवश्यक छ। त्यसोभए, फर्वार्डिङ तालिकाको आकारको साथ समस्याको अवस्थामा, तपाईंले मार्गहरू जम्मा गर्ने सम्भावनालाई विचार गर्न आवश्यक छ। पहुँचहरूका लागि TCAM साइजमा समस्या भएमा, अडिट पहुँचहरू, पुरानो र ओभरल्यापिङ रेकर्डहरू हटाउनुहोस्, र सम्भवतः पहुँचहरू खोल्ने प्रक्रियालाई परिमार्जन गर्नुहोस् (अडिटिङ पहुँचहरूको अध्यायमा विस्तारमा छलफल गरिनेछ)।

उच्च उपलब्धता

प्रश्न यो छ: के मैले फायरवालहरूको लागि HA प्रयोग गर्नुपर्छ वा दुईवटा स्वतन्त्र बक्सहरू "समानान्तरमा" स्थापना गर्नुपर्छ र, यदि ती मध्ये एउटा असफल भयो भने, दोस्रो मार्फत ट्राफिकलाई रुट गर्ने?

यस्तो देखिन्छ कि जवाफ स्पष्ट छ - HA प्रयोग गर्नुहोस्। यो प्रश्न अझै उठ्नुको कारण यो हो कि, दुर्भाग्यवश, सैद्धान्तिक र विज्ञापन 99 र व्यवहारमा पहुँचको धेरै दशमलव प्रतिशत धेरै गुलाबी देखि टाढा छ। HA तार्किक रूपमा एकदम जटिल चीज हो, र विभिन्न उपकरणहरूमा, र विभिन्न विक्रेताहरूसँग (त्यहाँ कुनै अपवाद थिएन), हामीले समस्याहरू र बगहरू र सेवा बन्दहरू समात्यौं।

यदि तपाइँ HA प्रयोग गर्नुहुन्छ भने, तपाइँसँग व्यक्तिगत नोडहरू बन्द गर्ने अवसर हुनेछ, सेवा रोक्न बिना तिनीहरू बीच स्विच गर्नुहोस्, जुन महत्त्वपूर्ण छ, उदाहरणका लागि, अपग्रेड गर्दा, तर एकै समयमा तपाइँसँग शून्य सम्भावनाबाट टाढा छ कि दुबै नोडहरू। एकै समयमा ब्रेक हुनेछ, र यो पनि कि अर्को अपग्रेड विक्रेताले वाचा गरे जस्तै सहज रूपमा जानेछैन (यदि तपाइँसँग प्रयोगशाला उपकरणहरूमा अपग्रेड परीक्षण गर्ने अवसर छ भने यो समस्याबाट बच्न सकिन्छ)।

यदि तपाइँ HA प्रयोग गर्नुहुन्न भने, दोहोरो असफलताको दृष्टिकोणबाट तपाइँको जोखिम धेरै कम छ (किनकि तपाइँसँग 2 स्वतन्त्र फायरवालहरू छन्), तर ... सत्रहरू सिङ्क्रोनाइज हुँदैनन्, त्यसपछि प्रत्येक पटक तपाईंले यी फायरवालहरू बीच स्विच गर्दा तपाईंले ट्राफिक गुमाउनु हुनेछ। तपाईले, अवश्य पनि, स्टेटलेस फायरवालिङ प्रयोग गर्न सक्नुहुन्छ, तर त्यसपछि फायरवाल प्रयोग गर्ने बिन्दु धेरै हदसम्म हराएको छ।

तसर्थ, यदि लेखापरीक्षणको परिणाम स्वरूप तपाईंले एक्लो फायरवालहरू फेला पार्नुभयो, र तपाईं आफ्नो नेटवर्कको विश्वसनीयता बढाउने बारे सोच्दै हुनुहुन्छ भने, HA, अवश्य पनि, सिफारिस गरिएका समाधानहरू मध्ये एक हो, तर तपाईंले सम्बन्धित बेफाइदाहरूलाई पनि ध्यानमा राख्नुपर्छ। यस दृष्टिकोणको साथ र, सायद, विशेष गरी तपाईको नेटवर्कको लागि, अर्को समाधान अधिक उपयुक्त हुनेछ।

व्यवस्थापन क्षमता

सिद्धान्तमा, HA नियन्त्रणको बारेमा पनि हो। २ वटा बाकसहरू छुट्टाछुट्टै कन्फिगर गर्नुको सट्टा र कन्फिगरेसनहरूलाई सिङ्कमा राख्ने समस्याको सामना गर्नुको सट्टा, तपाईंले तिनीहरूलाई एउटा यन्त्र भए जस्तै व्यवस्थापन गर्नुहुन्छ।

तर सायद तपाईंसँग धेरै डाटा सेन्टरहरू र धेरै फायरवालहरू छन्, त्यसपछि यो प्रश्न नयाँ स्तरमा उठ्छ। र प्रश्न कन्फिगरेसनको बारेमा मात्र होइन, तर यसको बारेमा पनि हो

• ब्याकअप कन्फिगरेसनहरू
• अपडेटहरू
• अपग्रेडहरू
• निगरानी
• लगिङ

र यो सबै केन्द्रीकृत व्यवस्थापन प्रणाली द्वारा हल गर्न सकिन्छ।

त्यसोभए, उदाहरणका लागि, यदि तपाइँ पालो अल्टो फायरवालहरू प्रयोग गर्दै हुनुहुन्छ भने, त्यसपछि Panorama यस्तो समाधान छ।

फेरि जारी राखौंला।

स्रोत: www.habr.com