Azure peering या VNet-से-VNet VPN? रूटिंग से पहले फैसला करें

Azure आपको दो वर्चुअल नेटवर्क जोड़ने के कम से कम दो तरीके देता है, और ये एक ही ऑब्जेक्ट पर बदले जा सकने वाली सेटिंग्स नहीं हैं। Peering बिना गेटवे के Microsoft के बैकबोन पर VNet को जोड़ता है; VNet-से-VNet VPN आपके द्वारा तैनात, आकार-निर्धारित और निगरानी किए जाने वाले दो गेटवे के बीच IPsec संबंध रखता है। फैसला तीन शर्तों पर आता है, और अगर रूट जोड़ने से पहले आप तीनों का जवाब नहीं दे सकते, तो आप ऐसे मॉडल के लिए बायपास बनाने जा रहे हैं जिसे आपने कभी चुना ही नहीं।

तीन शर्तें जो मॉडल तय करती हैं

पहली यह है कि क्या आवश्यकता में किसी चीज़ को ऐसी IPsec सीमा चाहिए जो आपके स्वामित्व में हो और जिसकी ओर आप इशारा कर सकें। दूसरी यह है कि क्या पता-स्थान साफ़ हैं और दोनों VNet को केवल एक-दूसरे से बात करनी है। तीसरी यह है कि किसी भी पारगमन पथ और गेटवे बिल का मालिक कौन है। इसी क्रम में उत्तर दें, क्योंकि पहली दूसरी कितनी भी आकर्षक लगे, peering को हटा सकती है।

दोनों मॉडलों में समान है कड़ा पता-निर्धारण नियम: VNet के पता-स्थान ओवरलैप नहीं होने चाहिए। न peering और न VNet-से-VNet VPN दो समान रेंज को स्पष्ट बनाने का समर्थित तरीका है, और ओवरलैप के लिए अलग कनेक्शन प्रकार नहीं, मैपिंग डिज़ाइन या पुनर्डिज़ाइन चाहिए।

शर्त 1: क्या आपको अपने स्वामित्व वाली IPsec सीमा चाहिए?

Peering ट्रैफ़िक को Azure के निजी बैकबोन पर ले जाता है और peered कनेक्शन के लिए स्वयं VPN गेटवे की आवश्यकता नहीं रखता। यह परिवहन के बारे में कथन है, एन्क्रिप्शन के बारे में ऐसा कथन नहीं जो आप ऑडिटर को «हम IPsec चलाते हैं» के रूप में दे सकें। अगर आवश्यकता ग्राहक-कॉन्फ़िगर टनल, विशिष्ट IKE नीति या आपके नियंत्रण वाले उपकरण पर समाप्त होने वाली सीमा का नाम लेती है, तो बैकबोन कितना भी निजी हो, peering उसे पूरा नहीं करता।

VNet-से-VNet VPN वह सीमा देता है: दो गेटवे, IPsec/IKE संबंध, साझा कुंजियाँ और उसके साथ आने वाली पूरी परिचालन सतह। आपको टनल की स्थिति, गेटवे क्षमता, SKU सीमाएँ और वह निगरानी विरासत में मिलती है जो साबित करती है कि टनल चालू है। यह सही उत्तर है जब आवश्यकता ठीक उसी सीमा के बारे में हो, जिसे peering अवलोकन में peering से अलग कनेक्शन प्रकार के रूप में वर्णित किया गया है।

दूसरी दिशा में भी उतने ही सावधान रहें। «हमें VNet के बीच एन्क्रिप्शन चाहिए» अक्सर वर्कलोड के अपने TLS से पूरा हो जाता है, और तब गेटवे पीछे कोई आवश्यकता न होने वाला खर्च है। तंत्र चुनने से पहले वह वाक्य लिखें जो ऑडिटर पढ़ेगा।

शर्त 2: क्या टोपोलॉजी सीधी है, या किसी चीज़ को पारगमन करना है?

Peering पारगम्य नहीं है। एक हब से peered दो VNet इससे एक-दूसरे से जुड़े नहीं हो जाते, और एक दिशा में काम करता दिखने वाला रूट आमतौर पर ऐसा peering होता है जो केवल एक तरफ़ Connected तक पहुँचा है। दोनों पक्ष मौजूद होने चाहिए और दोनों को Connected दिखाना चाहिए, और ट्रैफ़िक चुपचाप गायब होने पर पहले यही जाँचते हैं।

अगर आवश्यकता हब के ज़रिए ऑन-प्रिमाइसेस पहुँच है, तो गेटवे ट्रांज़िट विशिष्ट भूमिकाओं वाला अलग डिज़ाइन है: हब गेटवे का मालिक है, स्पोक peering गेटवे ट्रांज़िट की अनुमति देता है, और स्पोक को फ़ॉरवर्ड किया गया ट्रैफ़िक अनुमत करना होगा। ये peering पर गुण हैं, VNet जोड़ने के स्वतः परिणाम नहीं:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

प्रभावी रूट तालिका «क्या पथ मौजूद है?» का ईमानदार उत्तर है। यह अगली हॉप का प्रकार दिखाती है जिसे प्लेटफ़ॉर्म वास्तव में उपयोग करेगा, इसलिए कॉन्फ़िगर दिखने वाला पर जुड़ा न हो ऐसा peering रहस्य नहीं, बल्कि अनुपस्थित या गलत रूट के रूप में दिखता है।

शर्त 3: पारगमन पथ और बिल का मालिक कौन है?

प्रत्येक अतिरिक्त हॉप का एक मालिक होता है। Peering में नया VNet दोनों तरफ़ नई peering जोड़ी लाता है और पारगमन के लिए ऐसा हब जो ट्रैफ़िक आगे भेजता रहता है और ऐसी रूट तालिका जो उसी की ओर इशारा करती रहती है। VPN में नया VNet मतलब मौजूदा पर एक और गेटवे या एक और कनेक्शन, जिसकी अपनी क्षमता-सीमा देखनी होती है।

लागत वही आकार अपनाती है पर वही लाइन आइटम नहीं: peering शुल्क कनेक्शन और डेटा अंतरण हैं, जबकि VPN गेटवे घंटे और अपने अंतरण शुल्क जोड़ता है। उस टोपोलॉजी का कुल तुलना करें जिसे आप वास्तव में एक साल चलाएँगे, दूसरी टनल और निगरानी सहित, आज के एक कनेक्शन की कीमत नहीं। वह श्रम भी जोड़ें जिसका कोई चालान नहीं करता: किसी को कुंजियाँ घुमानी होती हैं, टनल की स्थिति देखनी होती है और गेटवे रीस्टार्ट होने पर रात तीन बजे अलर्ट का जवाब देना होता है। आमतौर पर यही मद बहस तय करती है, क्योंकि कोटेशन में कभी न दिखने वाली यह अकेली मद है।

जो भी चुनें, तीन प्रवाह जाँचें: इच्छित, अस्वीकृत जो अस्वीकृत ही रहना चाहिए, और वह पुनर्प्राप्ति स्थिति जिसमें हब गेटवे या peering डाउन है। केवल सुखद पथ समझाने वाला मॉडल सत्यापित नहीं हुआ, वह प्रदर्शित हुआ है।

अपने ही दावे के विरुद्ध चयन सत्यापित करें

एक वाक्य लिखें जो मॉडल, सीमा और मालिक का नाम ले, फिर जाँचें कि तैनात स्थिति उससे मेल खाती है। Peering के लिए इसका अर्थ है दोनों peering स्थितियाँ Connected, प्रभावी रूट गंतव्य प्रीफ़िक्स के लिए peering अगली हॉप दिखाए और पथ में कोई गेटवे न हो। VNet-से-VNet VPN के लिए इसका अर्थ है दोनों कनेक्शन Connected, दोनों गेटवे पर मेल खाती कुंजियाँ और नीतियाँ, और ऐसा रूट जिसकी अगली हॉप वर्चुअल नेटवर्क गेटवे है।

अगर जाँचें वाक्य से टकराती हैं, तो पहले वाक्य ठीक करें। इन डिज़ाइनों में अधिकांश उलझन ऐसे संकर से आती है जिसे किसी ने वर्णित नहीं किया: वर्कलोड सबनेट के लिए peering, एक पुरानी सेवा के लिए VPN और ऐसी रूट तालिका जो चुपचाप एक को प्राथमिकता देती है।