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 देवघेव सेवा पोर्ट, त्याचे प्रमाणीकरण किंवा नाव-निराकरण याबद्दल काहीही सांगत नाही. पुन्हा कनेक्ट झाल्यानंतर चाचणी पुन्हा करा, कारण पूलमधून वेगळा पत्ता मिळालेला क्लायंट निकाल बदलू शकतो. नंतर क्लायंट झोपल्यानंतर आणि उठल्यानंतर अजून एकदा पुन्हा करा, कारण पुन्हा सुरू झालेल्या सत्रातच एकदिशी वर्तन अनेकदा पुन्हा दिसते.