ip link प्रयोग गरेर Linux VPN इन्टरफेस तह-तहमा जाँच्नुहोस्

क्लाइन्ट आइकनले जोडिएको भन्छ, इन्टरफेस अवस्थित छ, तर एप्लिकेसनले अझै केही भेट्दैन। यो संयोजन सामान्य हो, किनकि भर्चुअल इन्टरफेस रहिरहन सक्छ जबकि यसको रिमोट पियर, ठेगाना वा रुट हराइरहेका हुन्छन्। ip link सही पहिलो उपकरण हो, र यसलाई बढी अर्थ लगाउनु पनि सबैभन्दा सजिलो छ। फ्ल्याग र काउन्टरले एउटा तह वर्णन गर्छन्, र तिनका माथिका तहहरू स्वतन्त्र रूपमा असफल हुन्छन्। मानिसहरूले टनेल चालु छ भनी प्रमाणित गर्न यही उपकरण उद्धृत गर्छन्, जुन ठ्याक्कै त्यो दाबी हो जुन यसले एक्लै समर्थन गर्न सक्दैन।

आइकन पढ्नुअघि इन्टरफेस पढ्नुहोस्

सुरु गर्नुहोस् ip -details link show dev tun0 बाट, जुन ip-link म्यानुअल मा वर्णन गरिएको छ, र परम्परागत नामको सट्टा तपाईंको क्लाइन्टले वास्तवमै राख्ने इन्टरफेस राख्नुहोस्। फ्ल्याग, प्रकार, MTU र इन्टरफेस पहिचान उपयोगी अवलोकन हुन्। भर्चुअल इन्टरफेसको अवस्था शब्दावलीले भौतिक केबलको क्यारियर सङ्केत जस्तै व्यवहार गर्नुपर्दैन, त्यसैले UP लाई इन्टरफेसको बारेमा भनिएको कुरा मान्नुहोस्, टनेलको बारेमा होइन।

यो भिन्नताले सबैभन्दा अन्योलपूर्ण अवस्था व्याख्या गर्छ: रिमोट पक्ष पुनः जोडिँदै वा पुग्न नसकिने हुँदा पनि रहिरहने इन्टरफेस।

स्थायित्व सेटिङहरूले लिंकलाई ठ्याक्कै यसैका लागि राख्न सक्छन् ताकि पुनः जडानले यसलाई पुनः नबनाओस्, जसको अर्थ उपस्थिति स्वास्थ्य होइन।

काउन्टर र तिनलाई प्रयोग गर्नुपर्ने अनुरोध थप्नुहोस्

समर्थित तथ्याङ्क दृश्य प्रयोग गर्नुहोस्, ip -s link show dev tun0, र दुवै दिशाका प्याकेट र बाइट गणना नोट गर्नुहोस्। त्यसपछि इन्टरफेसबाट जानुपर्ने हानिरहित अनुरोध उत्पन्न गर्नुहोस् र सम्बन्धित दिशा तुलना गर्नुहोस्। अर्को एप्लिकेसनको सिधा रुट लिने अनुरोधले ती काउन्टर सार्दैन, र त्यही नै यो अभ्यासको उद्देश्य हो।

यदि पठाउने काउन्टर सर्छ र प्राप्त गर्ने सर्दैन भने, प्याकेट गयो र केही फर्किएन। यो कहिल्यै केही बोक्ने नगरेको इन्टरफेसभन्दा फरक समस्या हो। यदि दुवै काउन्टर सर्छन् र एप्लिकेसन अझै असफल हुन्छ भने, दोष इन्टरफेसको माथि छ, जुन अन्त्य होइन, प्रगति हो।

एउटै स्न्यापसनमा भर नपर्दै, पढाइ दुई पटक लिनुहोस्, एक पटक अघि र एक पटक पछि।

ठेगाना र रुट छुट्टाछुट्टै कदम हुन्

लिंक प्रिफिक्स, रिजोल्भर कन्फिगरेसन वा एप्लिकेसनलाई चाहिने रुट बिना पनि अवस्थित हुन सक्छ। ठेगाना ip address show dev tun0 ले जाँच्नुहोस्, र त्यसपछि गन्तव्यले कुन रुट छान्छ भनी ip route get प्रयोग गरी वास्तविक लक्ष्यका लागि जाँच्नुहोस्। ती तीन अवलोकनले तीन फरक प्रश्नको उत्तर दिन्छन्, र अन्तिमले मात्र फर्वार्डिङको बारेमा बताउँछ।

IPsec का लागि सुरक्षा नीति र एसोसिएसन अवस्था पनि महत्त्वपूर्ण हुन सक्छन्, र सबै IPsec डिजाइन साधारण tun इन्टरफेसका रूपमा देखिँदैनन्। कहिल्यै नहुने tun यन्त्र खोज्नु गलत निष्कर्षमा पुग्ने छिटो बाटो हो।

तपाईंले राख्ने कुनै पनि आउटपुटसँग ठ्याक्कै नाम, नेमस्पेस र समय लेख्नुहोस्, किनकि अर्को कन्टेनर वा पुनःस्थापित सत्रमा उही देखिने नामले पूर्ण रूपमा अर्को सन्दर्भ जनाउँछ।

नपहिचान गरेको कुरा नमेट्नुहोस्

अपरिचित इन्टरफेस स्वतः पुरानो हुँदैन। केही हटाउनुअघि यसको मालिक पहिचान गर्नुहोस्, र हटाउने वास्तवमै मनसाय भए क्लाइन्टको वर्णित टियरडाउन वा व्यवस्थित कन्फिगरेसन प्रयोग गर्नुहोस्। के हुन्छ देख्नका लागि चालु टनेल मेटाउनु कसैले नसोधेको प्रश्नको उत्तर दिने परीक्षण हो।

यदि इन्टरफेस कन्टेनर रनटाइम वा तपाईंले नबनाएको नेटवर्क नेमस्पेसको हो भने, मालिक एक आदेश परै छ र पहिले खोज्न लायक छ।

त्यो सतर्कता ip link set down मा पनि लागू हुन्छ, जुन उल्टाउन सकिने देखिन्छ र प्रायः हुँदैन।

जाँचले तपाईंलाई के दिनुपर्छ

राम्रो जाँच चार तथ्यमा टुंगिन्छ: इन्टरफेसको नाम र नेमस्पेस, यसका फ्ल्याग र MTU, वास्तविक अनुरोधबाट आएको काउन्टर डेल्टा, र एप्लिकेसनलाई वास्तवमै चाहिने रुट र ठेगाना। ती लेखिएपछि अर्को कदम स्पष्ट हुन्छ र कुनै निश्चित तहको हुन्छ। ती बिना, हरेक पछिको परिवर्तन रोलब्याक योजनासहितको अनुमान हो।

ती चार तथ्यलाई काम गर्ने सत्रका उही चारसँग तुलना गर्नुहोस्। यदि इन्टरफेसको नाम र नेमस्पेस मिल्छ तर काउन्टर डेल्टा शून्य छ भने, अनुरोध टनेलसम्म पुगेन। यदि काउन्टर डेल्टा स्वस्थ छ र रुट अन्यत्र देखाउँछ भने, टनेल ठीक छ र रुटिङ ठीक छैन। त्यही तुलनाले थुप्रै आउटपुटलाई निर्णयमा बदल्छ।

आउटपुट टिकटसँगै राख्नुहोस्, किनकि पछिको तुलना तब मात्र उपयोगी हुन्छ जब तपाईं के बदलियो देख्न सक्नुहुन्छ।

त्यसपछि एप्लिकेसन फेरि परीक्षण गरेर चक्र बन्द गर्नुहोस्, किनकि इन्टरफेस प्रयोगकर्तालाई कहिल्यै चासोको विषय थिएन।