EVPN फायरवाल नीति: केन्द्रीकृत गेटवे र वितरित IRB
केन्द्रीकृत गेटवेहरू भाडावालको ट्राफिक फायरवालबाट पठाउँछन्, वितरित IRB पठाउँदैन। कुन कहाँ निरीक्षण गर्छ र छिटो मार्गलाई के चाहिन्छ तुलना गर्नुहोस्।
दुई EVPN डिजाइनले भाडावालको गेटवे फरक फरक ठाउँमा राख्छन्, र फायरवालले प्रत्येकमा फरक ट्राफिक देख्छ। केन्द्रीकृत गेटवेमा, सबनेटहरूबीचको ट्राफिक फायरवालसम्म पुग्छ किनकि राउटिङ त्यहीँ हुन्छ। वितरित IRB मा, leaf स्विचहरू स्थानीय रूपमा राउट गर्छन् र तपाईंले जानाजानी त्यो भित्र नहालेसम्म फायरवालले केही देख्दैन। कुनै पनि मोडेल गलत होइन। गलत त्यो हो कि सीमानामा फायरवाल जोडेर fabric ले ट्राफिक त्यहाँसम्म पुर्याउँछ भनी मान्नु।
दुई मोडेल, दुई फरक निरीक्षण बिन्दु
पहिले निरीक्षण चाहिने प्रवाहहरूको नाम लिनुहोस्, किनकि दुवै मोडेलले तिनलाई फरक तरिकाले व्यवहार गर्छन्।
| Flow class | Centralized gateway | Distributed IRB |
|---|---|---|
| Same subnet | Bridged, not routed | Bridged, not routed |
| Inter-subnet | Routed at the firewall | Routed at the leaf |
| Inter-VRF | At the firewall | Needs leaking or service insertion |
| External | Border firewall | Border firewall |
एउटै सबनेटभित्रको ट्राफिक त्यो पङ्क्ति हो जुन मानिसहरू बिर्सन्छन्। एउटै VLAN का दुई होस्टहरू ब्रिजिङमार्फत कुरा गर्छन्, र त्यो मार्गमा कुनै राउटेड फायरवाल हुँदैन, जबसम्म अलग तह 2 निरीक्षण डिजाइनले त्यसलाई रोक्दैन। यो दुवै मोडेलमा सत्य हो, त्यसैले यो डिजाइनको कमी हो, तिनीहरूबीचको तुलना होइन।
बाँकी तीन पङ्क्ति त्यहाँ हुन् जहाँ मोडेलहरू साँच्चै फरक हुन्छन्।
केन्द्रीकृत गेटवे: सरल निरीक्षण, वास्तविक ट्रान्जिट लागत
भाडावालको VLAN लाई तह 2 सेवा को रूपमा राख्नुहोस् र तिनका राउटिङ गेटवे फायरवालमा राख्नुहोस्। सबनेटहरूबीचको ट्राफिक त्यसपछि त्यो गेटवेमा जान्छ र फर्कन्छ, दुवै होस्ट एउटै leaf मा हुँदा पनि हुनसक्छ। निरीक्षण बिन्दु स्पष्ट छ, र त्यही यो डिजाइनको सम्पूर्ण तर्क हो। लागत फायरवालमा ट्रान्जिट भार र अब तपाईंले इन्जिनियर गर्नुपर्ने केन्द्रीय क्षमता तथा उपलब्धता निर्भरता हो।
परिवर्तनलाई तपाईंले लक्षित गरेका भाडावाल गेटवेमा सीमित राख्नुहोस्। व्यवस्थापन, underlay र प्लेटफर्म इन्टरफेसका छुट्टाछुट्टै जिम्मेवारी हुँदा प्रत्येक VLAN ठेगाना हटाउनु धेरै फराकिलो हुन्छ। दोस्रो सक्रिय गेटवे पनि जाँच्नुहोस्, किनकि फायरवालको वरिपरि अझै राउट गर्ने गेटवेले डिजाइनलाई चुपचाप असफल बनाउँछ।
यो मोडेल लेखापरीक्षकलाई बुझाउन सजिलो छ। यो चलाउन आफैं सस्तो भने होइन।
वितरित IRB: छिटो मार्ग, पूर्वनिर्धारित रूपमा निरीक्षण छैन
वितरित anycast गेटवेहरूसँग, प्रत्येक leaf ले भाडावालको ट्राफिक स्थानीय रूपमा राउट गर्छ, र RFC 9135 ले यसले केन्द्रीकृत गेटवेमा फर्काएर लैजाने काम किन टार्छ भन्ने वर्णन गर्छ। लाभ वास्तविक छ, र यसको सिधा परिणाम छ: फायरवाल कहाँ जोडिएको छ भन्नेबाट निरीक्षण अनुमान गर्न सकिँदैन। सीमा leaf मा जोडिएको फायरवालले बाह्य ट्राफिक र तपाईंले स्पष्ट रूपमा त्यतातिर पठाउने सबै देख्छ।
प्लेटफर्मले साँच्चै समर्थन गर्ने संयन्त्रबाट सेवा भित्र हाल्नुहोस्: नीति-आधारित पुनर्निर्देशन, सेवा नोड, वा फायरवालमार्फत नियन्त्रित VRF-बीचको राउटिङ। लक्षित ट्राफिकलाई यसको वास्तविक प्रवेश बिन्दुमा मिलाउनुहोस्। होस्टतिर फर्किएको इन्टरफेसमा लेखिएको नीतिले overlay बाट आउने प्याकेट समेट्दैन।
लक्षित पूर्वनिर्धारितको सट्टा स्थापित रुटहरू पढ्नुहोस्। सिधै आयात गरिएको थप विशिष्ट भाडावाल उपसर्गले फायरवालतिर देखाउने पूर्वनिर्धारित रुट बाइपास गर्न सक्छ, र कन्फिगरेसनमा केही पनि गलत देखिँदैन।
सममिति राउटिङको गुण हो, निरीक्षणको ग्यारेन्टी होइन
सममित IRB ले प्रवेश र निर्गम provider edge नोडहरूले एउटा प्रवाहका लागि राउटिङ र ब्रिजिङ कसरी सम्हाल्छन् भन्ने वर्णन गर्छ। दुवै दिशा एउटै stateful उपकरणसम्म पुग्छन् कि भन्ने यसले भन्दैन। ECMP, anycast र फायरवालको उच्च उपलब्धताले कुन नोडले फिर्ता ट्राफिक देख्छ भन्नेमा असर पार्छ, र क्लस्टरको समर्थित अवस्था मोडेलले त्यो स्वीकार्य छ कि छैन निर्धारण गर्छ।
तपाईंका लागि महत्त्वपूर्ण प्रत्येक प्रवाहका लागि फिर्ता मार्ग स्पष्ट रूपमा पछ्याउनुहोस्। NAT त्यो कामको सार्वभौमिक विकल्प होइन, र त्यसमा भर पर्ने डिजाइनहरूले कमी सामान्यतया निर्माणको क्रममा होइन, failover को क्रममा भेट्टाउँछन्।
डिजाइन स्वीकृत गर्नुअघि एउटा अनिवार्य प्रवाह र एउटा जानाजानी बाहिर राखिएको प्रवाह दुवै दिशामा हिँड्नुहोस्।
कसरी छान्ने, र जुनसुकै अवस्थामा के परीक्षण गर्ने
निरीक्षण कभरेज ट्रान्जिट क्षमताभन्दा महत्त्वपूर्ण हुँदा र तपाईं केन्द्रीय निर्भरता व्यहोर्न सक्नुहुन्छ भने केन्द्रीकृत गेटवे छान्नुहोस्। स्थानीय राउटिङ मुख्य कुरा हुँदा वितरित IRB छान्नुहोस्, र मान्नुको सट्टा स्पष्ट सेवा-प्रवेशका लागि बजेट राख्नुहोस्।
त्यसपछि तपाईंले साँच्चै स्थापना गरेको राउटिङ परीक्षण गर्नुहोस्, किनकि दुवै डिजाइन सबैभन्दा बढी त्यहीँ फरक हुन्छन्:
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefixपरीक्षणमा सेवा नोडको असफलता र पुनःप्राप्ति समावेश गर्नुहोस्। निरीक्षणलाई चुपचाप बाइपास गर्ने फलब्याक रुट योजनाबद्ध fail-open नीतिभन्दा फरक निर्णय हो, र सामान्यतया दुईमध्ये एउटा मात्र अभिप्रेत हुन्छ। तयार डिजाइनले प्रत्येक ट्राफिक वर्ग कहाँ राउट हुन्छ, कहाँ निरीक्षण हुन्छ, र त्यो निरीक्षण मार्ग उपलब्ध नहुँदा के हुन्छ भनी नाम दिन्छ।