Azure S2S VPN कनेक्टेड है पर ट्रैफ़िक नहीं: IKE लॉग पढ़ें

पोर्टल Connected कहता है, टनल में अपटाइम काउंटर है, और आपकी वर्चुअल मशीन से लिया गया trace दूसरे hop पर मर जाता है। कनेक्शन की स्थिति 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 ऐसा दिखता है: पहला hop ऑन-प्रिमाइज़ गेटवे है, फिर कुछ बिना जवाब वाले hop, फिर दूर का होस्ट जवाब देता है। यदि trace कभी होस्ट तक नहीं पहुँचता, तो वह TCP पोर्ट जाँचें जो एप्लिकेशन वास्तव में उपयोग करता है, क्योंकि ICMP इतनी बार फ़िल्टर होता है कि विफल ping बहुत कम प्रमाणित करता है। वही trace किसी दूर के होस्ट से Azure की वर्चुअल मशीन की ओर चलाएँ। दोनों परिणामों के बीच असममिति ही गुम रिटर्न रूट या केवल एक दिशा की अनुमति देने वाला नियम खोजने का सबसे तेज़ तरीका है।

पीयर प्रस्ताव, दोनों एड्रेस स्पेस और कनेक्शन बनने का समय टिकट में लिखें, ताकि अगले इंजीनियर को पता हो कि कौन-से मान फिर से बनाए गए और किन्हें कभी छुआ नहीं गया।

यदि लॉग खाली लौटता है, तो हो सकता है गेटवे आपका कनेक्शन बिल्कुल भी समाप्त न कर रहा हो। पुष्टि करें कि लोकल नेटवर्क गेटवे पर पीयर पता उस डिवाइस से मेल खाता है जिससे आप लॉग पढ़ रहे हैं, क्योंकि एक ही सदस्यता में दो गेटवे फिर से बनाते समय आसानी से गड्डमड्ड हो जाते हैं। वह गलती एक दिन लेती है और किसी भी लॉग में कोई निशान नहीं छोड़ती।