दोन ऑन-प्रेम VPN पत्ते: दोन Azure पीअर, एक नाही

आकृतीत शाखेत दोन इंटरनेट लिंक आणि Azure मध्ये एक VPN गेटवे आहे, त्यामुळे स्थानिक नेटवर्क गेटवेला दोन्ही सार्वजनिक पत्ते मिळतात। हे व्यवस्थित दिसते, आणि आकृती सुचवते तसे काम करत नाही। प्रत्येक ऑन-प्रेम VPN उपकरण वेगळे पीअर संबंध आहे, आणि Microsoft चे बहु-उपकरण डिझाइन प्रत्येकाला स्वतःचे स्थानिक नेटवर्क गेटवे संसाधन आणि स्वतःचे कनेक्शन देते। एकाच संसाधनात दुसरे पत्ता जोडल्याने दुसरे पीअर तयार होत नाही। ते असे संसाधन तयार करते जे दोन्ही उपकरणांचे योग्य वर्णन करत नाही।

दंतकथा: एक गेटवे, दोन पत्ते

स्थानिक नेटवर्क गेटवे हे दूरच्या पीअरचे वर्णन आहे: एक सार्वजनिक एंडपॉइंट आणि त्यामागील खाजगी उपसर्ग। त्या संसाधनाला «यापैकी कोणतेही उपकरण» असा अर्थ देण्याचा कोणताही समर्थित मार्ग नाही।

हाच गोंधळ उलट दिशेनेही आहे, जिथे Azure च्या दोन सार्वजनिक IP दोन Azure गेटवे असल्याचा पुरावा म्हणून वाचल्या जातात।

प्रथम वस्तू मोजा, नंतर बोगदे

सारख्या खाजगी नेटवर्कमध्ये प्रवेश आणि स्वतःचा सार्वजनिक पत्ता असलेली दोन स्वतंत्रपणे चालवली जाणारी ऑन-प्रेम उपकरणे घ्या, शिवाय सक्रिय-सक्रिय मोडमध्ये एक मार्ग-आधारित Azure गेटवे। Azure गेटवेमध्ये वेगवेगळ्या सार्वजनिक IP सह दोन सक्रिय उदाहरणे आहेत। प्रत्येक ऑन-प्रेम उपकरण दोन्ही उदाहरणांशी जोडते। हेच पूर्ण जाळे आहे, आणि वस्तूंची संख्या आकृतीतून नाही, यातून येते।

गणना डिझाइन दस्तऐवजात पेस्ट करण्याइतकी लहान आहे:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

एक कनेक्शन संसाधन एकापेक्षा जास्त अंतर्निहित बोगदे वाहून नेऊ शकते, म्हणून चार बोगदे म्हणजे चार व्हर्च्युअल नेटवर्क गेटवे नाहीत। Azure च्या दोन सार्वजनिक IP देखील दूरच्या साइटचे वर्णन करणाऱ्या दोन स्थानिक नेटवर्क गेटवेइतक्याच वस्तू नाहीत।

Azure बाजूला सक्रिय-सक्रिय काय जोडते

सक्रिय-सक्रिय Azure गेटवेला एका सक्रिय उदाहरणापासून दोनमध्ये बदलते, प्रत्येकाला स्वतःचा सार्वजनिक IP असतो, आणि हेच पूर्ण जाळे शक्य करते। एका प्रवाहाचे थ्रूपुट दुप्पट करत नाही। दोन्ही उपकरणे एकाच वेळी पुढे पाठवत असल्यास ऑन-प्रेम बाजूला समान-खर्च बहुमार्ग समर्थनाची गरजही ते दूर करत नाही। काहीही तयार करण्यापूर्वी गेटवे मोड, SKU आणि दूरच्या उपकरणाची क्षमता तपासा।

निष्क्रिय-स्टँडबाय गेटवे पूर्णपणे वैध डिझाइन आहे; ते फक्त वेगळी बोगद्यांची संख्या देते।

BGP दोन्ही मार्ग उपयुक्त करते

बहु-उपकरण डिझाइनसाठी दोन्ही ऑन-प्रेम उपकरणे BGP चालवतात। प्रत्येकाला अद्वितीय BGP पीअर पत्ता द्या आणि संबंधित मार्गांवर तेच इच्छित खाजगी उपसर्ग जाहीर करा। खाजगी उपसर्ग संरक्षित नेटवर्क ओळखतात, तर सार्वजनिक पत्ते एन्क्रिप्टेड कॅरियर कनेक्शन कुठे संपतात हे ओळखतात। या दोन्हींचा गोंधळ केल्यास प्रत्येक बोगदा वर असलेले पण मार्ग चुकीचे असलेले डिझाइन तयार होते।

परतीचे राउटिंग आणि दोन्हीपैकी कोणताही मार्ग सहन करावा लागणारा कोणताही स्टेटफुल तपासणीचे नियोजन करा। प्रत्येक एंडपॉइंटवर निरोगी IKE सत्र हे सिद्ध करत नाही की कोणतेही कार्यभार प्रत्येक जाहीर केलेला मार्ग वापरू शकते।

प्रवाह-आधारित निवड बँडविड्थ पूलिंग नाही

Azure प्रवाहाच्या पत्ते आणि पोर्टवर हॅश वापरून प्रत्येक प्रवाहासाठी मार्ग निवडते। स्थिर स्थितीत, दिलेल्या TCP किंवा UDP प्रवाहाचे पॅकेट सामान्यतः त्याच बोगद्यातून जातात, आणि ऑन-प्रेम बाजू परतीच्या दिशेसाठी वेगळा बोगदा निवडू शकते। त्यामुळे दोन उपकरणे आणि चार बोगदे उपलब्धता सुधारतात, एका हस्तांतरणाचा वेग नाही। जेव्हा विक्रेत्याची स्लाइड एकत्रीकरणाचे वचन देते, तेव्हा ती दुसरे वैशिष्ट्य किंवा गैरसमज वर्णन करते।

मार्ग कसे पसरतात हे पाहायचे असल्यास समांतर प्रवाहांसह चाचणी करा, आणि मर्यादा पाहायची असल्यास एका प्रवाहासह।

तुम्ही प्रत्यक्षात कोणती पुनरावृत्ती काढून टाकली

एका उपकरणावर दोन WAN पत्ते प्रवेश-लिंक पर्याय सुधारतात, परंतु त्या उपकरणाची वीज, सॉफ्टवेअर आणि अपयश स्थिती सामायिक करतात। ते दोन उपकरणांसारखे नाहीत, आणि Azure बाजूचे कोणतेही कॉन्फिगरेशन ते बदलत नाही। पत्त्यांच्या संख्येवरून पुनरावृत्तीचा अंदाज लावण्याऐवजी विक्रेत्याच्या समर्थित दुहेरी-WAN किंवा क्लस्टर डिझाइनचे अनुसरण करा। नंतर त्याची चाचणी करा: एका वेळी एक मार्ग काढा आणि उर्वरित मार्ग तसेच दोन्ही दिशांमधील वास्तविक अनुप्रयोग देवाणघेवाण पुष्टी करा।

शोध आणि अभिसरण विलंबाची अपेक्षा करा, आणि काही विद्यमान सत्रे संपतील याची अपेक्षा करा।