Azure P2S: VNet बदलने के बाद एक Windows क्लाइंट के रूट गायब
जब कोई एक Windows P2S क्लाइंट नए VNet तक नहीं पहुँचता, तो उसके चुने गए रूट की तुलना करें और TTL सेटिंग छूने से पहले गेटवे पैकेज फिर से बनाएँ।
दो लैपटॉप एक ही Azure point-to-site गेटवे से प्रमाणित होते हैं, और केवल एक नए जुड़े VNet तक पहुँचता है। दोनों Connected दिखाते हैं, इसलिए प्रमाणीकरण अंतर नहीं है; अंतर वे गंतव्य रूट हैं जो वे रखते हैं। जो क्लाइंट विफल होता है उससे शुरू करें, एक गंतव्य की तुलना करें, और तभी तय करें कि अंतराल गेटवे पैकेज का है या स्थानीय रूट तालिका का।
गेटवे से नहीं, जो क्लाइंट विफल होता है उससे शुरू करें
लैपटॉप को दोष देने से पहले टोपोलॉजी की पुष्टि करें। जाँचें कि कौन से VNet गेटवे VNet से जुड़े हैं और नया नेटवर्क सीधे पीयर है या अलग site-to-site टनल से पहुँचता है। अगर नया VNet गेटवे VNet से बिल्कुल जुड़ा नहीं है, तो कोई भी क्लाइंट पैकेज वहाँ रूट नहीं कर सकता, और जो लैपटॉप काम कर रहा है वही समझाने योग्य विसंगति है। उत्तर लिख लें, क्योंकि यह तय करता है कि आप क्लाइंट डीबग कर रहे हैं या गेटवे।
टोपोलॉजी सही होने पर दोनों लैपटॉप को पास-पास रखें। एक ही गेटवे, एक ही पता पूल, एक ही प्रोटोकॉल और एक ही क्लाइंट बिल्ड वही तुलना है जो आप चाहते हैं; बाकी सब दूसरा चर है जिसे बाद में हटाना होगा।
route print से एक गंतव्य की तुलना करें
अनुमत संसाधन IP चुनें और दोनों लैपटॉप की दो बार तुलना करें: डिस्कनेक्टेड, फिर कनेक्टेड। Windows में route print -4 IPv4 रूट को गंतव्य प्रीफ़िक्स, इंटरफ़ेस, अगले हॉप और मीट्रिक के साथ सूचीबद्ध करता है। VPN शब्द वाली प्रविष्टियाँ गिनने के बजाय वह पंक्ति दर्ज करें जो उस गंतव्य के लिए वास्तव में जीतेगी।
चयन पहले सबसे लंबे प्रीफ़िक्स से, फिर मीट्रिक से होता है, इसलिए अधिक विशिष्ट स्थानीय रूट गलत दिखे बिना टनल रूट को हरा सकता है। यदि इच्छित गंतव्य 10.24.0.0/16 के भीतर है, तो स्वस्थ क्लाइंट VPN इंटरफ़ेस पर मेल खाता रूट दिखाता है, जबकि विफल क्लाइंट वही पता अपने डिफ़ॉल्ट गेटवे को भेजता है।
टकराव वाला स्थानीय प्रीफ़िक्स वही लक्षण पैदा कर सकता है। कुछ भी जोड़ने से पहले तय करें कि आपके पास दो में से कौन-सी स्थिति है: बिल्कुल कोई टनल रूट नहीं, या ऐसा टनल रूट जो अधिक विशिष्ट से हार जाता है।
TTL expired रूट वितरण की खराबी नहीं है
जो ping TTL expired in transit लौटाता है वह कहता है कि पैकेट ने अपना हॉप कोटा खत्म कर लिया, जिसका अर्थ आमतौर पर फ़ॉरवर्डिंग लूप है, टूटा VPN ड्राइवर नहीं। Windows ping 255 तक TTL स्वीकार करता है, और मान बढ़ाना लूप ठीक नहीं करता; यह केवल वही त्रुटि टालता है। संदेश को पथ का लक्षण मानें, रूट वितरण का प्रमाण नहीं।
पथ कहाँ दोहराता है यह देखने के लिए tracert -4 10.24.1.10 का उपयोग करें। यदि वही दो हॉप बार-बार दिखें, तो ऐसा रूट खोजें जो टनल की ओर जाने वाला ट्रैफ़िक वापस टनल में या उसे लौटाने वाले स्थानीय राउटर में भेजता है।
पैकेज उसी गेटवे पर फिर से बनाएँ जो उसका मालिक है
Microsoft दस्तावेज़ करता है कि प्रासंगिक टोपोलॉजी परिवर्तनों के बाद Windows क्लाइंट पैकेज फिर से डाउनलोड और इंस्टॉल करने होते हैं। इस प्रोफ़ाइल की सेवा करने वाले Azure गेटवे से वर्तमान पैकेज लें, फिर उस क्लाइंट के लिए समर्थित प्रक्रिया से लागू करें। किसी असंबंधित VPN एप्लिकेशन की निष्पादन योग्य फ़ाइल बदलना गेटवे-विशिष्ट सेटिंग फिर से बनाने के समान कार्य नहीं है। पैकेज फिर से डाउनलोड करना सस्ता है; स्थानीय रूट का अनुमान लगाना नहीं।
फिर से कनेक्ट करें और मूल गंतव्य का रूट दोबारा पढ़ें। परिवर्तन रिकॉर्ड के साथ पहले और बाद की पंक्तियाँ रखें ताकि परिणाम मैंने क्लाइंट फिर से इंस्टॉल किया से अधिक सटीक हो।
Azure P2S रूटिंग परिदृश्य सीधे पीयर किए गए VNet को अन्य टनल से पहुँचने वाले नेटवर्क से अलग करते हैं, और नया पैकेज पीयरिंग को पारगमनशील नहीं बना सकता। कुछ Windows site-to-site या BGP परिदृश्यों में हाथ से कॉन्फ़िगर किए गए रिमोट रूट भी चाहिए, इसलिए पैकेज रीफ़्रेश सार्वभौमिक रूट वितरण तंत्र नहीं है।
अस्थायी रूट को अस्थायी रखें
मैनुअल रूट गायब क्लाइंट रूट को अलग कर सकता है, लेकिन इसे वास्तविक डिज़ाइन से बनाएँ: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, पर्सिस्टेंट फ़्लैग के बिना, ताकि रीबूट पर वह गायब हो जाए। इंटरफ़ेस इंडेक्स और अगला हॉप जुड़े VPN एडाप्टर से चुनें, अनुमान से नहीं।
प्रयोगात्मक रूट को स्थायी प्रतिद्वंद्वी मालिक के रूप में न छोड़ें। भविष्य के प्रोफ़ाइल अपडेट उसी प्रीफ़िक्स को भिन्न मीट्रिक के साथ जोड़ सकते हैं, और तब मैनुअल प्रविष्टि चुपचाप तय कर देती है कौन-सा पथ जीतेगा। हटाने का चरण परिवर्तन में दर्ज करें।
सही रूट सक्रिय होने पर ping नहीं, लक्ष्य एप्लिकेशन का परीक्षण करें। यदि पैकेट Azure तक पहुँचते हैं पर सेवा अभी भी विफल रहती है, तो नेटवर्क सुरक्षा समूह और वापसी पथ जाँचें, क्योंकि वे इससे अलग हैं कि लैपटॉप ने प्रीफ़िक्स सीखा या नहीं।