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शिकलेल्या मार्गांची तुम्ही अपेक्षित असलेल्या उपसर्गांशी तुलना करा. छोटा प्रशासकीय भार वाहणारा फॉलबॅक त्या भारासाठी पूर्णपणे पुरेसा असू शकतो आणि उत्पादन मागणीला आवश्यक असलेल्या क्षमतेपासून खूप दूर असू शकतो, म्हणून मार्गाच्या शेजारी क्षमतेचा गृहीतक नोंदवा.
एक निवाडा नाही, तीन वेगळ्या ओळी नोंदवा
एंडपॉइंट पुनरावृत्ती, ट्रान्सपोर्ट पुनरावृत्ती आणि आपत्तीनंतरची पुनर्प्राप्ती डिझाइन रेकॉर्डमध्ये वेगळ्या नोंदी म्हणून ठेवा, प्रत्येकी स्वतःची यंत्रणा, स्वतःची पडताळणी आणि स्वतःचा मालक. घटना-पुनरावलोकन विचारते की कनेक्शनने गेटवे रीस्टार्ट टिकवला पण फायबर कट नाही, तेव्हा तीन ओळी एका वाक्यात उत्तर देतात; एक «पुनरावृत्ती» चेकबॉक्स ते करू शकत नाही.
मग स्वस्तात तपासता येणाऱ्या ओळी तपासा. एक टनेल अयशस्वी करा आणि रहदारी सरकते व पुन्हा एन्क्रिप्ट होते याची खात्री करा. एक मार्ग मागे घ्या आणि उरलेला मार्ग तुमचा उद्दिष्ट असलेलाच आहे याची खात्री करा, नंतर तो अजूनही एन्क्रिप्टेड आहे का याची खात्री करा. ज्या अयशस्वी स्थितींचे अनुकरण तुम्ही करू शकला नाहीत त्या नोंदवा, कारण न तपासलेली ओळ एक गृहीतक आहे आणि ती तशीच चिन्हांकित केली पाहिजे.
उपयुक्त परिणाम म्हणजे छोटा तक्ता आणि प्रत्येक ओळीसाठी एक वाक्य. एखाद्या ओळीत यंत्रणा नसल्यास तोच शोध आहे, आणि तो डिझाइन पुनरावलोकनात शोधणे दोन्ही टनेल कधीही टिकवू न शकणाऱ्या कॅरियर व्यत्ययादरम्यान शोधण्यापेक्षा खूप स्वस्त आहे.