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 मेहमान की रूट टेबल नहीं हैं, और उन्हें संपादित करने से स्थानीय पॉलिसी नियम ठीक नहीं होगा।