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 देवाणघेवाण देत नाही.

दोन्ही साइट एकमेकांवर चढणार्या खाजगी श्रेणी वापरत असतील तर बोगद्यातील भाषांतर स्वतःच्या नियमांसह वेगळी रचना आहे. फक्त बाहेरील गेटवे घरगुती राउटरच्या मागे आहे म्हणून सबनेटचे पुनर्क्रमांकन करू नका.

काहीही बदलण्यापूर्वी अयशस्वीतेचे टप्प्यानुसार वर्गीकरण करा, आणि ते वर्गीकरण तिकिटात ठेवा जेणेकरून पुढील व्यक्ती तुम्ही थांबलात तिथून सुरुवात करेल.