दो ऑन-प्रेम 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 या क्लस्टर डिज़ाइन का पालन करें। फिर इसका परीक्षण करें: एक बार में एक पथ हटाएँ और शेष रूट तथा दोनों दिशाओं में वास्तविक एप्लिकेशन आदान-प्रदान की पुष्टि करें।

पहचान और अभिसरण में देरी की अपेक्षा करें, और कुछ मौजूदा सत्रों के समाप्त होने की अपेक्षा करें।