NetGuard का SOCKS मोड TCP को कवर करता है, हर प्रोटोकॉल को नहीं
NetGuard एंड्रॉइड के VPN इंटरफ़ेस से ट्रैफ़िक फ़िल्टर करता है और समर्थित कनेक्शन SOCKS को दे सकता है। UDP, DNS और प्रोफ़ाइल के बीच पहुँच के लिए अलग ऑडिट चाहिए।
NetGuard ट्रैफ़िक फ़िल्टर करने के लिए एंड्रॉइड का VPN इंटरफ़ेस ले लेता है, और समर्थित कनेक्शन किसी SOCKS एंडपॉइंट को सौंप सकता है। इन दो तथ्यों को अक्सर “फ़ोन VPN पर है” के रूप में पढ़ा जाता है, जो ऐसा निष्कर्ष है जिसे यह तंत्र समर्थन नहीं देता। फ़िल्टर पैकेट देखता है; प्रॉक्सी केवल उन्हीं कनेक्शन को देखता है जो वास्तव में उसे सौंपे गए थे। इन दो कथनों के बीच कवरेज का पूरा सवाल है।
मूल परियोजना के FAQ में एक-सेवा सीमा और SOCKS विकल्प दोनों दर्ज हैं। विकल्प का होना इस बात का प्रमाण नहीं है कि हर अनुमत पैकेट उसका उपयोग करता है, और कवरेज के सवाल ठीक इसी अंतर से उठते हैं।
एक ही ऐप के भीतर दो फ़ॉरवर्डिंग रास्ते
कार्यान्वयन के TCP पक्ष में SOCKS कनेक्शन प्रबंधन शामिल है, इसलिए अनुमत TCP कनेक्शन को प्रॉक्सी के साथ तय किया जा सकता है और उसके ज़रिए ले जाया जा सकता है। UDP पक्ष का अलग सॉकेट रास्ता है, और उसका भेजने और प्राप्त करने का प्रबंधन उस TCP बातचीत पर निर्भर नहीं है। इसलिए फ़िल्टर जिस डेटाग्राम की अनुमति देता है वह कभी प्रॉक्सी से गुज़रे बिना सामान्य नेटवर्क तक पहुँच सकता है। इसमें ऐप की कोई खराबी नहीं है; दोनों रास्ते बस यही लागू करते हैं।
इस अंतर का एक परिणाम है जिसे लोग दोनों दिशाओं में गलत बताते हैं। हर UDP पैकेट को लीक कहना ब्लॉकिंग नियमों को अनदेखा करना है, क्योंकि अस्वीकृत डेटाग्राम कभी बाहर नहीं जाता। पूरी व्यवस्था को VPN कहना अनुमत सीधे रास्ते को अनदेखा करना है, क्योंकि कुछ ट्रैफ़िक वाकई प्रॉक्सी के बिना बाहर जाता है। आपके पास जो है वह आंशिक प्रॉक्सी वाला फ़िल्टर किया गया उपकरण है, और सच्चा विवरण लेबल नहीं, एक मैट्रिक्स है।
UDP का विज्ञापन करना उसे लागू करना नहीं है
UDP समर्थन का दावा करने वाला SOCKS सर्वर आपके फ़ोन के ऐप में उससे मेल खाता क्लाइंट-पक्ष प्रबंधन नहीं जोड़ता। प्रोटोकॉल की सैद्धांतिक विशेषताएँ और स्थापित बिल्ड का व्यवहार अलग विषय हैं, और आपके ट्रैफ़िक का वर्णन केवल दूसरा करता है।
आप वास्तव में जो संस्करण और कॉन्फ़िगरेशन चलाते हैं उसे जाँचें, फिर एक हानिरहित डेटाग्राम प्रवाह का परीक्षण करें और देखें कि वह प्रॉक्सी पर दिखता है या नहीं। बाकी सब विशेषताओं की सूची से निकाला गया अनुमान है, और विशेषताओं की सूचियाँ कोड रास्ते नहीं, इरादे बताती हैं।
DNS तीसरा रास्ता है, कोई ब्यौरा नहीं
नाम विश्लेषण मैट्रिक्स में अपनी शाखा जोड़ता है। स्थानीय DNS फ़ॉरवर्डर, सामान्य UDP क्वेरी, प्रॉक्सी द्वारा स्वयं हल किया गया गंतव्य होस्टनाम, और ब्राउज़र में एन्क्रिप्टेड रिज़ॉल्वर — ये चार अलग व्यवस्थाएँ हैं। ये इसमें भिन्न हैं कि क्वेरी कौन देखता है और कौन सा नेटवर्क रास्ता उसे ले जाता है, और इन्हें मिलाने से ऐसा परीक्षण बनता है जो बाकियों के बारे में कुछ सिद्ध नहीं करता।
सचेत रूप से तय करें कि आप कौन सा चाहते हैं। अगर आवश्यकता यह है कि नाम सुरंग से होकर हल हों, तो अकेला ब्राउज़र सेटिंग यह नहीं देगा, और जो प्रॉक्सी स्वयं होस्टनाम हल करता है वह उत्तर केवल उन कनेक्शनों के लिए बदलता है जिन्हें वह वास्तव में संभालता है।
प्रॉक्सी परिवहन अपने आप निजी नहीं होता
सादा SOCKS फ़ोन से प्रॉक्सी तक का एन्क्रिप्टेड लिंक नहीं है। अगर एंडपॉइंट तक किसी और सुरक्षित रास्ते से पहुँचा जाता है, तो उस रास्ते का और उसकी विफलता नीति का नाम लें, क्योंकि खुले नेटवर्क पर वापसी बिना चेतावनी निजी व्यवस्था को सार्वजनिक बना देती है। प्रॉक्सी का अपना प्रमाणीकरण भी मायने रखता है: साझा उपकरण पर खुला श्रोता ऐसी सेवा है जिसका हिसाब कोई नहीं देता।
प्रोफ़ाइल के बीच की व्यवस्थाएँ भी उसी जाँच की हक़दार हैं। कार्य-प्रोफ़ाइल का VPN केवल उसी ट्रैफ़िक की रक्षा करता है जो उसके रास्ते का उपयोग करता है, और व्यक्तिगत प्रोफ़ाइल के फ़ायरवॉल के साथ कार्य-सुरंग का सहअस्तित्व यह सिद्ध नहीं करता कि फ़ायरवॉल का आगे का कनेक्शन उस सुरंग तक पहुँचता है। दोनों प्रोफ़ाइल के सहयोग मानने के बजाय पहुँच और प्रमाणीकरण सत्यापित करें।
कवरेज का ऑडिट पेज लोड से नहीं, मैट्रिक्स से करें
अधिकृत मूल्यांकन के लिए ऐसे हानिरहित उदाहरण चुनें जो आपके लिए मायने रखने वाली हर श्रेणी का प्रतिनिधित्व करें: आवश्यक TCP, अनुमत UDP और दोनों पता-परिवारों में DNS। हर एक के लिए दर्ज करें कि वह प्रॉक्सी हुआ, अवरुद्ध हुआ या सीधे भेजा गया। वही एक तालिका परिणाम है, और यह लोड हुए पेज के स्क्रीनशॉट से कहीं अधिक उपयोगी है।
अगर आवश्यकता यह है कि चुना गया सारा ऐप्लिकेशन ट्रैफ़िक दूरस्थ सुरंग से गुज़रे, तो स्पष्ट रूप से समर्थित संयुक्त फ़िल्टरिंग और टनलिंग वाला कार्यान्वयन चुनें। केवल TCP-प्रॉक्सी वाली रचना संकरे कामों के लिए उपयोगी रहती है, बशर्ते बाकी ट्रैफ़िक भुला दिए जाने के बजाय जानबूझकर संभाला जाए।