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 इंटरफेसवर समकक्ष नसेल तर तो सेवा अपयश नसून फॉरवर्डिंग निर्णय आहे। दोन्ही कॅप्चर विनंती दाखवतात आणि फक्त एक उत्तर दाखवते, तेव्हा उरलेला संशयित परतीचा मार्ग आहे।

कोणत्या पत्त्याने उत्तर दिले आणि कोणते फॉरवर्ड केलेले गंतव्य अयशस्वी झाले ते नोंदवा। तेच वाक्य अहवालाला सर्व्हर अगम्य आहे या दाव्याऐवजी कृतीयोग्य बनवते।