ExpressRoute प्लस VPN: आप किन विफलता-डोमेन को कवर करते हैं?
दूसरा IPsec टनल एक एंडपॉइंट को कवर करता है, उसके नीचे के सर्किट को नहीं। हर विफलता-डोमेन का नक्शा बनाएँ, फिर तय करें कि बिना एन्क्रिप्शन वाला फ़ॉलबैक अनुमत है या नहीं।
ExpressRoute के निजी पीयरिंग पर चलने वाली IPsec टनल उस ट्रांसपोर्ट में एन्क्रिप्शन जोड़ती है जो पहले से मौजूद है। दूसरी टनल एंडपॉइंट की उपलब्धता सुधारती है, और दोनों के नीचे के कैरियर पथ के लिए वह कुछ भी नहीं करती। यह अंतर खोना आसान है जब डैशबोर्ड दो हरी टनल दिखाते हैं और डिज़ाइन समीक्षा एक अलग सवाल पूछती है: यह कनेक्शन किन विफलताओं को झेलना चाहिए? पहले उसका उत्तर दें, फिर टनल गिनें, क्योंकि हरे संकेतकों की संख्या एन्क्रिप्शन परत का गुण है और विफलता-डोमेन की संख्या पूरे पथ का गुण है।
हरी टनल से नहीं, विफलताओं से शुरू करें
कुछ भी बनाने से पहले चार पंक्तियाँ लिखें: एक VPN एंडपॉइंट या पीयर इंस्टेंस का विफल होना, एक स्थानीय राउटर या फ़र्स्ट-माइल कनेक्शन का विफल होना, साझा ExpressRoute पथ का विफल होना, और निजी पीयरिंग के अब भी ट्रैफ़िक ढोते समय IPsec का अनुपलब्ध हो जाना। हर पंक्ति बताती है कि डिज़ाइन को क्या सुरक्षित रखना है, और हर एक का उत्तर अलग तंत्र देता है।
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft, ExpressRoute के निजी पीयरिंग पर निजी-IP साइट-टू-साइट VPN और इंटरनेट-आधारित साइट-टू-साइट कनेक्शन के साथ समर्थित सहअस्तित्व का दस्तावेज़ीकरण करता है। वह सहअस्तित्व एक अलग अंडरले डिज़ाइन है, और वह केवल इसलिए प्रकट नहीं होता कि आपने एक और निजी टनल एंडपॉइंट जोड़ा है।
विफलता-डोमेन 1: VPN एंडपॉइंट
एक गेटवे पर दो टनल आमतौर पर active-active जोड़े होते हैं जो उसी Azure-पक्ष के संसाधन पर समाप्त होते हैं। वे एक टनल या इंस्टेंस की समस्या से बचाते हैं, और उस संसाधन के अनुपलब्ध, पुनःकॉन्फ़िगर या क्षमता-रहित होने से नहीं बचाते। एंडपॉइंट अनावश्यकता का अर्थ है दूसरा समर्थित एंडपॉइंट, अपने स्वयं के पथ और अपने स्वयं के कॉन्फ़िगरेशन के साथ, और साथ में एक ऐसा रूट जो उस तक पहुँच सके।
जो आपने वास्तव में तैनात किया है उसे जाँचें, न कि जो आरेख कहता है, क्योंकि पोर्टल इन संसाधनों को ऐसे समूहित करता है जो उनका संबंध छिपा देता है:
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'यदि दोनों टनल एक सार्वजनिक IP वाले एक गेटवे की ओर इंगित करते हैं, तो आपके पास एक विशिष्ट और सीमित प्रकार की एंडपॉइंट अनावश्यकता है। हो सकता है कि यह ठीक वही हो जो आवश्यकता माँगती है, और इसे अनावश्यक कनेक्शन के रूप में वर्णित करने के बजाय ऐसे ही कहा जाना चाहिए।
विफलता-डोमेन 2: स्थानीय पथ और कैरियर
एन्क्रिप्शन के नीचे एक भौतिक और वाणिज्यिक वास्तविकता है: ग्राहक-किनारे का उपकरण, एक क्रॉस-कनेक्ट, एक प्रदाता नेटवर्क और एक पीयरिंग स्थान। ExpressRoute उपलब्धता मार्गदर्शिका स्पष्ट है कि एंड-टू-एंड अनावश्यकता में ग्राहक और सेवा-प्रदाता खंड शामिल हैं, केवल Microsoft पक्ष नहीं। एक राउटर, एक विद्युत फ़ीड या फ़र्स्ट-माइल कनेक्शन साझा करने वाले दो तार्किक पथ अब भी वही निर्भरता साझा करते हैं।
यहीं कोई डिज़ाइन आमतौर पर ईमानदार समीक्षा में विफल होता है। एक ही प्रदाता के दो सर्किट, एक ही इमारत में समाप्त होते हुए, एक ही खरीद आदेश के उपकरण पर, दो विफलता-डोमेन नहीं हैं। वे दो इनवॉइस वाला एक विफलता-डोमेन हैं।
कैरियर से लिखित में पूछें: इनमें से कौन-से पथ कहाँ अलग होते हैं, और साझा खंड के विफल होने पर दस्तावेज़ी व्यवहार क्या है? डिज़ाइन कॉल के दौरान मौखिक आश्वासन उस आउटेज में नहीं टिकता जिसके लिए आप डिज़ाइन कर रहे हैं।
विफलता-डोमेन 3: वह रूट जो IPsec के बिना बचा रहता है
निजी पीयरिंग और IPsec एक ही एप्लिकेशन प्रीफ़िक्स के लिए प्रतिस्पर्धी रूट दे सकते हैं. यदि सुरक्षित रूट गायब हो जाए, तो बचा हुआ सीधा ExpressRoute रूट अब भी उपयोगी हो सकता है, उस एन्क्रिप्शन परत के बिना जो टनल दे रही थी। यह स्वीकार्य है या नहीं यह नीति-निर्णय है, और यही वह निर्णय है जो सबसे अधिक निहित छोड़ा जाता है।
एन्क्रिप्शन आवश्यकताएँ और उपलब्धता आवश्यकताएँ यहाँ सचमुच टकरा सकती हैं। «कोई भी बचा हुआ रूट सफलता माना जाता है» एक उपलब्धता-कथन है जो एन्क्रिप्शन के सवाल का चुपचाप «नहीं» से उत्तर देता है। लिखें कि कौन जीतता है, किन प्रीफ़िक्स के लिए, और किसने मंज़ूरी दी।
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o tableसीखे गए रूट की तुलना उन प्रीफ़िक्स से करें जिनकी आपको अपेक्षा थी। छोटा प्रशासनिक भार ढोने वाला फ़ॉलबैक उस भार के लिए पूरी तरह उपयुक्त हो सकता है और उत्पादन माँग को जिस क्षमता की ज़रूरत है उससे बहुत दूर हो सकता है, इसलिए रूट के साथ क्षमता की धारणा दर्ज करें।
एक फ़ैसला नहीं, तीन अलग पंक्तियाँ दर्ज करें
एंडपॉइंट अनावश्यकता, ट्रांसपोर्ट अनावश्यकता और आपदा-पश्चात रिकवरी को डिज़ाइन रिकॉर्ड में अलग प्रविष्टियों के रूप में रखें, हर एक अपने तंत्र, अपने सत्यापन और अपने स्वामी के साथ। जब कोई घटना-समीक्षा पूछे कि कनेक्शन गेटवे रीस्टार्ट झेल गया पर फ़ाइबर कट नहीं, तो तीन पंक्तियाँ एक वाक्य में उत्तर देती हैं; एक «अनावश्यक» चेकबॉक्स ऐसा नहीं कर सकता।
फिर उन पंक्तियों का परीक्षण करें जिन्हें सस्ते में परखा जा सकता है। एक टनल विफल करें और पुष्टि करें कि ट्रैफ़िक हटता है और फिर से एन्क्रिप्ट होता है। एक रूट वापस लें और पुष्टि करें कि बचा हुआ पथ वही है जो आप चाहते थे, फिर पुष्टि करें कि क्या वह अब भी एन्क्रिप्टेड है। जिन विफलताओं का अनुकरण आप नहीं कर सके उन्हें दर्ज करें, क्योंकि अनपरखी पंक्ति एक धारणा है और उसे वैसा ही चिह्नित करना चाहिए।
उपयोगी आउटपुट एक छोटी तालिका और हर पंक्ति के लिए एक वाक्य है। यदि किसी पंक्ति में कोई तंत्र नहीं है, तो वही निष्कर्ष है, और उसे डिज़ाइन समीक्षा में खोजना कैरियर आउटेज के दौरान खोजने से कहीं सस्ता है, जिसे दोनों टनल कभी नहीं झेल पातीं।