दुई अन-प्रिम 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 वा क्लस्टर डिजाइन पछ्याउनुहोस्। त्यसपछि परीक्षण गर्नुहोस्: एक पटकमा एउटा मार्ग हटाउनुहोस् र बाँकी मार्ग तथा दुवै दिशामा वास्तविक अनुप्रयोग आदानप्रदान पुष्टि गर्नुहोस्।

पहिचान र अभिसरण ढिलाइको अपेक्षा गर्नुहोस्, र केही विद्यमान सत्रहरू अन्त्य हुने अपेक्षा गर्नुहोस्।