AWS से Azure साइट VPN: पहले वापसी मार्ग लिखें
दो क्लाउड के बीच जुड़ा टनल तब तक कुछ साबित नहीं करता जब तक हर वर्कलोड सबनेट दूर के प्रीफ़िक्स की ओर रूट न करे। योजना क्रम से पूरी करें, फिर सेवा का परीक्षण करें।
टनल ऊपर आएगा। सामान्यतः ऐसा होता है, क्योंकि IKE को केवल मेल खाते प्रस्ताव और पहुँच योग्य पीयर पता चाहिए। उसके बाद जो विफल होता है वह वापसी मार्ग है: AWS वर्कलोड पैकेट टनल में भेजता है, पर Azure पक्ष पर कोई नहीं जानता कि 10.10.0.0/16 का उत्तर कैसे दें, या Azure का मार्ग ऐसी तालिका में है जिसका वर्कलोड सबनेट उपयोग नहीं करता। किसी भी कंसोल को छूने से पहले मार्ग योजना लिखें, और टनल काम का सबसे कम रोचक हिस्सा बन जाएगा।
चरण 1: पता योजना स्थिर करें
ठोस मानों के साथ काम करें। AWS वर्कलोड 10.10.0.0/16 के भीतर 10.10.1.20 पर है और 10.20.0.0/16 के भीतर 10.20.1.30 पर Azure सेवा तक TCP 443 चाहता है। दोनों रेंज ओवरलैप नहीं होनी चाहिए, और स्वीकृति परीक्षण सेवा-युग्म है, टनल नहीं।
बाकी कुछ भी करने से पहले वे चार तथ्य लिखें, क्योंकि हर बाद का चरण उनके विरुद्ध जाँचा जाता है।
चरण 2: हर सिरे का स्वामी गेटवे नाम दें
AWS Site-to-Site VPN वर्चुअल प्राइवेट गेटवे या ट्रांज़िट गेटवे पर समाप्त हो सकता है, और ये अलग रूटिंग स्वामी हैं। Azure अपना प्रबंधित VPN Gateway और अलग से VM-आधारित उपकरण देता है जिन्हें ग्राहक स्वयं चलाते हैं। नोट करें कि आपके पास कौन-सा युग्म है, क्योंकि हर संयोजन में अगला हॉप अलग होता है।
प्रबंधित गेटवे के लिए, ऐसा मार्ग न कॉपी करें जो अनुमानित निजी उपकरण पते की ओर इशारा करता है। उपकरण के लिए, यह न मानें कि क्लाउड में रूट प्रसार गेस्ट ऑपरेटिंग सिस्टम को कॉन्फ़िगर करता है, क्योंकि वह ऐसा नहीं करता।
यहाँ गलती करने से ऐसी योजना बनती है जो पूरी दिखती है और पैकेट ऐसे पते पर भेजती है जो कभी उत्तर नहीं देता।
चरण 3: वह मार्ग लिखें जो हर वर्कलोड वास्तव में उपयोग करता है
नीचे की हर सीमा अलग लुकअप है, और उनमें से किसी एक का मार्ग पैकेट के लिए मार्ग नहीं है। टनल के लाइव होने से पहले तालिका अपने मानों से भरें।
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS में, वर्कलोड सबनेट की रूट तालिका BGP या टनल स्वस्थ होने के बाद भी आपकी ही अपडेट करने की है; रूटिंग अवलोकन इसे कनेक्शन का हिस्सा मानता है। Azure में, उपयोगकर्ता-परिभाषित रूट तालिका वर्चुअल नेटवर्क से नहीं बल्कि सबनेट से जुड़ती है, इसलिए प्रभावी मार्ग वर्कलोड NIC पर जाँचें, VNet ब्लेड में नहीं।
प्रबंधित Azure गेटवे गेटवे प्रसार के माध्यम से दूर का प्रीफ़िक्स सीख सकता है, और UDR उस निर्णय को बदल सकता है। UDR तब जोड़ें जब कारण हो, आदतवश नहीं। यदि जोड़ें, तो उसे उपकरण का पता गढ़ने के बजाय उस अगले हॉप पर इंगित करें जो गेटवे VPN पथ के लिए प्रकाशित करता है। फिर NIC पर प्रभावी मार्ग दोबारा पढ़ें, क्योंकि निर्णय वास्तव में वहीं होता है।
चरण 4: दायरा मिलाएँ
BGP के लिए, हर पक्ष जो घोषित करता है उसकी तुलना दूसरे पक्ष ने वास्तव में जो सीखा उससे करें, प्रीफ़िक्स दर प्रीफ़िक्स। स्थिर रूटिंग के लिए, कॉन्फ़िगर की गई दूर की रेंज की तुलना चरण 3 में लिखे वर्कलोड मार्गों से करें।
क्रिप्टोग्राफ़ी पर सहमत IKE संबंध इस बात का प्रमाण नहीं है कि किसी पक्ष ने 10.10.0.0/16 या 10.20.0.0/16 सीखा है। दो टनल ऊपर हो सकते हैं जबकि एक पक्ष आपकी योजना के /16 के बजाय एक ही /24 घोषित कर रहा हो। प्रीफ़िक्स रूटिंग तालिका में जाँचें, टनल स्थिति में नहीं। असंगति बाद में एक चलते सबनेट और एक कभी उत्तर न देने वाले सबनेट के रूप में दिखती है।
चरण 5: सेवा का परीक्षण असली स्रोत से करें
AWS सुरक्षा समूहों और नेटवर्क ACL, Azure NSG, तथा पथ के किसी भी उपकरण फ़िल्टर में इच्छित प्रवाह की अनुमति दें। फिर 10.10.1.20 से स्वीकृत सेवा पते और पोर्ट पर एक कनेक्शन खोलें और पुष्टि करें कि उत्तर उसी स्रोत पर लौटता है।
क्लाउड सुरक्षा समूह और NSG दोनों stateful हैं, इसलिए अस्वीकृत वापसी पैकेट रूटिंग का लक्षण है, उलटी दिशा में लिखना भूला हुआ नियम नहीं।
किसी भी गेटवे से ping कुछ तय नहीं करता। गेटवे पते पर ICMP कंट्रोल प्लेन पथ का अभ्यास करता है, वर्कलोड को चाहिए फ़ॉरवर्ड किया गया TCP सेवा नहीं।
रोलबैक और रिकॉर्ड
टनल पहचानकर्ताओं के पास मार्ग स्वामियों को दर्ज करें और बदलाव से पहले की रूट तालिकाएँ सुरक्षित रखें। यदि बदलाव हटाना हो, तो टनल तोड़ने से पहले वर्कलोड मार्ग हटाएँ, ताकि कोई सबनेट ऐसे अगले हॉप की ओर न रहे जो अब मौजूद नहीं है।
तब बाद में सबनेट स्थानांतरण या spoke जुड़ाव के पास अपडेट करने की एक निश्चित जगह होती है, न कि एक चलता टनल जो ऐसे मार्ग का दोष ढोता है जो उसका कभी था ही नहीं।