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 पर पैकेट कैप्चर लगभग कुछ नहीं बताता अगर जवाब कभी उसके पास वापस नहीं आया।

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