VPN सुरू झाल्यानंतर Azure VM IMDS किंवा WireServer पर्यंत पोहोचत नाही

VM सुरू आहे, VPN क्लायंट कनेक्टेड असल्याचे सांगतो, आणि काही मिनिटांनंतर Azure एजंट अस्वस्थ स्थिती नोंदवू लागतो. कधीकधी SSH टिकते आणि पोर्टलचे Run Command टिकत नाही, ज्यामुळे लोक रूट टेबलऐवजी एजंटकडे पाहतात. टनेल वर आल्यावर गेस्टचे स्वतःचे फॉरवर्डिंग निर्णय बदलले, आणि सामान्यतः दोन प्लॅटफॉर्म पत्ते पहिले बळी ठरतात. मी हे एजंट बिघाड मानण्यापूर्वी राउटिंग लक्षण मानतो.

लक्षण तुटलेल्या एजंटसारखे दिसते

खालील दोन्ही पत्ते उपाय म्हणून सुचवले जातात, पण ते एकच सेवा नाही. एकासाठी /32 कॉपी करणे कारण ते दुसऱ्यासाठी चालले—अशाच प्रकारे तात्पुरता उपाय कुणीही काढण्याची हिंमत न करणारी कायमची कॉन्फिगरेशन बनते.

जो क्रम चालतो तो असा: आधी अपयशी कॉल प्रत्यक्षात कोणत्या पत्त्याला लक्ष्य करतो हे तपासा, नंतर गेस्ट तो कसा सोडवतो ते वाचा. बाकी सर्व जास्तीच्या पायऱ्यांसह अंदाज आणि मोठी बदल विंडो आहे.

168.63.129.16 सार्वजनिक गंतव्य नाही

168.63.129.16 हा Azure चा विशेष व्हर्च्युअल प्लॅटफॉर्म पत्ता आहे, आणि त्याची एक भूमिका WireServer आहे, जी VM एजंट फॅब्रिकशी बोलण्यासाठी वापरतो. Microsoft नोंदवते की एजंटचा TCP 80 आणि 32526 पोर्टवरील रहदारी उपलब्ध राहिली पाहिजे. हा सामान्य इंटरनेट होस्ट नाही, आणि पूर्ण-टनेल VPN ने तो दूरच्या एक्झिटकडे नेऊ नये. म्हणूनच निरोगी दिसणारे टनेलही एजंटला उपाशी ठेवू शकते.

प्लॅटफॉर्म पत्त्याचे दस्तऐवज हे देखील सांगते की हा पत्ता वापरकर्ता-परिभाषित रूटच्या अधीन नाही, जो Azure फॅब्रिकचा गुणधर्म आहे, तुमच्या गेस्टबद्दलचे वचन नाही. स्थानिक फायरवॉल नियम किंवा VPN क्लायंटचे स्वतःचे राउटिंग धोरण अजूनही मार्ग तोडू शकते, आणि त्यातील काहीही VNet च्या रूट टेबलमध्ये राहत नाही.

जर एजंटच समस्येची नोंद करत असेल, तर काहीही पुन्हा इन्स्टॉल करण्यापूर्वी सेवेची स्थिती आणि त्या पत्त्यापर्यंतचा मार्ग तपासा.

169.254.169.254 चे स्वतःचे नियम आहेत

169.254.169.254 हा Azure Instance Metadata Service साठीचा link-local पत्ता आहे. त्याकडे जाणाऱ्या विनंत्यांना स्वतःच्या अटी आहेत: प्राथमिक NIC आणि प्राथमिक IP, पत्त्याला आधार देणारे DHCP कॉन्फिगरेशन, आणि कोणताही HTTP प्रॉक्सी बायपास करणे. त्या दूरच्या VPN एक्झिटमधून किंवा कोणत्याही इंटरनेट गेटवेमधून पाठवणे हे Microsoft वर्णन करते ते प्रवेश मॉडेल नाही.

ती प्रॉक्सी अट मार्ग दुरुस्त केलेल्या पण अजूनही अपयश पाहणाऱ्यांना पकडते. गेस्ट HTTP प्रॉक्सी IMDS तोडू शकतो, तर ip route get तुम्ही अपेक्षित तोच इंटरफेस परत देतो, म्हणून मार्गांसोबत प्रॉक्सी अपवादही तपासा.

हे डीबग करताना मेटाडेटा प्रतिसाद सपोर्ट तिकिटात पेस्ट करू नका. त्यात घटनेपेक्षा जास्त काळ टिकणारी क्रेडेन्शियल्स आणि इन्स्टन्स तपशील असू शकतात.

गेस्टचे धोरण राउटिंग वाचा, फक्त मुख्य टेबल नाही

Linux गेस्टवर तीन फक्त-वाचन आदेश स्तर वेगळे करतात: धोरण नियमांसाठी ip -4 rule show, नंतर कर्नेल प्रत्यक्षात घेत असलेल्या निर्णयांसाठी ip -4 route get 168.63.129.16 आणि ip -4 route get 169.254.169.254. VPN जोडण्यापूर्वी आणि नंतर ते चालवा. त्या दोन आउटपुटमधील फरक हा तुमचा बदल-संच आहे, आणि क्लायंटने काय केले याच्या कोणत्याही अंदाजापेक्षा तो उपयुक्त आहे.

धोरण नियम इन्स्टॉल करणारा VPN क्लायंट मुख्य टेबलला हात न लावता ती शोध वळवू शकतो. म्हणून फक्त मुख्य टेबल दुरुस्त करणारा उपाय एका होस्टवर चालताना दिसतो आणि पुढच्यावर काहीच करत नाही. अनेक NIC असलेले गेस्ट तीच समस्या दुसऱ्या बाजूने जोडतात, कारण उत्तर नियम कोणता NIC आणि स्रोत पत्ता निवडतो यावर अवलंबून असते.

जुन्या गेटवेमधून दोन्ही /32 मार्ग जोडणाऱ्या कृतीला विरोध करा. link-local प्लॅटफॉर्म मार्ग आणि सामान्य WAN पुढील हॉप वेगवेगळ्या वस्तू आहेत, आणि सर्वसमावेशक अपवाद खरा धोरण संघर्ष लपवतो.

प्रशासन आणि पुनर्प्राप्ती वेगळी ठेवा

तुमचा SSH किंवा RDP प्रतिसादही पूर्ण-टनेल डीफॉल्टने पकडू शकतो, पण तो प्लॅटफॉर्म एंडपॉइंटऐवजी प्रशासकाच्या निरीक्षित पत्त्याला लक्ष्य करतो. त्याच्या स्वतःच्या विनंती-प्रतिसाद जोडीवरून निदान करा, आणि VPN धोरण बदलण्यापूर्वी सीरियल कन्सोलसारखा स्वतंत्र पुनर्प्राप्ती मार्ग ठेवा. तैनातीने VM पुन्हा सुरू केले आणि एजंटने अस्वस्थता नोंदवली, तर मार्ग बदलामुळे रीबूट झाला असे गृहीत धरण्याऐवजी नोंदवलेली क्रिया आणि जबाबदार सेवा तपासा.

नंतर तीन प्रवाह स्वतंत्रपणे तपासा: तुम्हाला प्रत्यक्षात हवे असलेले खाजगी संसाधन, समर्थित एजंट आणि प्लॅटफॉर्म संवाद, आणि प्रशासन मार्ग. एक पुनर्संचयित करणे बाकीचे दोन टिकले याचा पुरावा नाही.

मंजूर अपवाद गेस्ट नेटवर्क आणि VPN कॉन्फिगरेशनच्या मालकाच्या नावावर लिहा, पुन्हा कनेक्ट आणि पुन्हा सुरू करताना काय होते यासह. Azure UDR गेस्टचे रूट टेबल नाहीत, आणि ते संपादित केल्याने स्थानिक धोरण नियम सुधारणार नाही.