दोन लॅपटॉप एकाच 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 ही रूट वितरणाची बाग नाही

TTL expired in transit परत देणारे ping सांगते की पॅकेटने आपला हॉप कोटा संपवला, ज्याचा अर्थ सामान्यतः फॉरवर्डिंग लूप असतो, तुटलेला VPN ड्रायव्हर नाही. Windows ping 255 पर्यंत TTL स्वीकारते, आणि मूल्य वाढवल्याने लूप दुरुस्त होत नाही; तीच त्रुटी फक्त लांबवते. संदेशाला मार्गाचे लक्षण माना, रूट वितरणाचा पुरावा नाही.

मार्ग कुठे पुनरावृत्ती होतो हे पाहण्यासाठी tracert -4 10.24.1.10 वापरा. तेच दोन हॉप वारंवार दिसल्यास, बोगद्याकडील रहदारी पुन्हा बोगद्यात किंवा ती परत पाठवणाऱ्या स्थानिक राउटरकडे पाठवणारा रूट शोधा.

पॅकेज त्याच्या मालकीच्या गेटवेवर पुन्हा तयार करा

संबंधित टोपोलॉजी बदलांनंतर Windows क्लायंट पॅकेज पुन्हा डाउनलोड करून स्थापित करावे लागतात असे Microsoft नोंदवते. हे प्रोफाइल सेवा देणाऱ्या 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 पर्यंत पोहोचतात पण सेवा अजूनही अयशस्वी होत असल्यास, नेटवर्क सुरक्षा गट आणि परतीचा मार्ग तपासा, कारण ते लॅपटॉपने प्रीफिक्स शिकले की नाही यापासून वेगळे आहेत.

संबंधित लेख