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 मध्ये, वापरकर्ता-परिभाषित मार्ग तक्ता व्हर्च्युअल नेटवर्कशी नाही तर सबनेटशी जोडला जातो, म्हणून प्रभावी मार्ग VNet ब्लेडमध्ये नाही तर वर्कलोड NIC वर तपासा.
व्यवस्थापित 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 जोडणीला अद्ययावत करण्यासाठी एक निश्चित जागा असते, कधीही स्वतःचा नसलेल्या मार्गाचा दोष वाहणाऱ्या चालू टनेलऐवजी.