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 रुट वितरणको बग होइन
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 सम्म पुगे पनि सेवा अझै असफल भइरहेको छ भने, नेटवर्क सुरक्षा समूह र फर्कने मार्ग जाँच्नुहोस्, किनकि ती ल्यापटपले प्रिफिक्स सिक्यो कि सिकेन भन्नेबाट अलग छन्।