Azure P2S VPN को फिर्ती ट्राफिक एउटै दिशामा मात्र काम गर्छ

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

भ्रम: जोडिएको टनेल दुईतर्फी टनेल हो

VPN टनेल नीति-मार्ग हो, तार होइन। प्रत्येक दिशा चयनकर्ता, रुट र फिल्टरसँग मिलाइन्छ, र तीमध्ये कुनै पनि एउटा दिशालाई अनुमति दिँदै अर्कोलाई रोक्न सक्छ।

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

पहुँचयोग्यता जाँच्नुअघि दिशा जाँच्नुहोस्

एउटा क्लाइन्ट ठेगाना, एउटा VM ठेगाना र एउटा प्रोटोकल छान्नुहोस्। क्लाइन्टबाट जोडिनुहोस् र नतिजा लेख्नुहोस्; त्यसपछि त्यही परीक्षण VM बाट सुरु गर्नुहोस् र त्यो पनि लेख्नुहोस्। पहिलो सफल र दोस्रो असफल भएमा क्लाइन्ट पूल, गेटवे सम्बन्ध र क्लाइन्टदेखि VNet सम्मको मार्ग सबै काम गरिरहेका छन्।

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

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 आदानप्रदानले सेवा पोर्ट, त्यसको प्रमाणीकरण वा नाम-समाधानबारे केही भन्दैन। पुनः जोडिएपछि परीक्षण दोहोर्याउनुहोस्, किनकि पूलबाट फरक ठेगाना पाउने क्लाइन्टले नतिजा बदल्न सक्छ। त्यसपछि क्लाइन्ट सुतेर उठेपछि अझै एक पटक दोहोर्याउनुहोस्, किनकि पुनः सुरु भएको सत्रमै एकतर्फी व्यवहार प्रायः फेरि देखा पर्छ।