VPN जुड़ता है पर LAN डिवाइस तक नहीं पहुँचता: क्या जाँचें

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

अब से गेटवे के दूसरी ओर कुछ जाँचें। गेटवे का अपना पता उत्तर देता रहेगा, चाहे फ़ॉरवर्डिंग कितनी भी टूटी हो।

गेटवे अपने ही स्टैक से उत्तर देता है

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

टनल से पहुँचे प्रशासन पृष्ठ भी पहली श्रेणी में आते हैं। वे टनल के बारे में साक्ष्य हैं, उसके पीछे के नेटवर्क के बारे में नहीं।

प्रवाह को पहली उस सीमा तक ट्रेस करें जो उसे गिरा देती है

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

गेटवे से वही परीक्षण चलाना दिलचस्प आधे हिस्से को छिपा देता है, क्योंकि गेटवे से उत्पन्न पैकेट का स्रोत अलग होता है और वापसी की आवश्यकता भी अलग होती है। हर कदम पर क्लाइंट के प्रवाह का, उसके अपने स्रोत पते के साथ, उपयोग करें। गलत इंटरफ़ेस पर लिया गया कैप्चर आत्मविश्वासी बकवास देता है।

वापसी मार्ग और होस्ट फ़ायरवॉल अलग-अलग विफल होते हैं

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

वापसी पथ को जानबूझकर जाँचें: क्लाइंट से भेजें और वापसी देखें। एकतरफ़ा कैप्चर सेकंडों में वह तय कर देता है जो एक घंटे की अटकल नहीं तय करेगी।

क्लाइंट के स्रोत पते से हर हॉप की पुष्टि करें

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

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

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

दर्ज करें कि किस पते ने उत्तर दिया और कौन गंतव्य फ़ॉरवर्ड होकर विफल हुआ। यही वाक्य रिपोर्ट को कार्रवाई योग्य बनाता है, सर्वर अगम्य होने के दावे के बजाय।