एडमिन अधिकारों के बिना पोर्टेबल VPN क्लाइंट: अब भी क्या टूटता है

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

पोर्टेबल तीन अलग वादों को कवर करता है, और केवल एक मुफ़्त है

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

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

वह विशेषाधिकार प्राप्त सहायक खोजें जिसे क्लाइंट कॉल करेगा

लगभग कोई भी VPN क्लाइंट स्वयं पैकेट नहीं हिलाता। Windows पर डेटा पथ WFP फ़िल्टर और Base Filtering Engine से होकर जाता है, macOS पर NetworkExtension प्रदाता से जिसे उपयोगकर्ता सिस्टम सेटिंग्स में स्वीकृत करता है, और Linux पर tun डिवाइस के साथ राउटिंग स्टैक से। आपने जो बाइनरी कॉपी की है वह उन घटकों के लिए नियंत्रण सतह है, उनका विकल्प नहीं। पूछें कि क्लाइंट किस घटक की अपेक्षा करता है, फिर पुष्टि करें कि वह स्थापित है, चल रहा है और आपके खाते से प्रयोग करने योग्य है।

दावा सिद्ध करने के लिए Linux सबसे आसान जगह है, क्योंकि जाँच एक ही सिस्टम कॉल है। /dev/net/tun खोलने और कर्नेल से डिवाइस माँगने के लिए CAP_NET_ADMIN चाहिए, और कर्नेल का TUN/TAP दस्तावेज़ स्वामित्व नियम और क्षमता दोनों बताता है। जाँच उस खाते से चलाएँ जो क्लाइंट शुरू करेगा, root के रूप में नहीं।

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

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

पहले कनेक्शन से पहले रूट और रिज़ॉल्वर बदलावों की जाँच करें

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

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

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

यदि पहली पंक्ति RTNETLINK answers: Operation not permitted लौटाती है, तो इसका अर्थ है कि खाता वह निजी रूट स्थापित नहीं कर सकता जिसकी प्रोफ़ाइल माँग करती है। दूसरी पंक्ति उसी अधिकार को उल्टा सिद्ध करती है, जो मायने रखता है क्योंकि जो क्लाइंट रूट जोड़ सकता है पर हटा नहीं सकता वह पीछे टूटी तालिका छोड़ देता है। फिर रिज़ॉल्वर क्वेरी दिखाती है कि निजी नाम टनल से हल होते हैं या उस रिज़ॉल्वर तक लीक होते हैं जिस पर होस्ट पहले से भरोसा करता है।

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

तय करें कि सत्र को क्या पार करना है

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

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

ip -brief addr show
ip route show table main
resolvectl status

दूसरी कैप्चर में मौजूद और पहली में अनुपस्थित हर चीज़ को मालिक चाहिए। या तो क्लाइंट बाहर निकलते समय उसे हटा देता है, या आप उसे उन्हीं कमांडों से हटाते हैं जिन्होंने उसे बनाया था, और वह हटाना परिनियोजन नोट्स में जाना चाहिए, किसी की याद में नहीं कि क्या हुआ था। Windows पर समकक्ष रीडिंग Get-NetAdapter, Get-NetRoute और Get-DnsClientServerAddress हैं, जिन्हें बढ़ोतरी की ज़रूरत नहीं है पर वही अवशेष दिखाते हैं।