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, खऱ्या विनंतीतील काउंटर डेल्टा, आणि अनुप्रयोगाला प्रत्यक्षात आवश्यक असलेला मार्ग व पत्ता। ती लिहिली गेल्यावर पुढचे पाऊल स्पष्ट असते आणि ते विशिष्ट स्तराचे असते। ती नसल्यास, पुढील प्रत्येक बदल हा रोलबॅक योजनेसह केलेला अंदाज असतो।

ती चार तथ्ये कार्यरत सत्रातील त्याच चारांशी तुलना करा। इंटरफेसचे नाव व नेमस्पेस जुळतात पण काउंटर डेल्टा शून्य असेल, तर विनंती टनेलपर्यंत पोहोचलीच नाही। काउंटर डेल्टा निरोगी असेल आणि मार्ग दुसरीकडे निर्देश करत असेल, तर टनेल ठीक आहे आणि राउटिंग नाही। आउटपुटचा ढीग निर्णयात बदलणारी गोष्ट तीच तुलना आहे।

आउटपुट तिकिटासोबत ठेवा, कारण नंतरची तुलना काय बदलले हे दिसल्यासच उपयोगी ठरते।

मग अनुप्रयोग पुन्हा तपासून वर्तुळ बंद करा, कारण इंटरफेस वापरकर्त्याला कधीच महत्त्वाचा नव्हता।