रुंद 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 रिकामे करणे त्या पत्त्याला अजूनही टनेलमध्ये पाठवणारा प्रीफिक्स दुरुस्त करणार नाही. आधी निवड तपासा, नंतर मार्ग.