NAT पछाडिको पियरसँग Azure साइट-देखि-साइट VPN: जाँच सूची

यी जाँचहरू क्रममा गर्नुहोस् र पहिलो असफल हुनेमा रोक्नुहोस्। Azure ले NAT पछाडिको उपकरणलाई समर्थन गर्दैन भन्ने धेरैजसो रिपोर्ट वास्तवमा Azure पुग्न नसक्ने पियर ठेगाना, वा सही पक्षबाट कहिल्यै सुरु नहुने टनेल हुन्छन्। बाहिरी यातायात र भित्री राउटिङ दुई फरक समस्या हुन्, र तिनीहरूलाई मिसाउँदा आधा दिन बर्बाद हुन्छ। तलको प्रत्येक चरणले अरूलाई दिन सकिने अवलोकन दिन्छ।

चरण 1: पियर साँच्चै NAT पछाडि छ भनी पुष्टि गर्नुहोस्

उपकरणको WAN इन्टरफेसको ठेगानालाई Azure ले यसका लागि देख्ने ठेगानासँग तुलना गर्नुहोस्। यदि तिनी फरक छन् भने केही अनुवाद गर्दैछ, र त्यो अनुवादक अब तपाईंको VPN डिजाइनको भाग हो। प्रदायकलाई सोध्नुहोस् म्यापिङ स्थिर हो वा साझा, किनकि साझा म्यापिङले तपाईं भर पर्न सक्ने कुरा बदल्छ। निजी WAN ठेगाना र फर्वार्डिङ नभएको उपकरण स्थिर सार्वजनिक म्यापिङ भएको क्यारियर-ग्रेड NAT पछाडिको उपकरणभन्दा फरक केस हो।

यदि दुवै ठेगाना मिले, यहीँ रोक्नुहोस्: NAT तपाईंको समस्या होइन र यो सूचीको बाँकी मद्दत गर्दैन।

टिकटमा दुवै ठेगाना र अनुवादकको मोडेल लेख्नुहोस्। त्यो एक लाइनले कन्फिगर गरिएको पियरले किन जवाफ दिँदैन भन्ने अर्को प्रश्न-राउन्ड रोक्छ।

चरण 2: कसले सुरु गर्ने भनी सहमत हुनुहोस्

Azure VPN Gateway का प्रश्नोत्तर ले NAT-T समर्थन उल्लेख गर्छ र थप्छ कि अन-प्रिमाइस उपकरणले NAT पछाडि हुँदा IPsec टनेल सुरु गर्नुपर्छ। यो स्टेटफुल अनुवाद कसरी काम गर्छसँग मिल्छ, किनकि भित्री उपकरणले पहिलो प्याकेट पठाएकाले अनुवादकले म्यापिङ राख्छ। यदि Azure ले सुरु गर्ने अपेक्षा छ र त्यो म्यापिङ बनाउन केही आउँदैन भने टनेल कहिल्यै सुरु हुँदैन।

पियरलाई यसरी कन्फिगर गर्नुहोस् कि जवाफ-मात्र गर्ने गल्ती स्पष्ट देखियोस्, र उपकरण आफै फेरि प्रयास गर्छ कि ट्रिगर चाहिन्छ जाँच्नुहोस्। केही उपकरणले रोचक ट्राफिक देखिएपछि मात्र टनेल उठाउँछन्, जुन रोचक ट्राफिक कहिल्यै नआउने स्वास्थ्य जाँच नबनेसम्म ठीक छ।

म्यानुअल सुरुवातको समयमा उपकरणमा IKE आदानप्रदान हेर्नुहोस्; त्यहाँको मौनता राउटिङ वा फायरवालको जवाफ हो, Azure को जवाफ होइन।

चरण 3: पियरको ठेगाना ठीकसँग राख्नुहोस्

Azure लाई आफ्नो स्थानीय सञ्जाल गेटवे वस्तुमा पियरका लागि पुग्न सकिने सार्वजनिक ठेगाना चाहिन्छ, सामान्यतया उपकरणको भित्री ठेगाना होइन, अनुवादकको सार्वजनिक ठेगाना। उपकरणले जुन पहिचानले प्रमाणित गर्छ त्यो छुट्टै फिल्ड हो र Azure ले डायल गर्ने ठेगानाभन्दा कानुनी रूपमा फरक हुन सक्छ। दुवैलाई छुट्टै राख्नुहोस्, किनकि तिनी साट्दा NAT समस्याजस्तै देखिने प्रमाणीकरण असफलता आउँछ।

यदि सार्वजनिक ठेगाना बदलिन्छ भने त्यो वस्तु पनि त्यसैसँग बदलिनुपर्छ। पुरानो ठेगानामा रिजोल हुने नाम हातले अद्यावधिक गर्नुपर्ने स्थिर ठेगानाभन्दा नराम्रो हो।

तीनवटै मान लेख्नुहोस्: उपकरणको स्थानीय ठेगाना, अनुवादित सार्वजनिक ठेगाना, कन्फिगर गरिएको पियर पहिचान।

चरण 4: NAT-T लाई चाहिने पोर्ट मात्र खोल्नुहोस्

NAT-T ले UDP भित्र ESP बोक्छ, र RFC 3948 ले त्यो इन्क्याप्सुलेसन वर्णन गर्छ जसमा पोर्ट 500 मा प्रारम्भिक वार्तापछि पोर्ट 4500 प्रयोग हुन्छ। तपाईंको फायरवाल र अनुवादक दुवैले आदानप्रदान र त्यसको फिर्ती ट्राफिक अनुमति दिनुपर्छ। असम्बन्धित TCP पोर्ट अनुमति दिँदा यो मार्गबारे केही प्रमाणित हुँदैन, र बाहिर जान अनुमति दिने तर जवाफ नदिने नियम पनि असफल हुन्छ।

पियरले सुरु गरे र अनुवादकले स्थिति राखे स्थिर इनबाउन्ड पोर्ट फर्वार्ड स्वतः आवश्यक हुँदैन। म्यापिङ अस्थिर हुँदा वा मार्गमा केहीले स्थिति आक्रामक रूपमा सकाउँदा यो आवश्यक हुन्छ।

अनुवादकको दुवैतिर एकपटक क्याप्चर गर्नुहोस्; इन्क्याप्सुलेसनको फरक तुरुन्तै देखिन्छ।

चरण 5: बाहिरी यातायातलाई भित्री राउटिङबाट अलग गर्नुहोस्

स्थापित हुने तर केही नबोक्ने टनेल राउटिङ समस्या हो, NAT-T समस्या होइन। साइटहरूलाई अझै मिल्ने ट्राफिक चयनकर्ता, मिल्दो ठेगाना क्षेत्र, पहुँच नियम र अनुप्रयोग सञ्जालका लागि फिर्ती मार्ग चाहिन्छ। यीमध्ये केही पनि सफल IKE आदानप्रदानले दिँदैन।

यदि दुई साइटले एकअर्कामा पर्ने निजी दायरा प्रयोग गर्छन् भने टनेलभित्रको अनुवाद आफ्नै नियम भएको छुट्टै डिजाइन हो। बाहिरी गेटवे घरायसी राउटर पछाडि छ भन्ने मात्र कारणले सबनेट पुनःनम्बर नगर्नुहोस्।

केही बदल्नुअघि असफलतालाई चरणअनुसार वर्गीकरण गर्नुहोस्, र त्यो वर्गीकरण टिकटमा राख्नुहोस् ताकि अर्को व्यक्ति तपाईं रोकिएको ठाउँबाट सुरु गर्न सकोस्।