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 अतिथिको रुट टेबल होइनन्, र ती सम्पादन गर्दा स्थानीय नीति नियम सुध्रने छैन।