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 आदान-प्रदान नहीं देता।

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

कुछ भी बदलने से पहले विफलता को चरण के अनुसार वर्गीकृत करें, और वह वर्गीकरण टिकट में रखें ताकि अगला व्यक्ति वहीं से शुरू करे जहाँ आप रुके थे।