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 वर पॅकेट कॅप्चर, उत्तर कधीच तिथे परत आले नाही तर जवळजवळ काहीच सांगत नाही.

शेवटी, योजना तीन स्वतंत्र ओळींमध्ये लिहा: मार्गांची मालकी, रहदारी स्टीअरिंग आणि सत्र-स्थितीची मालकी. पहिल्या दोन सोडवल्या गेल्यावर आणि तिसरी गृहीत धरल्यावर रचना तुटतात.