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 बिग्रिएको रिपोर्ट गर्ने टिकट होइन।