कैसे जाँचें कि लिनक्स पर VPN टनल वाकई चालू है

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

लिंक फ़्लैग उपकरण बताते हैं, रास्ता नहीं

जो जाँच सब कॉपी करते हैं वह सिर्फ़ शून्यों से बना हार्डवेयर पता खोजती है। यह तरकीब कुछ ड्राइवरों में असली इंटरफ़ेस को प्लेसहोल्डर से अलग करती है और बाकी में कुछ साबित नहीं करती, क्योंकि tun उपकरण के पास बताने के लिए MAC ही नहीं होता। ip -brief link show tun0 इसके बजाय फ़्लैग देता है: UP का मतलब है कि किसी प्रशासक ने उपकरण सक्षम किया, और LOWER_UP का मतलब है कि ड्राइवर लिंक को उपयोग-योग्य मानता है। साथ पढ़ने पर वे बताते हैं कि उपकरण मौजूद है और प्रशासनिक रूप से बंद नहीं है। इनमें से कोई यह नहीं बताता कि पैकेट के पास जाने की कोई जगह है।

OpenVPN रूट लगने से पहले ही अपना tun उपकरण बना लेता है, इसलिए फ़्लैग तब पूरे सही लग सकते हैं जब कुछ भी रूट न हो। इन्हें पूर्व-शर्त मानें, कभी जवाब नहीं।

पूछें कि पैकेट कहाँ जाएगा

रूट लुकअप उस सवाल का जवाब देता है जो फ़्लैग नहीं दे सकते। ip route get 10.8.0.1 from 10.8.0.2 इंटरफ़ेस, स्रोत पता और वह तालिका बताता है जो कर्नेल इस्तेमाल करेगा, और स्प्लिट टनल को ठीक उसी के ख़िलाफ़ जाँचना होता है। स्रोत पते के बिना आप कुछ और पूछ रहे हैं, और नीति-आधारित रूटिंग में जवाब स्रोत के हिसाब से अलग हो सकता है। यह सबसे सस्ती ईमानदार जाँच है, क्योंकि यह वही नियम देखती है जो आपका ट्रैफ़िक इस्तेमाल करेगा।

WireGuard के लिए हैंडशेक भी जोड़ें। wg show हर साथी के लिए नवीनतम हैंडशेक का समय-चिह्न छापता है, और ऐसा समय-चिह्न जो बढ़ना बंद हो गया हो का मतलब है कि साथी जा चुका है, चाहे इंटरफ़ेस फ़्लैग कुछ भी कहें। हाल के हैंडशेक के बिना कॉन्फ़िगर किया गया इंटरफ़ेस घर में बनी मॉनिटरिंग में सबसे आम झूठे सकारात्मक नतीजों में से एक है।

तालिका 220 IPsec की कहानी कहती है

strongSwan रूट इंस्टॉलेशन सक्षम होने पर बातचीत किए गए चयनकर्ताओं के लिए तालिका 220 में रूट लगाता है। ip route list table 220 इसलिए बातचीत किए गए को रूट किए गए से अलग करता है: लोड किए गए कनेक्शन के बगल में खाली तालिका का मतलब है कि IKE और CHILD SA ऊपर आए जबकि उनकी ओर कोई ट्रैफ़िक नहीं भेजा जा रहा। जाँचें ip xfrm state को उसके साथ, क्योंकि यह स्थापित सुरक्षा संगठनों और उनके अंतिम बिंदुओं की सूची देता है।

ट्रैप नीति वही मामला है जिस पर नज़र रखनी चाहिए। यह रूट करने के बजाय दिलचस्प ट्रैफ़िक का इंतज़ार करती है, इसलिए तालिका तब तक खाली रहती है जब तक कुछ टनल न चालू करे।

मैनेजर की स्थिति और डेमन की स्थिति अलग-अलग सूचियाँ हैं

NetworkManager सिर्फ़ उन कनेक्शनों की सूची देता है जो उसके हैं। nmcli -t -f NAME,TYPE connection show --active सीधे wg-quick या OpenVPN डेमन से शुरू की गई टनल के लिए कुछ नहीं लौटाता।

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

अगले चरण को उस जाँच पर टिकाएँ जिसकी उसे ज़रूरत है

UDP पोर्ट को पोल करना तैयारी के बारे में कुछ साबित नहीं करता, क्योंकि UDP में हैंडशेक नहीं होता और nc -u पैकेट निकलते ही सफल हो जाता है। जाँचें कि अगला चरण वाकई क्या खपत करता है: फ़ॉरवर्ड किए गए पोर्ट पर TCP कनेक्शन, टनल के भीतर किसी होस्ट को अनुरोध, ऐसा नाम जो सिर्फ़ वहीं हल होता है। प्रतीक्षा को समय-सीमा और प्रयासों की संख्या से बाँधें, और ख़त्म होने पर ज़ोर से विफल हों।

जब क्लाइंट हुक देता है तो हुक पोलिंग से बेहतर होते हैं। --up और --down OpenVPN की स्क्रिप्टें इंटरफ़ेस का हाल बदलने के बाद चलती हैं, जो दौड़ पूरी तरह ख़त्म कर देता है, पर वे डेमन के रखे विशेषाधिकारों के साथ चलती हैं। अगर OpenVPN user और group के ज़रिए बिना विशेषाधिकार वाले खाते में गिर गया है, तो हुक उसी खाते के रूप में चलता है। तब सिस्टम सेवा को फिर से चलाने के लिए sudo चाहिए जो ठीक उसी आदेश की अनुमति दे। पुनःप्रयास cron लूप के बजाय सेवा मैनेजर को सौंपें: शुरुआत-सीमा वाली सीमित रीस्टार्ट नीति टूटी टनल को सामने लाती है, जबकि असीमित लूप उसे अनिश्चित काल तक छिपाए रखता है।