फराकिलो 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 खाली गर्नुले त्यो ठेगानालाई अझै सुरुङमा पठाउने प्रिफिक्स सुधार्दैन। पहिले छनोट परीक्षण गर्नुहोस्, त्यसपछि मार्ग।