पूरी मशीन के बिना एक ऐप को 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, असली अनुरोध से काउंटर का अंतर, और वह रूट और पता जो ऐप को वास्तव में चाहिए। ये लिखे होने पर अगला कदम स्पष्ट है और किसी ख़ास परत का है। इनके बिना हर अगला बदलाव रोलबैक योजना वाला अनुमान है।

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

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

फिर ऐप को दोबारा जाँचकर चक्र पूरा करें, क्योंकि इंटरफ़ेस कभी वह चीज़ नहीं थी जिसकी उपयोगकर्ता को परवाह थी।