प्रशासकीय अधिकारांशिवाय पोर्टेबल 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 आहेत, त्यांना उंचावणीची आवश्यकता नाही पण तेच अवशेष दाखवतात।