VPN जुड़ा है पर एक सेवा विफल: चरण अलग करें

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

नाम से शुरू करें, टनल से नहीं

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

resolvectl query host.internal
getent hosts host.internal

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

कर्नेल से पूछें कि उसने कौन-सा पथ चुना

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

ip route get 10.20.30.40
ip -brief address show

dev, via और src फ़ील्ड इसी क्रम में पढ़ें, क्योंकि हर एक अलग संदेह हटाता है। यह चरण क्लाइंट द्वारा स्थापित स्थिति का भी स्वामी है, क्योंकि फ़ायरवॉल नियम और रूट असामान्य निकास के बाद भी बने रह सकते हैं। इसीलिए «टनल के बिना इंटरनेट नहीं» और «क्लाइंट चले बिना इंटरनेट नहीं» दो नहीं, एक ही दोष-परिवार हैं।

पैकेट का आकार जाँचें

बड़ा स्थानांतरण अटकते समय लौटता छोटा उत्तर पहले पथ के MTU की ओर इशारा करता है। टनल के भीतर से भेजी गई, do-not-fragment बिट सेट किए हुए एक प्रोब इस चरण को बाकियों से अलग करती है। प्रोब विफल होने तक पेलोड बढ़ाएँ और आपके पास वह संख्या होगी जो मायने रखती है।

ping -M do -s 1400 10.20.30.40

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

यह संख्या क्लाइंट की नहीं, पथ की विशेषता है, इसलिए ऑफ़िस कनेक्शन पर काम करने वाला मान मोबाइल लिंक पर विफल हो सकता है। प्रोब कमांड को टिकट के साथ रखें, क्योंकि अगले व्यक्ति को वही माप चाहिए। अगर छोटा पेलोड पास होता है, तो समाधान clamp या कम टनल MTU है, नया साइफ़र नहीं।

दूर के सिरे को जाँचें

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

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

टनल से पहुँचने योग्य कोई भी चीज़ ऐसी सेवा नहीं हो सकती जो केवल 127.0.0.1 पर सुनती हो, क्योंकि श्रोता पैकेट कभी नहीं देखता। जब दूर के होस्ट का फ़ायरवॉल ऑफ़िस सबनेट को अनुमति देता है और टनल पूल को अस्वीकार करता है, तो परिणाम क्लाइंट की खराबी जैसा दिखता है और होता नहीं। Remote Desktop या फ़ाइल साझाकरण टूटना जबकि वेब ट्रैफ़िक बचा रहे, आमतौर पर यहीं आता है, चाहे उपयोगकर्ता इसे कैसे भी कहे।

शिकायत को एक चरण से मिलाएँ

अधिकांश रिपोर्ट पाँच आकृतियों में से एक में आती हैं, और हर आकृति एक चरण का नाम बताती है। केवल टनल से काम करने वाली एक साइट नाम का उत्तर या स्रोत पते से बँधी नीति है। टनल के बिना अपडेट विफल होना जबकि ब्राउज़िंग काम करे, उस क्लाइंट के लिए नाम या रूट की समस्या है।

प्रदाता का क्लाइंट शुरू होते ही सब कुछ रुक जाना स्थापित स्थिति है, यानी रूट और फ़ायरवॉल का प्रश्न। बाकी ठीक होते हुए एक सेवा अप्राप्य होना दूर का सिरा है। स्थानांतरण कुछ सेकंड बाद अटकना पैकेट का आकार है। कमांड चलाने से पहले आकृति मिलाएँ, क्योंकि यह तय करती है कि पहले कौन-से सबूत इकट्ठे करने हैं।

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