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 कडे प्रत्यक्षात काय आहे याची यादी करतात. दोन्ही चालवा आणि हिरवे IP फ्लो व्हेरिफाय रिकामे सोडते तो Azure बाजूचा मार्ग तुम्हाला मिळेल.

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 निकाल आणि बरोबर पुढील हॉप हे पुराव्याचे दोन तुकडे आहेत, कनेक्शन यशस्वी झाले याचा पुरावा नाही.