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 जडानसँग अद्यावधिक गर्न एउटा निश्चित ठाउँ हुन्छ, कहिल्यै आफ्नो नभएको मार्गको दोष बोक्ने चलिरहेको टनेलको सट्टा।