तुम्ही 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 बाजू वाचा, स्नॅपशॉट ठेवा, आणि त्यानंतरच सामाईक हार्डवेअर स्तर तपासण्यासारखा आहे का ते ठरवा.

संबंधित लेख