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 नतिजा र सही अर्को हप प्रमाणका दुई टुक्रा हुन्, जडान सफल भयो भन्ने प्रमाण होइन।