Azure S2S VPN जोडिएको तर ट्राफिक छैन: IKE लग पढ्नुहोस्

पोर्टलले Connected भन्छ, टनेलसँग अपटाइम काउन्टर छ, र तपाईंको भर्चुअल मेसिनबाट आएको trace दोस्रो हपमा मर्छ। जडानको अवस्थाले IKE र IPsec वार्तालाप वर्णन गर्छ, कुनै पनि पक्षमा एउटा प्याकेट नीति तहबाट जान्छ कि जाँदैन भनेर होइन। यी टिकटमध्ये धेरैको कारण दुई त्रुटि हुन् र तीमध्ये एउटै पनि Azure मार्ग बदलेर सुधारिँदैन। दुवै पहिले नै गेटवेले बनाएको लगमा लेखिएका छन्, त्यसैले म मार्ग तालिकाबाट होइन, त्यहीँबाट सुरु गर्छु।

Connected ले वास्तवमा के प्रमाणित गर्छ

जोडिएको site-to-site जडानको अर्थ चरण 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 को भर्चुअल मेसिनतर्फ चलाउनुहोस्। दुई नतिजाबीचको असममिति नै हराएको फिर्ती मार्ग वा एउटा मात्र दिशा अनुमति दिने नियम भेट्ने सबैभन्दा छिटो उपाय हो।

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

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