NetGuard चा SOCKS मोड TCP व्यापतो, प्रत्येक प्रोटोकॉल नाही

NetGuard रहदारी गाळण्यासाठी Android चा VPN इंटरफेस ताब्यात घेतो आणि समर्थित कनेक्शन SOCKS एंडपॉइंटला देऊ शकतो। ही दोन तथ्ये अनेकदा “फोन VPN वर आहे” अशी वाचली जातात, पण हा असा निष्कर्ष आहे ज्याला ही यंत्रणा आधार देत नाही। फिल्टर पॅकेट पाहतो; प्रॉक्सी फक्त तिला प्रत्यक्ष दिलेली कनेक्शन पाहते। या दोन विधानांमध्ये व्यापाचा संपूर्ण प्रश्न आहे।

मूळ प्रकल्पाच्या FAQ मध्ये एक-सेवा मर्यादा आणि SOCKS पर्याय दोन्ही नोंदवले आहेत। पर्यायाचे अस्तित्व हे प्रत्येक अनुमत पॅकेट तो वापरतो याचा पुरावा नाही, आणि व्यापाचे प्रश्न याच अंतरातून उठतात।

एका अॅपमध्ये दोन फॉरवर्डिंग मार्ग

अंमलबजावणीच्या TCP बाजूला SOCKS कनेक्शन हाताळणी असते, त्यामुळे अनुमत TCP कनेक्शन प्रॉक्सीशी बोलणी करून त्यातून नेले जाऊ शकते। UDP बाजूला वेगळा सॉकेट मार्ग असतो, आणि त्याची पाठवणे व घेणे यांची हाताळणी त्या TCP बोलणीवर अवलंबून नाही। त्यामुळे फिल्टर अनुमती देत असलेला डेटाग्राम प्रॉक्सीतून कधीही न जाता सामान्य नेटवर्कपर्यंत पोहोचू शकतो। यात अॅपची कोणतीही खराबी नाही; दोन मार्ग जे अंमलात आणतात ते इतकेच।

या फरकाचा एक परिणाम आहे जो लोक दोन्ही दिशांनी चुकीचा सांगतात। प्रत्येक UDP पॅकेटला गळती म्हणणे ब्लॉकिंग नियमांकडे दुर्लक्ष करते, कारण नाकारलेला डेटाग्राम कधीही बाहेर जात नाही। संपूर्ण रचनेला VPN म्हणणे अनुमत थेट मार्गाकडे दुर्लक्ष करते, कारण काही रहदारी खरोखर प्रॉक्सीशिवाय बाहेर जाते। तुमच्याकडे जे आहे ते अंशतः प्रॉक्सी असलेले गाळलेले उपकरण आहे, आणि प्रामाणिक वर्णन लेबल नाही, मॅट्रिक्स आहे।

UDP ची जाहिरात करणे म्हणजे ते अंमलात आणणे नाही

UDP समर्थनाचा दावा करणारा SOCKS सर्व्हर तुमच्या फोनच्या अॅपमध्ये त्याशी जुळणारी क्लायंट-बाजू हाताळणी जोडत नाही। प्रोटोकॉलची सैद्धांतिक वैशिष्ट्ये आणि स्थापित बिल्डचे वर्तन वेगवेगळे विषय आहेत, आणि तुमची रहदारी फक्त दुसरे वर्णन करते।

तुम्ही प्रत्यक्ष चालवत असलेली आवृत्ती व संरचना तपासा, नंतर निरुपद्रवी डेटाग्राम प्रवाह तपासा आणि तो प्रॉक्सीवर दिसतो का ते पहा। बाकी सर्व वैशिष्ट्यांच्या यादीतून काढलेला अंदाज आहे, आणि वैशिष्ट्यांच्या याद्या कोड मार्ग नाही, हेतू सांगतात।

DNS हा तिसरा मार्ग आहे, तपशील नाही

नाव निराकरण मॅट्रिक्समध्ये स्वतःची शाखा जोडते। स्थानिक DNS फॉरवर्डर, सामान्य UDP प्रश्न, प्रॉक्सीने स्वतः सोडवलेले गंतव्य होस्टनाव आणि ब्राउझरमधील एन्क्रिप्टेड रिझॉल्व्हर या चार वेगळ्या रचना आहेत। प्रश्न कोण पाहतो आणि कोणता नेटवर्क मार्ग तो नेतो यात त्या वेगळ्या आहेत, आणि त्या मिसळल्यास बाकीच्यांबद्दल काहीही सिद्ध न करणारी चाचणी तयार होते।

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

प्रॉक्सी वाहतूक आपोआप खाजगी नसते

साधा SOCKS हा फोनपासून प्रॉक्सीपर्यंतचा एन्क्रिप्टेड दुवा नाही। एंडपॉइंटपर्यंत दुसऱ्या संरक्षित मार्गाने पोहोचत असाल, तर तो मार्ग व त्याची अपयश धोरण नावाने सांगा, कारण खुल्या नेटवर्ककडे परतणे इशाऱ्याशिवाय खाजगी रचना सार्वजनिक करते। प्रॉक्सीचे स्वतःचे प्रमाणीकरणही महत्त्वाचे: सामायिक उपकरणावरील खुला श्रोता ही अशी सेवा आहे जिचा हिशोब कोणी देत नाही।

प्रोफाइलांमधील रचनांनाही तीच तपासणी लागते। कामाच्या प्रोफाइलचे VPN फक्त त्याचा मार्ग वापरणाऱ्या रहदारीचे रक्षण करते, आणि वैयक्तिक प्रोफाइलचा फायरवॉल व कामाचा बोगदा एकत्र असणे म्हणजे फायरवॉलची पुढील कनेक्शन त्या बोगद्यापर्यंत पोहोचते याचा पुरावा नाही। दोन्ही प्रोफाइल सहकार्य करतात असे गृहीत धरण्याऐवजी पोहोच व प्रमाणीकरण तपासा।

पान लोडने नाही, मॅट्रिक्सने व्यापाचे ऑडिट करा

अधिकृत मूल्यांकनासाठी, तुमच्यासाठी महत्त्वाच्या प्रत्येक वर्गाचे प्रतिनिधित्व करणारी निरुपद्रवी उदाहरणे निवडा: आवश्यक TCP, अनुमत UDP आणि दोन्ही पत्ता-कुटुंबांमधील DNS। प्रत्येकासाठी ते प्रॉक्सी झाले, अडवले गेले की थेट पाठवले गेले हे नोंदवा। तोच एक तक्ता हा निकाल आहे, आणि लोड झालेल्या पानाच्या स्क्रीनशॉटपेक्षा तो खूप उपयुक्त आहे।

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