Azure P2S VPN का रिटर्न ट्रैफ़िक केवल एक ही दिशा में काम करता है

टनल आइकन हरा है, NSG अनुमति देता दिखता है, प्रभावी रूट सही दिखते हैं, फिर भी VM जुड़े क्लाइंट की ओर वापस कनेक्शन नहीं खोल सकता। सामान्य धारणा यह है कि काम करने वाला point-to-site टनल सममित होता है: यदि क्लाइंट VM तक पहुँच सकता है, तो VM भी क्लाइंट तक पहुँच सकता है। यही धारणा तर्क की गलती है, कॉन्फ़िगरेशन की नहीं। एक टनल बिना माँगे गए प्रवाह की एक दिशा ले जा सकता है और दूसरी गिरा सकता है, और सुधार इस पर निर्भर करता है कि कौन-सी परत उसे गिरा रही है।

मिथक: जुड़ा हुआ टनल दो-तरफ़ा टनल होता है

VPN टनल एक नीति-पथ है, तार नहीं। हर दिशा को सेलेक्टर, रूट और फ़िल्टर से मिलाया जाता है, और इनमें से कोई भी एक दिशा को अनुमति देकर दूसरी को रोक सकता है।

व्यवहार में असममिति इतनी सामान्य है कि दिशा पहली जाँच में होनी चाहिए, आख़िरी में नहीं। क्लाइंट शुरू करता है, गेटवे प्रवाह का पीछा करता है, और उत्तर बनी हुई स्थिति का अनुसरण करता है। नया प्रवाह शुरू करने वाले VM के पास ऐसी स्थिति नहीं होती, इसलिए वह इस पर निर्भर है कि वापसी पथ स्पष्ट रूप से रूट-योग्य और अनुमत हो। जब वह पथ न हो, तो किसी भी एप्लिकेशन के देखने से पहले ही कनेक्शन का प्रयास समाप्त हो जाता है।

पहुँच जाँचने से पहले दिशा जाँचें

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

अगला कदम साक्ष्य है, और नियम नहीं। VM सबनेट पर NSG को दोनों दिशाओं में जाँचें, VM के NIC पर प्रभावी रूट पढ़ें, और जब क्लाइंट ट्रैफ़िक भेज रहा हो तब VM पर पैकेट कैप्चर करें। बिना उत्तर आने वाला अनुरोध फ़िल्टर या वापसी-रूट की समस्या है; कभी न पहुँचने वाला अनुरोध पथ की समस्या है। विफल ping को VM के अप्राप्य होने का प्रमाण न मानें, क्योंकि ICMP नीति TCP के चलने के दौरान उत्तर गिरा सकती है।

IKEv2 point-to-site वापसी पथ ही सामान्य संदिग्ध है

इस लेख के पीछे की Azure रिपोर्ट में, एक क्लाइंट IKEv2 के ज़रिए VM तक पहुँच सकता था, लेकिन VM से क्लाइंट की ओर आने वाला ICMP तब तक विफल रहा जब तक गेटवे का टनल प्रकार OpenVPN पर नहीं बदला गया। रिपोर्टर बताता है कि Microsoft ने IKEv2 point-to-site पथ में एक सीमा की पुष्टि की, जहाँ VM से क्लाइंट की ओर वापसी ट्रैफ़िक सममित रूप से रूट नहीं होता जब तक क्लाइंट ने सत्र शुरू न किया हो। IKEv2 ट्रैफ़िक सेलेक्टर पर निर्भर करता है, और गेटवे ने उस स्थिति में वापसी दिशा का पालन नहीं किया।

इससे OpenVPN सामान्य रूप से बेहतर टनल प्रकार नहीं बन जाता। इससे इस कार्यभार के लिए परीक्षण मैट्रिक्स में टनल प्रकार एक चर बन जाता है।

टनल प्रकार बदलना सेवा परिवर्तन है, टॉगल नहीं। हर क्लाइंट को संगत प्रोफ़ाइल चाहिए, और गेटवे को भिन्न प्रमाणपत्र या प्रमाणीकरण सेटअप चाहिए हो सकता है। एक परीक्षण क्लाइंट और एक परीक्षण VM के साथ एकतरफ़ा व्यवहार दोहराएँ, स्वीकृत समय-सारणी पर प्रकार बदलें, और फिर वही दिशा-परीक्षण दोहराएँ। यदि व्यवहार बदलाव के बाद भी बना रहे, तो टनल प्रकार कारण नहीं था और आपने उत्पादन को छुए बिना समस्या को सीमित कर लिया।

मिथक: ब्रॉडकास्ट खोज VNet की सीमा पार करती है

दूसरी धारणा असंबद्ध कारण से विफल होती है। Azure का वर्चुअल नेटवर्क ब्रॉडकास्ट ट्रैफ़िक नहीं ले जाता, इसलिए VM site-to-site या point-to-site कनेक्शन पर ऑन-प्रिमाइज़ नेटवर्क से ब्रॉडकास्ट फ़्रेम नहीं पा सकता। ब्रॉडकास्ट से साथी खोजने वाले एप्लिकेशन, जैसे पुरानी फ़ाइल ब्राउज़िंग या कुछ डिवाइस-खोज प्रोटोकॉल, रूट कैसे भी लिखे गए हों, दूर का पक्ष कभी नहीं देखेंगे।

ब्रॉडकास्ट खोज को DNS नाम, निर्देशिका सेवा या स्पष्ट साथी-सूची से बदलें। यदि एप्लिकेशन के पास unicast विकल्प नहीं है, तो डिज़ाइन को चौड़ा टनल नहीं, बल्कि भिन्न खोज तंत्र चाहिए।

क्या बदलें, और इसे कैसे सिद्ध करें

यदि दिशा-परीक्षण केवल IKEv2 पर विफल होता है, तो गेटवे का टनल प्रकार, क्लाइंट पता पूल और सटीक ICMP या TCP परीक्षण दर्ज करें, फिर प्रभावित क्लाइंट के लिए स्वीकृत OpenVPN प्रोफ़ाइल का मूल्यांकन करें। यदि यह हर टनल प्रकार पर विफल होता है, तो वापसी पथ पर काम करें: क्लाइंट पता VM सबनेट से रूट-योग्य होना चाहिए, उपयोगकर्ता-परिभाषित कोई भी रूट मान्य अगले हॉप की ओर इंगित करना चाहिए, और क्लाइंट फ़ायरवॉल को आने वाला प्रवाह स्वीकार करना चाहिए। NSG और रूट के साक्ष्य टिकट के साथ संलग्न करें।

एप्लिकेशन से सत्यापित करें, ping से नहीं। बदलाव के बाद सफल ICMP अदला-बदली सेवा पोर्ट, उसके प्रमाणीकरण या नाम-विश्लेषण के बारे में कुछ नहीं कहती। पुनः कनेक्ट के बाद परीक्षण दोहराएँ, क्योंकि पूल से भिन्न पता पाने वाला क्लाइंट परिणाम बदल सकता है। फिर क्लाइंट के सोने और जागने के बाद इसे एक बार और दोहराएँ, क्योंकि फिर से शुरू हुए सत्र में ही एकतरफ़ा व्यवहार अक्सर लौटता है।