Azure का IP फ़्लो वेरिफ़ाई कहता है अनुमत, पर VPN फिर भी विफल रहता है

साइट-टू-साइट टनल जुड़ा है, VM स्वस्थ है, पर ऑन-प्रिमाइज़ क्लाइंट को कुछ नहीं मिलता। आप Network Watcher खोलते हैं, IP फ़्लो वेरिफ़ाई चलाते हैं, और वह कहता है Access allowed, इसलिए टिकट VPN समस्या के रूप में बंद हो जाता है। यह परिणाम वह नहीं है जो दिखता है, क्योंकि IP फ़्लो वेरिफ़ाई आपके बताए फ़्लो के सुरक्षा नियमों का मूल्यांकन करता है और कभी यह नहीं जाँचता कि Azure के पास आपके ऑन-प्रिमाइज़ प्रीफ़िक्स तक कोई रूट है या नहीं।

फ़िल्टरिंग का प्रश्न और रूटिंग का प्रश्न अलग हैं, और Network Watcher इनका उत्तर अलग-अलग औज़ारों से देता है। यह जानना कि आपने कौन-सा पूछा, निदान का बड़ा हिस्सा है।

IP फ़्लो वेरिफ़ाई वास्तव में क्या तय करता है

IP फ़्लो वेरिफ़ाई एक VM, एक नेटवर्क इंटरफ़ेस, एक दिशा, पाँच-मान और एक प्रोटोकॉल लेता है, फिर उस फ़्लो के लिए NSG और सुरक्षा-व्यवस्थापक नियम का निर्णय बताता है। यह TCP और UDP पर काम करता है, इसलिए यह ICMP नियम परीक्षक नहीं है और अवरुद्ध ping आपकी सेवा के बारे में कुछ सिद्ध नहीं करता। इसे अनुमान के बजाय असली फ़्लो दें। ऑन-प्रिमाइज़ से डेटाबेस पोर्ट तक का इनबाउंड कनेक्शन, VM द्वारा शुरू किए आउटबाउंड कनेक्शन से अलग विवरण है।

अगर गेटवे पतों का अनुवाद करता है, तो वह स्रोत पता इस्तेमाल करें जो आपके द्वारा मूल्यांकित सीमा तक पहुँचता है, क्लाइंट कॉन्फ़िग में वाला नहीं। परिणाम को भी जैसा है वैसा पढ़ें। Access allowed का अर्थ है कि फ़िल्टर परत पैकेट आने पर अनुमति देती, और इससे अधिक कुछ नहीं।

जो यह आपको नहीं बता सकता वह है Azure द्वारा चुना गया रूट, क्या गेस्ट फ़ायरवॉल पोर्ट की अनुमति देता है, या क्या कुछ सुन रहा है। वे अन्य परतों में रहते हैं।

अगला हॉप और प्रभावी रूट क्या जोड़ते हैं

अगला हॉप फ़ॉरवर्डिंग का प्रश्न उत्तर देता है: इस गंतव्य के लिए Azure कौन-सा अगला-हॉप प्रकार चुनता है, किस पते पर, किस रूट तालिका से। प्रभावी रूट सूचीबद्ध करते हैं कि NIC के पास वास्तव में क्या है। दोनों चलाएँ और आपको Azure पक्ष का वह पथ मिलेगा जिसे हरा IP फ़्लो वेरिफ़ाई खाली छोड़ देता है।

Microsoft का IP फ़्लो वेरिफ़ाई अवलोकन फ़िल्टरिंग का दायरा सीधे बताता है, जबकि अगले हॉप और रूट-निदान पृष्ठ फ़ॉरवर्डिंग पक्ष को कवर करते हैं। निष्कर्ष लिखते समय सही पृष्ठ उद्धृत करें।

कमांड शेल से चलाने के लिए काफ़ी छोटे हैं। az network nic show-effective-route-table इंटरफ़ेस पर लागू रूट की सूची देता है। az network watcher show-next-hop स्रोत और गंतव्य के साथ चुना गया हॉप लौटाता है। आपके लिए महत्वपूर्ण प्रीफ़िक्स की उस तालिका से तुलना करें, फिर पुष्टि करें कि कौन-सी प्रविष्टि जीतती है।

VM के NIC से वापसी पथ पर चलें

यह लक्ष्य VM के NIC से, ऑन-प्रिमाइज़ क्लाइंट प्रीफ़िक्स के लिए करें, इंटरनेट के लिए नहीं। वापसी पथ वही जगह है जहाँ साइट-टू-साइट खराबियाँ छिपती हैं, क्योंकि टनल-स्थिति जाँच केवल बताती है कि सुरक्षा संबद्धताएँ चालू हैं।

अगर अपेक्षित रूट नहीं है, तो गेटवे कॉन्फ़िगरेशन द्वारा दिए गए दूरस्थ प्रीफ़िक्स, VNet कनेक्टिविटी डिज़ाइन और किसी भी रूट-प्रसार सेटिंग की जाँच करें। स्थानीय नेटवर्क गेटवे ऑब्जेक्ट ऑन-प्रिमाइज़ पक्ष का वर्णन करता है; उसका होना यह सिद्ध नहीं करता कि हर आवश्यक प्रीफ़िक्स NIC पर मौजूद है और पसंद किया जाता है। ये अलग तथ्य हैं, और पोर्टल सारांश में इनमें से केवल एक दिखता है।

उदाहरण कॉपी करने के बजाय अगले हॉप का प्रकार पढ़ें

प्रबंधित VPN गेटवे पथ सामान्यतः अगले हॉप प्रकार के रूप में VirtualNetworkGateway दिखाता है। VirtualAppliance भिन्न फ़ॉरवर्डिंग डिज़ाइन का वर्णन करता है, सामान्यतः फ़ायरवॉल या नेटवर्क वर्चुअल उपकरण।

किसी पुराने फ़ोरम उत्तर ने वह प्रकार इस्तेमाल किया था, इसलिए अनुमानित VPN एंडपॉइंट की ओर उपकरण रूट न बनाएँ। अगर उपयोगकर्ता-परिभाषित रूट इच्छित पथ को ओवरराइड करता है, तो उसे बदलने से पहले उसका स्वामी और उद्देश्य खोजें। दूसरा NIC भी बदल सकता है कि गेस्ट कौन-सा इंटरफ़ेस इस्तेमाल करता है, और उसे हटाना इस रूट को ठीक करने के बजाय दूसरी सेवा तोड़ सकता है।

उस सीमा पर जाएँ जो अभी भी विफल है

जब फ़िल्टरिंग और रूटिंग दोनों डिज़ाइन से मेल खाते हैं, तो खराबी कहीं और है। गेस्ट की अपनी रूट तालिका, उसका फ़ायरवॉल और यह जाँचें कि लिसनर अपेक्षित पते से बंधा है या नहीं। फिर VPN के संरक्षित ट्रैफ़िक चयनकर्ता और ऑन-प्रिमाइज़ उत्तर पथ जाँचें। इनमें से प्रत्येक अलग परिणाम वाला अलग परीक्षण है।

अनुमत एप्लिकेशन अनुरोध और दोनों सिरों की टिप्पणियों के साथ समाप्त करें। allow परिणाम और सही अगला हॉप प्रमाण के दो टुकड़े हैं, यह प्रमाण नहीं कि कनेक्शन सफल हुआ।