VPN जोडले आहे असे सांगते, पण डीफॉल्ट मार्ग मृत आहे

क्लायंट सांगतो की जोडले आहे, ट्रे चिन्ह सामान्य दिसते, आणि काहीही लोड होत नाही। तुम्ही 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 प्लगइन बदलते, तर जतन केलेले प्रोफाइल ते लिहिले गेले त्या गुणधर्मांची नावे ठेवते। नवीन प्लगइनला आता न ओळखणारे सर्व गुपचूप वगळले जाते। प्रोफाइल अजूनही सक्रिय होते आणि उपकरण अजूनही दिसते, पण पूर्वी त्याच्यासोबत येणारा मार्ग आता येत नाही।

हाताने लिहिलेले हुकही सरकतात। जुन्या क्रमातील अंदाजे क्षणी मार्ग बसवणारी स्क्रिप्ट आता इंटरफेस तयार होण्यापूर्वी चालू शकते, किंवा क्लायंटची मुदत संपल्यानंतर।

जिवंत प्रोफाइलची तुमच्याकडे खरोखर असलेल्या प्लगइनशी तुलना करा, आठवणीतील वर्तनाशी नाही। एखादी किल्ली दस्तऐवजातून गेली असेल, तर जुना गुणधर्म पुनर्संचयित करण्याऐवजी काम डिस्पॅचर स्क्रिप्ट किंवा समर्थित पर्यायाकडे हलवा।

तीन स्थिती, तीन वेगवेगळ्या दुरुस्त्या

काहीही स्पर्श करण्यापूर्वी तुम्ही कोणत्या स्थितीत आहात ते ठरवा, कारण रीबूट पुरावे नष्ट करतो आणि पुढील नेटवर्क बदलात बिघाड परत येतो।

सार्वजनिक पत्त्यासाठी एक शोध, अंतर्गत पत्त्यासाठी एक शोध आणि एक नाव क्वेरीने संपवा। पत्ते चालतात पण नाव चालत नाही, तर उर्वरित बिघाड रिझोल्व्हरमधील डोमेन व्याप्ती आहे, आणि मार्ग तक्ता कधीच समस्या नव्हता।