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 प्लगइन बदल्छ, तर सुरक्षित प्रोफाइलले लेखिँदाका गुण नामहरू राख्छ। नयाँ प्लगइनले अब नचिन्ने सबै चुपचाप छोडिन्छ। प्रोफाइल अझै सक्रिय हुन्छ र यन्त्र अझै देखिन्छ, तर पहिले सँगै आउने मार्ग अब आउँदैन।

हातले लेखिएका हुकहरू पनि सर्छन्। पुरानो क्रमको अनुमान गर्न सकिने क्षणमा मार्ग स्थापना गर्ने स्क्रिप्ट अब इन्टरफेस बन्नुअघि वा क्लाइन्टको समय सकिएपछि चल्न सक्छ।

जीवित प्रोफाइललाई तपाईंसँग साँच्चै भएको प्लगइनसँग तुलना गर्नुहोस्, सम्झनामा रहेको व्यवहारसँग होइन। कुनै कुञ्जी कागजातबाट हरायो भने पुरानो गुण पुनर्स्थापना गर्नुको सट्टा काम डिस्प्याचर स्क्रिप्ट वा समर्थित विकल्पमा सार्नुहोस्।

तीन अवस्था, तीन फरक सुधार

केही पनि छुनुअघि तपाईं कुन अवस्थामा हुनुहुन्छ निर्णय गर्नुहोस्, किनकि रिबुटले प्रमाण नष्ट गर्छ र अर्को नेटवर्क परिवर्तनमा खराबी फर्किन्छ।

सार्वजनिक ठेगानाका लागि एउटा खोजी, आन्तरिक ठेगानाका लागि एउटा र एउटा नाम क्वेरीसँग अन्त्य गर्नुहोस्। ठेगाना चले तर नाम नचले, बाँकी खराबी रिजोल्भरमा डोमेन क्षेत्र हो, र मार्ग तालिका कहिल्यै समस्या थिएन।