एक चौड़ा VPN रूट कुछ सार्वजनिक साइटों को क्यों तोड़ता है

अधिकांश पेज लोड होते हैं, दो या तीन समय-सीमा पार कर जाते हैं, और ब्राउज़र कनेक्शन को दोष देता है। जो साइटें विफल होती हैं उनमें कुछ ऐसा साझा है जो काम करने वाली साइटों में नहीं है: उनके हल किए गए पते उस प्रीफ़िक्स के अंदर पड़ते हैं जिसे VPN ने इंस्टॉल किया है। सार्वजनिक रेंज को कवर करने के लिए पर्याप्त चौड़ा रूट ऐसा ट्रैफ़िक पकड़ेगा जिसे टनल कभी नहीं ले जाना था, और लक्षण रूटिंग निर्णय के बजाय वेबसाइट की समस्या जैसा दिखता है।

विफल हो रहे नाम को हल करें, फिर ब्राउज़र के बजाय रूटिंग तालिका में देखें।

पते की तुलना करें, साइट के नाम की नहीं

वह पता खोजें जिसे क्लाइंट ने वास्तव में आज़माया, फिर जाँचें कि कौन-सा रूट उससे मेल खाता है। 45.61.20.10 के अंदर गंतव्य 45.0.0.0/8 के अंतर्गत आता है यदि वह प्रीफ़िक्स मौजूद है, भले ही साइट का खुद टनल से कोई संबंध न हो। विफल पते की इंस्टॉल किए गए प्रीफ़िक्स से तुलना करना घटाव की समस्या है, अनुमान नहीं।

Windows दोनों आधों का सीधा उत्तर दे सकता है, और एक लुकअप दिखाता है कि कौन-सा इंटरफ़ेस और अगला हॉप चयन जीते। यदि साइट कई पते लौटाती है तो नाम दो बार हल करें। हर एक को उस रूट के साथ लिखें जो उससे मेल खाया। अलग-अलग पते अलग-अलग उत्तर दे सकते हैं, और उनमें से केवल एक ही विफल मामला हो सकता है।

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

सबसे विशिष्ट मेल खाता प्रीफ़िक्स पढ़ें, पहली ऐसी पंक्ति नहीं जो परिचित लगे। तालिका में मौजूद रूट यह सिद्ध नहीं करता कि उसने लुकअप जीता; सबसे लंबा मेल ऐसा करता है। दो प्रीफ़िक्स एक पते से मेल खा सकते हैं, और उनमें से केवल एक ही पैकेट प्राप्त करता है। हारने वाला तालिका में रहता है और सूची में उतना ही वास्तविक दिखता है।

प्रीफ़िक्स, उसका इंटरफ़ेस और हल किया गया पता लिखें। ये तीन मान ही पूरा निदान हैं।

पता लगाएँ कि रूट किसने इंस्टॉल किया

रूट चार जगहों से आते हैं: मूल VPN प्रोफ़ाइल, प्रबंधन नीति, कनेक्शन स्क्रिप्ट या पूरी तरह से दूसरा क्लाइंट। जीवित प्रविष्टि को हटाना उसकी प्रासंगिकता की पुष्टि कर सकता है, लेकिन अगला कनेक्शन इसे सहेजे गए कॉन्फ़िगरेशन से फिर बनाता है, इसलिए स्रोत ही बदलना होगा।

पहले प्रोफ़ाइल की रूट सूची जाँचें, फिर प्रबंधन नीति, फिर कनेक्ट होने पर चलने वाली कोई भी स्क्रिप्ट। यह क्रम इस बात से मेल खाता है कि कौन कितनी बार ज़िम्मेदार निकलता है। यह बदलाव को तीन के बजाय एक परत में भी रखता है।

मूल वर्ग-आधारित व्यवहार को ध्यान से पढ़ें

मूल Windows प्रोफ़ाइल में एक प्रलेखित सेटिंग है, NativeProfile/DisableClassBasedDefaultRoute, जो इंटरफ़ेस पते से अनुमानित स्वचालित रूट को नियंत्रित करती है। 45 से शुरू होने वाला प्रोफ़ाइल पता उस व्यवहार के तहत 45.0.0.0/8 प्रविष्टि बना सकता है, और इस तरह एक सार्वजनिक पता पूरी वर्ग-A श्रेणी पकड़ लेता है।

गुण का नाम गलत पठन का निमंत्रण देता है: इसे true पर सेट करना अनुमान बंद करता है, और false इसे चालू करता है। यह डिफ़ॉल्ट रूट जैसी वही वस्तु भी नहीं है, और अपने प्रीफ़िक्स इंस्टॉल करने वाले तृतीय-पक्ष क्लाइंट को यह नियंत्रित नहीं करता।

यदि अनुमान सिद्ध कारण है, तो प्रोफ़ाइल को उसके प्रबंधन स्वामी के माध्यम से ठीक करें और इच्छित निजी प्रीफ़िक्स स्पष्ट रूप से दें। यदि किसी स्क्रिप्ट ने प्रविष्टि जोड़ी है, तो स्क्रिप्ट ठीक करें। एक अस्पष्ट चौड़े रूट को दूसरे से बदलना लक्षण बदलता है, प्रश्न का उत्तर नहीं देता।

स्रोत ठीक करें, फिर दोनों पथ फिर से जाँचें

बदलाव के बाद फिर कनेक्ट करें और विफल सार्वजनिक साइट तथा उस संसाधन के लिए लुकअप दोहराएँ जिसे टनल का उपयोग करना चाहिए। पहला अब भौतिक इंटरफ़ेस पर हल होना चाहिए, और दूसरा अभी भी VPN चुनना चाहिए। पहली सफलता पर न रुकें; जो सुधार निजी पहुँच भी तोड़ता है उसने एक खराबी को दूसरी से बदल दिया है।

उसी समय सर्वर की पता योजना की समीक्षा करें। सार्वजनिक स्थान से ओवरलैप होता पूल इस प्रकार की समस्या बार-बार पैदा करता है। ऑपरेटर द्वारा जानबूझकर चुनी गई श्रेणी दूसरी बातचीत की हकदार है, स्वचालित पुन:क्रमांकन की नहीं।

MTU बढ़ाना या DNS साफ़ करना उस प्रीफ़िक्स को ठीक नहीं करेगा जो अभी भी उस पते को टनल में भेजता है। पहले चयन का परीक्षण करें, फिर पथ का।