तपाईं Windows मा VPN स्थापना गर्नुहुन्छ, Linux मा रिबुट गर्नुहुन्छ, र तारको जडान मृत छ। स्पष्ट कथा आफैं लेखिन्छ: VPN ले केही पछाडि छोड्यो। कथा गलत छ, किनकि दुवै बुटले छुट्टाछुट्टै कर्नेल, छुट्टाछुट्टै ड्राइभर, छुट्टाछुट्टै राउटिङ तालिका र छुट्टाछुट्टै रिजोल्भर चलाउँछन्। Windows को नेटवर्क फिल्टर Linux भित्र चल्दैन, त्यसैले दोष Linux स्ट्याकमा छ वा दुवै बुटले साँच्चै साझा गर्ने कुनै कुरामा, जस्तै हार्डवेयर, फर्मवेयर वा राउटर।

लक्षण र गलत निष्कर्ष

अवलोकनको उपयोगी भाग समय हो: परिवर्तन पछि दोष देखा पर्‍यो। निरुपयोगी भाग Windows VPN तर्फको कारणगत फड्को हो, जुन अर्को अपरेटिङ सिस्टममा चल्न सक्दैन। दुवैलाई छुट्याउनु नै पूरा काम हो। केबल छुनु अघि समयरेखा लेख्नुहोस्।

दुवै बुटले साँच्चै साझा गर्ने कुरा भौतिक एडाप्टर, केबल, स्विच पोर्ट र माथिको सबै हो। यी वास्तविक साझा चर हुन्, र Linux स्ट्याक जाँचिसकेपछि यी जाँच्न योग्य छन्।

चार कमाण्डमा Linux स्ट्याकको स्न्यापसट लिनुहोस्

केही बदल्नु अघि पढ्ने-मात्र मोडमा सुरु गरी अवस्था कैद गर्नुहोस्: इन्टरफेसको उपस्थितिका लागि ip -br link, ठेगानाका लागि ip -br address, IPv4 मार्गका लागि ip route र IPv6 महत्त्वपूर्ण हुने ठाउँमा ip -6 route. ip उपकरणको सन्दर्भले यी वस्तुहरू छुट्याउँछ, र सूचीमा इन्टरफेस देखिनु भनेको यसको काम गर्ने ठेगाना वा प्रयोगयोग्य मार्ग छ भन्ने प्रमाण होइन।

आउटपुट फाइलमा सुरक्षित गर्नुहोस्, पछि काम गर्ने बुटसँग तुलना गर्न। तपाईंले पुनः उत्पादन गर्न नसक्ने स्न्यापसट केवल अवस्थाको सम्झना हो।

यो लिङ्क हो, ठेगाना, मार्ग वा नाम?

चार फरक दोष ब्राउजरबाट उस्तै देखिन्छन्। यन्त्र पूर्ण रूपमा अनुपस्थित हुन सक्छ, वाहक बिना उपस्थित हुन सक्छ, जोडिएको तर अपेक्षित ठेगाना बिना, वा ठेगाना भए पनि गन्तव्यसम्म मार्ग बिना। कच्चा ठेगाना चलिरहँदा नाम-विश्लेषण असफल हुनु पाँचौं केस हो, र त्यो ड्राइभरको होइन, रिजोल्भरको हो।

हरेक केसले फरक कामतर्फ संकेत गर्छ: हराएको यन्त्रका लागि ड्राइभर वा फर्मवेयर, वाहक नहुँदा केबलिङ वा स्विच, ठेगाना नहुँदा DHCP वा स्थिर कन्फिगरेसन, र मार्ग नहुँदा राउटिङ वा नीति। रिजोल्भरको समस्याले systemd-resolved, NetworkManager वा स्थानीय DNS कन्फिगरेसनतर्फ संकेत गर्छ।

Linux स्थापनाको आफ्नै VPN वा स्थायी फायरवाल कन्फिगरेसन छ कि जाँच्नुहोस्। स्थानीय टनेल वा nftables नियमको सेट Linux पक्षको कारण हो, र नचलिरहेको Windows प्रोग्रामभन्दा यसले दोष धेरै सम्भावनाका साथ व्याख्या गर्छ।

त्यसपछि बुट संक्रमण तुलना गर्नुहोस्

Windows Fast Startup पूर्ण बुटको सट्टा कर्नेल सत्रको अवस्था राख्ने हाइब्रिड सटडाउन हो। Microsoft को पावर-स्टेट दस्तावेजले यसलाई रिस्टार्ट र पूर्ण सटडाउनबाट छुट्याउँछ, त्यसैले एउटै हार्डवेयर दुवै संक्रमणमा फरक व्यवहार गर्न सक्छ।

दोष एउटा अपरेटिङ सिस्टमबाट अर्कोमा जानमा निर्भर छ भने, काम सुरक्षित गरेपछि दस्तावेजीकृत रिस्टार्ट वा पूर्ण सटडाउनको सामान्य मार्गसँग तुलना गर्नुहोस्। संक्रमणलाई पछ्याउने नतिजाले ड्राइभर, यन्त्र वा फर्मवेयरको अवस्था जाँच्नु न्यायोचित ठहराउँछ, र यसले आफैंमा Fast Startup ले निश्चित एडाप्टर दोष निम्त्यायो भनी प्रमाणित गर्दैन।

अन्तमा कुन अपरेटिङ सिस्टमले एडाप्टर प्रयोग गर्‍यो, संक्रमणको प्रकार, Linux मा लिङ्कको अवस्था र असफल भएको पहिलो कार्य लेख्नुहोस्। कुन स्ट्याक बिग्रियो भन्ने नजानी दुवै स्थापनाबाट VPN सफ्टवेयर हटाउनुभन्दा चिसो स्टार्ट र तातो संक्रमणबीचको दोहोर्‍याउन सकिने भिन्नता धेरै मूल्यवान छ।

के बदल्नु हुँदैन

पहिलो कदमका रूपमा दुवै नेटवर्क स्ट्याक रिसेट नगर्नुहोस्। यसले तुलना नष्ट गर्छ र वास्तविक कारण कहिल्यै पहिचान नभएकाले प्रायः केही पनि सुधार्दैन। Linux सुधार्न Windows VPN पुनः स्थापना नगर्नुहोस्, र बुट संक्रमण दोषसँग मिल्यो भनेर फर्मवेयर सेटिङ अनियमित रूपमा नबदल्नुहोस्।

ip उपकरणको सन्दर्भ ले माथि प्रयोग गरिएका लिङ्क, ठेगाना र मार्ग वस्तुहरूको दस्तावेजीकरण गर्छ। पहिले Linux पक्ष पढ्नुहोस्, स्न्यापसट राख्नुहोस्, र त्यसपछि मात्र साझा हार्डवेयर तह जाँच्न योग्य छ कि भन्ने निर्णय गर्नुहोस्।

सम्बन्धित लेखहरू