Windows में VPN इंस्टॉल, Linux बूट में नेटवर्क नहीं: क्या जाँचें

आप 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 ने कोई विशेष एडाप्टर गड़बड़ी पैदा की।

अंत में किस OS ने एडाप्टर इस्तेमाल किया, ट्रांज़िशन का प्रकार, Linux में लिंक की स्थिति और पहला विफल ऑपरेशन दर्ज करें। कौन सा स्टैक टूटा यह जाने बिना दोनों इंस्टॉलेशन से VPN सॉफ़्टवेयर हटाने की तुलना में ठंडे स्टार्ट और गर्म ट्रांज़िशन का दोहराया जा सकने वाला अंतर कहीं अधिक मूल्यवान है।

क्या न बदलें

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

ip टूल का संदर्भ ऊपर इस्तेमाल की गई लिंक, पता और रूट वस्तुओं का दस्तावेज़ीकरण करता है। पहले Linux पक्ष पढ़ें, स्नैपशॉट रखें, और तभी तय करें कि साझा हार्डवेयर परत जाँचने लायक है या नहीं।