Azure S2S VPN कनेक्टेड आहे पण ट्राफिक नाही: IKE लॉग वाचा

पोर्टल Connected म्हणते, टनेलला अपटाइम काउंटर आहे, आणि तुमच्या व्हर्च्युअल मशीनमधून आलेला trace दुसऱ्या हॉपवर मरतो. कनेक्शनची स्थिती IKE आणि IPsec वाटाघाटीचे वर्णन करते, दोन्ही बाजूंना एकही पॅकेट धोरण स्तरातून जातो का हे नाही. यापैकी बहुतेक तिकिटांचे कारण दोन त्रुटी आहेत आणि त्यांपैकी एकही Azure मार्ग बदलून दुरुस्त होत नाही. दोन्ही आधीच गेटवेने तयार केलेल्या लॉगमध्ये लिहिलेल्या आहेत, म्हणून मी मार्ग तक्त्यातून नाही, तिथून सुरुवात करतो.

Connected प्रत्यक्षात काय प्रमाणित करते

कनेक्टेड साइट-टू-साइट कनेक्शनचा अर्थ असा आहे की टप्पा 1 आणि टप्पा 2 पूर्ण झाले आणि सुरक्षा संघटना सक्रिय आहेत. हे वाटाघाटीबद्दलचे विधान आहे: दोन्ही पीअर एका प्रस्तावावर सहमत झाले, किल्ल्या बदलल्या आणि SA ची जोडी स्थापित केली. तुम्ही संरक्षित मानता त्या सबनेटशी ट्राफिक निवडक जुळतात का, किंवा डिक्रिप्ट केल्यानंतर दुसरी बाजू पॅकेटला कुठे मार्गस्थ करेल का, याबद्दल ते काहीही सांगत नाही. टनेल आठवड्यांनुसार सुरू राहू शकते आणि प्रत्येक मनोरंजक प्रवाह टाकून देऊ शकते, आणि निरोगी गेटवे पुन्हा बांधण्यास प्रवृत्त करणारा हाच नमुना आहे.

प्रथम तपासण्यासारख्या दोन त्रुटी म्हणजे ESP ऐवजी AH प्रस्तावित करणारा पीअर, आणि गेटवे अंतर्गत मानणार नाही अशा जागेत क्रमांकित व्हर्च्युअल नेटवर्क.

मार्गांना स्पर्श करण्यापूर्वी निर्यात केलेला लॉग उघडा

पोर्टलमध्ये व्हर्च्युअल नेटवर्क गेटवे उघडा आणि कनेक्शनवर VPN troubleshoot क्रिया चालवा, नंतर तयार होणारे बंडल डाउनलोड करून उघडा. आत टप्पा 1 आणि टप्पा 2 च्या देवघेवीसह IKE लॉग आहे, वेळ-मुद्रांसह आणि साधा मजकूर म्हणून वाचनीय. त्यात transform ओळ शोधा, वरून खाली वाचू नका, कारण मनोरंजक नोंद सहसा काहीशे ओळींनंतर असते. पोर्टलमध्ये प्रवेश नसल्यास, डायग्नोस्टिक सेटिंग्ज सुरू असताना तीच डायग्नोस्टिक्स गेटवेच्या लॉग गंतव्यस्थानात दिसतात.

दोन नोंदी बहुतांश मूल्य वाहतात. पहिली अंदाजे अशी वाचली जाते: expected ESP with combined authentication and cipher, received AH. दुसरी IKE देवघेवीदरम्यान invalid payload त्रुटी आहे, ज्याचा अर्थ सहसा चुकीच्या स्वरूपातील किंवा असमर्थित प्रस्ताव फील्ड असा होतो.

दोन्ही ऑन-प्रिमाइस उपकरणाने काय प्रस्तावित केले हे सांगतात, म्हणून दोन्ही पीअर बाजूच्या सेटिंग्ज आहेत. कनेक्शनची Azure बाजू पुन्हा तयार केल्याने तुमचा फायरवॉल पाठवणारा प्रस्ताव बदलत नाही, आणि तसे करूनही हा कामाच्या प्रवाहातील सर्वात जास्त वाया जाणारा तास आहे. पीअरवर टप्पा 2 एकत्रित प्रमाणीकरण आणि सिफरसह ESP वर ठेवा आणि अल्गोरिदम वाटाघाटीसाठी सोडा, नंतर तपासा की combined mode असे नाव असलेला विक्रेता चेकबॉक्स खालून गुपचूप AH प्रस्ताव निवडत आहे का.

व्हर्च्युअल नेटवर्कची पत्ता स्पेस निश्चित करा

गेटवे अपेक्षा करतो की व्हर्च्युअल नेटवर्क खाजगी श्रेणींमध्ये असेल. सार्वजनिक ब्लॉकमध्ये क्रमांकित नेटवर्क, उदाहरणार्थ 111.x ने सुरू होणारे, टनेल उभे करू शकते पण Azure ती जागा अंतर्गत मानण्यास नकार देते, त्यामुळे कनेक्शन निरोगी दिसते आणि एकही प्रवाह स्वीकारला जात नाही. निवडकांवर दुपार वाया घालवण्यापूर्वी पत्ता स्पेस निश्चित करा. क्रमांकन जुन्या वाटपातील कठोर आवश्यकता असल्यास, उपाय दुसरे गेटवे नाही तर पत्ता योजना बदलणे आहे.

पत्ता स्पेस ब्लेडमध्ये असतानाच ऑन-प्रिमाइस श्रेणींशी होणारा ओव्हरलॅप नोंदवा, कारण ओव्हरलॅपिंग प्रीफिक्स वेगळ्या प्रकारचे अपयश निर्माण करतात जे क्लायंटकडून सारखेच दिसते.

दोन्ही दिशांनी प्रीफिक्स तपासा

स्थानिक नेटवर्क गेटवे संसाधन ऑन-प्रिमाइस प्रीफिक्स ठेवते आणि ते दूरचे उपकरण प्रत्यक्षात संरक्षित करते त्या सबनेटशी जुळले पाहिजेत. उपकरण टाकून देते अशा पत्त्यांचा समावेश असलेला सारांश काही प्रवाह पार करेल आणि इतरांमध्ये अयशस्वी होईल, जे कॉन्फिगरेशन विसंगतीऐवजी अधूनमधून येणारे मार्ग अपयश म्हणून वाचले जाते. दूरची बाजूही पाहा: एक टोक /16 सूचीबद्ध करते तर दुसरे त्यातील तीन /24 सूचीबद्ध करते — हेच पारंपरिक अर्धवट अपयश आहे. कोणतीही यादी एकटी अधिकृत नाही, म्हणून तुम्हाला दिसणाऱ्यावर विश्वास ठेवण्याऐवजी दोन्ही शेजारी ठेवून तुलना करा.

प्रीफिक्स बदल नेहमी स्वतःहून घेतला जात नाही, म्हणून कनेक्शन ऑब्जेक्ट पुन्हा जतन करण्याची किंवा पुन्हा तयार करण्याची योजना करा आणि नंतर नवीन प्रीफिक्स दोन्ही बाजूंना दिसतात याची खात्री करा.

ping नाही, मार्ग तपासा

कार्यरत टनेलला कार्यरत मार्गापासून वेगळे करणारा trace असा दिसतो: पहिला हॉप ऑन-प्रिमाइस गेटवे, नंतर प्रतिसाद न देणारे काही हॉप, नंतर दूरचा होस्ट उत्तर देतो. trace कधीही होस्टपर्यंत पोहोचत नसेल, तर अनुप्रयोग प्रत्यक्षात वापरतो तो TCP पोर्ट तपासा, कारण ICMP पुरेशा वेळा फिल्टर होते की अयशस्वी ping फार कमी सिद्ध करतो. तोच trace दूरच्या होस्टवरून Azure मधील व्हर्च्युअल मशीनकडे चालवा. दोन्ही निकालांतील असममिती ही गहाळ परतीचा मार्ग किंवा फक्त एकाच दिशेला परवानगी देणारा नियम शोधण्याचा सर्वात वेगवान मार्ग आहे.

पीअर प्रस्ताव, दोन्ही पत्ता स्पेस आणि कनेक्शन तयार झाल्याची वेळ तिकिटात लिहा, जेणेकरून पुढील अभियंत्याला कोणती मूल्ये पुन्हा बांधली आणि कोणाला कधीही स्पर्श केला नाही हे कळेल.

लॉग रिकामा परत आल्यास, गेटवे तुमचे कनेक्शन अजिबात संपवत नसावे. स्थानिक नेटवर्क गेटवेवरील पीअर पत्ता तुम्ही लॉग वाचत असलेल्या उपकरणाशी जुळतो याची खात्री करा, कारण एकाच सदस्यत्वातील दोन गेटवे पुन्हा बांधताना सहज गोंधळतात. ती चूक एक दिवस घेते आणि कोणत्याही लॉगमध्ये खूण सोडत नाही.