क्लाइंट बताता है कि जुड़ा है, ट्रे आइकन सामान्य दिखता है, और कुछ भी लोड नहीं होता। यह ठीक उसी समय शुरू हुआ जब आप Wi-Fi से केबल पर गए, या ठीक उसी समय जब डिस्ट्रिब्यूशन अपग्रेड पूरा हुआ। टूटा प्रोफ़ाइल नहीं है, बल्कि वह स्थिति है जो पिछले बेस कनेक्शन के लिए बनी थी। कर्नेल के पास अब भी एक डिफ़ॉल्ट रूट है जो ऐसे टनल डिवाइस की ओर इशारा करता है जिसका कोई मालिक नहीं है, या रिज़ॉल्वर अब भी ऐसी लिंक पर सर्वर सूचीबद्ध करता है जो जा चुकी है। दोनों विफलताएँ मृत नेटवर्क जैसी लगती हैं और दोनों को वहीं ठीक किया जा सकता है।

पुराने टुकड़े आपके ध्यान देने से पहले ही गलत थे। केबल निकालने ने उन्हें केवल दिखाया।

कर्नेल से पूछें कि पैकेट कहाँ जाएगा

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

लुकअप दो बार चलाएँ, एक बार सार्वजनिक पते के लिए और एक बार आंतरिक पते के लिए, क्योंकि स्प्लिट-टनल नीति एक को ईमानदारी से रूट कर सकती है और दूसरे को गिरा सकती है।

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

रिज़ॉल्वर भी मृत लिंक रखता है

systemd-resolved वाले होस्ट पर DNS सर्वर लिंक से जुड़े होते हैं, किसी एक वैश्विक सूची से नहीं। गिरी हुई VPN लिंक कुछ समय तक अपने सर्वरों के साथ पंजीकृत रह सकती है, और तब हर लुकअप ऐसे पते पर प्रतीक्षा करता है जो कभी उत्तर नहीं देगा। वह देरी मृत नेटवर्क जैसी लगती है और लोगों को रूट देखने भेजती है जबकि रूट ठीक है।

resolvectl status
resolvectl query intranet.example.com

प्रत्येक लिंक के ब्लॉक पढ़ें और पहचानें कि प्रश्न में दिया डोमेन किस लिंक का है। जो टनल ऊपर है पर आंतरिक डोमेन का मालिक नहीं है, वह आंतरिक नाम सार्वजनिक रिज़ॉल्वर पर भेजता है, और लक्षण रूटिंग खराबी से अलग नहीं पहचाना जा सकता।

रजिस्ट्रेशन ठीक करें, न कि /etc/resolv.conf। मौजूदा Ubuntu और Fedora इंस्टॉल में वह पथ रिज़ॉल्वर की रनटाइम स्थिति का सिमलिंक है, इसलिए संपादन या तो नजरअंदाज़ होता है या अगली नेटवर्क घटना में फिर से लिख दिया जाता है।

VPN कभी अपने आप शुरू नहीं होता

NetworkManager बेस कनेक्शन के ऊपर VPN उठाता है, और यह सीखता है कि किसके पीछे जाना है, connection.secondaries उस बेस पर। कनेक्शन सेटिंग्स संदर्भ स्पष्ट रूप से कहता है कि VPN प्रोफ़ाइल के लिए ऑटोकनेक्ट लागू नहीं है। इस श्रेणी की विफलता के पीछे यही पूरी क्रियाविधि है: बेस बदलें, और VPN को फिर से जोड़ना या हाथ से फिर सक्रिय करना पड़ता है।

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

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

अपग्रेड बिना संदेश के सेटिंग्स गिरा सकता है

डिस्ट्रिब्यूशन अपग्रेड क्लाइंट और अक्सर उसके NetworkManager प्लगइन को बदल देता है, जबकि सहेजी गई प्रोफ़ाइल वही प्रॉपर्टी नाम रखती है जिनके साथ वह लिखी गई थी। नया प्लगइन जो अब नहीं पहचानता वह चुपचाप छोड़ दिया जाता है। प्रोफ़ाइल अब भी सक्रिय होती है और डिवाइस अब भी दिखता है, पर जो रूट पहले उसके साथ आता था वह अब नहीं आता।

हाथ से लिखे हुक भी खिसकते हैं। जो स्क्रिप्ट पुराने क्रम के अनुमानित क्षण पर रूट इंस्टॉल करती थी, वह अब इंटरफ़ेस बनने से पहले चल सकती है, या क्लाइंट का समय पूरा हो जाने के बाद।

जीवित प्रोफ़ाइल की तुलना उस प्लगइन से करें जो वास्तव में आपके पास है, न कि उस व्यवहार से जो आपको याद है। अगर कोई कुंजी दस्तावेज़ीकरण से गायब है, तो पुरानी प्रॉपर्टी बहाल करने के बजाय काम को डिस्पैचर स्क्रिप्ट या समर्थित विकल्प में ले जाएँ।

तीन स्थितियाँ, तीन अलग मरम्मतें

कुछ भी छूने से पहले तय करें कि आप किस स्थिति में हैं, क्योंकि रीबूट सबूत नष्ट कर देता है और अगले नेटवर्क बदलाव पर खराबी लौट आती है।

What the lookup showsWhat it meansRepair
A default route via a device that exists but is unusedLeftover route from an earlier activationRemove the stale entry, or bounce the profile that installed it
A tunnel device with no client processThe client skipped its cleanupFix the disconnect path, then clear the leftover device state
No tunnel device and no active profileMissing base connection or broken pairingBring up the base, then pair the VPN with it again

सार्वजनिक पते के लिए एक लुकअप, आंतरिक पते के लिए एक लुकअप और एक नाम क्वेरी के साथ समाप्त करें। अगर पते काम करते हैं और नाम नहीं, तो बची हुई खराबी रिज़ॉल्वर में डोमेन स्कोप है, और रूट तालिका कभी समस्या नहीं थी।

संबंधित लेख