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सिकेका मार्गहरूको तुलना तपाईंले अपेक्षा गरेका प्रिफिक्सहरूसँग गर्नुहोस्। सानो प्रशासनिक भार बोक्ने फलब्याक त्यो भारका लागि पूर्ण रूपमा पर्याप्त हुन सक्छ र उत्पादन मागलाई आवश्यक पर्ने क्षमताबाट धेरै टाढा हुन सक्छ, त्यसैले मार्गको छेउमा क्षमताको अनुमान लेख्नुहोस्।
एउटा फैसला होइन, तीन अलग हरफ लेख्नुहोस्
अन्त्यबिन्दु पुनरावृत्ति, ट्रान्सपोर्ट पुनरावृत्ति र विपत्तिपछिको पुनर्प्राप्तिलाई डिजाइन अभिलेखमा अलग प्रविष्टिका रूपमा राख्नुहोस्, प्रत्येकको आफ्नै संयन्त्र, आफ्नै प्रमाणीकरण र आफ्नै मालिक। घटना-समीक्षाले जडानले गेटवे रिस्टार्ट किन सह्यो तर फाइबर कट सहेन भनेर सोध्दा, तीन हरफले एउटै वाक्यमा उत्तर दिन्छन्; एउटा «पुनरावृत्ति» चेकबक्सले त्यो गर्न सक्दैन।
त्यसपछि सस्तोमा परीक्षण गर्न सकिने हरफहरू परीक्षण गर्नुहोस्। एउटा टनेल असफल बनाउनुहोस् र ट्राफिक सर्छ र फेरि एन्क्रिप्ट हुन्छ भनी पुष्टि गर्नुहोस्। एउटा मार्ग फिर्ता लिनुहोस् र बाँकी मार्ग तपाईंले चाहेकै हो भनी पुष्टि गर्नुहोस्, त्यसपछि त्यो अझै एन्क्रिप्टेड छ कि छैन पुष्टि गर्नुहोस्। अनुकरण गर्न नसकेका असफलताहरू दस्तावेज गर्नुहोस्, किनकि नपरीक्षण गरिएको हरफ एउटा अनुमान हो र त्यसै गरी चिन्ह लगाउनुपर्छ।
उपयोगी नतिजा छोटो तालिका र प्रत्येक हरफका लागि एउटा वाक्य हो। कुनै हरफमा संयन्त्र छैन भने त्यही नै निष्कर्ष हो, र त्यसलाई डिजाइन समीक्षामा फेला पार्नु दुवै टनेलले कहिल्यै सहन नसक्ने क्यारियर अवरोधका बेला फेला पार्नुभन्दा धेरै सस्तो हुन्छ।