Azure NVA निरीक्षण: जवाफ किन अर्को फायरवालबाट जान्छ

शाखाबाट Azure सम्मको प्रवाह दुवै दिशामा सही रूपमा रुट हुन सक्छ र तैपनि असफल हुन सक्छ, किनकि दुई दिशा फरक उपकरणबाट जान्छन्। अनुरोध VPN मार्फत शाखा छोड्छ, NVA A मा अवतरण हुन्छ र कार्यभारमा पुग्छ। जवाफ कार्यभार छोड्छ, NVA B तर्फ देखाउने मार्गसँग मिल्छ र त्यहीँ मर्छ। त्यो चित्रको हरेक मार्ग मान्य छ, र TCP सत्र अझै टुटेको छ।

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

यही अन्तर यहाँ पूरै विषय हो: रुटिङ कन्भर्जेन्स र सत्र-स्थितिको स्वामित्व आरेखमा एउटै देखिने फरक समस्याहरू हुन्।

Route Server ले वास्तवमा के प्रोग्राम गर्छ

Azure Route Server समर्थित BGP वक्ताहरूसँग पियरिङ गर्छ, तिनका मार्ग सिक्छ र तिनलाई भर्चुअल नेटवर्कका प्रभावकारी मार्गमा प्रोग्राम गर्छ। यो नियन्त्रण-तलको काम हो। यसले कुनै विक्रेता फायरवालको सत्र तालिका पढ्दैन, र कुन उपकरणले कुनै निश्चित जडान स्वीकार गर्‍यो भन्ने थाहा पाउँदैन। दुई समान-लागतका अर्को हप यो फ्याब्रिकका लागि एउटै प्रिफिक्समा पुग्ने दुई मात्र बाटो हुन्, र यसले जुनसुकै प्रयोग गर्नेछ।

त्यसैले मार्ग सिक्नु पहुँचयोग्यता प्रमाणित गर्छ। अर्को छेउको उपकरणले यो प्रवाह पहिले देखेको छ कि छैन भन्नेबारे यसले केही प्रमाणित गर्दैन।

डिजाइन गर्नुअघि दुवै दिशा पढ्नुहोस्

प्रत्येक दिशामा तपाईंसँग वास्तवमा भएको स्टेयरिङ लेखेर सुरु गर्नुहोस्, तपाईंले इरादा गरेको होइन। अझ विशिष्ट BGP मार्ग, प्रयोगकर्ता-परिभाषित मार्ग र गेटवे व्यवहार सबै प्रतिस्पर्धा गर्छन्, र विजेता प्रत्येक सत्रको लागि होइन, प्रत्येक गन्तव्यको लागि निर्धारण हुन्छ। NVA मा पूर्वनिर्धारित मार्ग भन्नाले हरेक निजी प्रिफिक्स त्यसबाट जान्छ भन्ने होइन।

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

स्थिति कहाँ बस्छ

स्थितियुक्त फायरवालले जडान स्वीकार गर्छ र पाँच-टुपलमा कुञ्जी गरिएको तालिका प्रविष्टि राख्छ। जवाफ त्यो प्रविष्टि राख्ने उपकरणमा पुग्नुपर्छ, वा त्यो उपकरणले स्थिति अर्को तरिकाले प्राप्त गर्नुपर्छ। Azure डाटा तलमा केहीले पनि उपकरणहरूबीच प्रविष्टि अगाडि पठाउँदैन। या त ट्राफिक मालिकतर्फ फर्काइन्छ, वा उपकरणहरूले विक्रेता संयन्त्रबाट स्थिति साझा गर्छन्, वा डिजाइन काम गर्दैन।

त्यसैले दुई स्वस्थ NVA निरीक्षणका लागि स्वास्थ्य-जाँच होइनन्। स्वास्थ्य पहुँचयोग्यताको बारेमा हो; निरीक्षण कुन इन्स्ट्यान्सले सत्र राख्छ भन्ने बारेमा हो।

समर्थित HA मोडेल र प्रत्येकले के वाचा गर्छ

Microsoft's guidance on Virtual WAN रुटिङ इरादा बारे Microsoft को मार्गदर्शनले दोहोरो-भूमिका जडान र फायरवाल NVA का लागि सीमित व्यवहार वर्णन गर्छ, जहाँ प्रत्यक्ष रुटिङले हबको सामान्य सममितीय प्रवर्तन बाइपास गर्न सक्छ। ती नोटहरूलाई तपाईंले छान्नुभएको टोपोलोजीमा बाधाका रूपमा पढ्नुहोस्, सक्रिय-सक्रिय डिजाइनमा प्रतिबन्धका रूपमा होइन। स्थिति सिङ्क गर्ने, वा प्रति प्रवाह स्टेयर गर्ने विक्रेता जोडी समर्थित हुन सक्छ। दुवैमध्ये केही नगर्ने समान-लागत जोडी समर्थित हुँदैन।

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

यसमा भरोसा गर्नुअघि के परीक्षण गर्ने

Test with inspection enabled and कार्यभारको पहुँच नीति ठाउँमा राखेर परीक्षण गर्नुहोस्, किनकि दुवैमध्ये कुनैले असमानता लुकाउन सक्छ। दुवै दिशामा नयाँ अधिकृत प्रवाह पठाउनुहोस् र एउटै उपकरणले दुवै आधा भाग देखेको पुष्टि गर्नुहोस्। त्यसपछि निरन्तर ट्राफिक चलाउनुहोस् र स्वीकृत फेलओभर सुरु गर्नुहोस्, स्थापित सत्रहरू टिक्छन् कि पुनःजडान हुन्छन् हेर्दै।

प्रत्येक प्रवाहलाई त्यसलाई सम्हालेको उपकरणसँग सम्बद्ध गर्नुहोस्। एउटा NVA मा प्याकेट क्याप्चरले लगभग केही बताउँदैन यदि जवाफ कहिल्यै त्यहाँ फर्किएन।

अन्तमा, योजना तीन अलग लाइनमा लेख्नुहोस्: मार्गको स्वामित्व, ट्राफिक स्टेयरिङ र सत्र-स्थितिको स्वामित्व। पहिलो दुई समाधान भइसकेपछि र तेस्रो अनुमान गरिएपछि डिजाइनहरू टुट्छन्।