VpnService protect() वा एप बहिष्कार: राउटिङ सुधार्ने कुन हो
टनेल बोक्ने सकेट सुरक्षित गर्नुहोस्, वा पूरै एप बहिष्कृत गर्नुहोस्: तपाईंको Android VPN लाई कति दायरा चाहिन्छ भनी निर्धारण गर्ने तीन सर्तहरू.
टनेलका आफ्नै प्याकेट टनेलबाहिर राख्ने दुई तरिका छन्: ट्रान्सपोर्ट सकेट सुरक्षित गर्ने, वा पूरै एप VPN बाट बाहिर निकाल्ने। ती फरक समस्याहरू समाधान गर्छन्, र जोड्न सजिलो भएकाले फराकिलो चयन गर्नु नै त्यो बाटो हो जसबाट एपहरूले नबुझीकनै स्थानीय सञ्जाल पहुँच र विभाजित DNS गुमाउँछन्। टनेलबाहिर रहनुपर्ने कुराबाट सुरु गर्नुहोस्, त्यसपछि त्यो हासिल गर्ने सबैभन्दा सानो दायरा छान्नुहोस्।
protect() ले टनेलबाट के हटाउँछ
VpnService.protect() प्रति-सकेट कल हो। टनेल बोक्ने सकेट वा डेस्क्रिप्टर तपाईंले यसलाई दिनुहुन्छ, र Android ले त्यो सकेट चिन्ह लगाउँछ ताकि यसको ट्राफिकले VPN इन्टरफेसको सट्टा तल्लो सञ्जाल प्रयोग गरोस्। एपले पठाउने बाँकी सबै सामान्य VPN मार्ग पछ्याउँछ।
त्यही साँघुरो दायरा मुख्य कुरा हो। सुरक्षित सकेटले तपाईंको HTTP क्लाइन्टले नाम कसरी समाधान गर्छ, तपाईंका विश्लेषण कलहरूले कुन इन्टरफेस प्रयोग गर्छन्, वा पछि खोलिने दोस्रो जडानलाई के हुन्छ भन्ने बदल्दैन।
दायरा निर्धारण गर्ने तीन सर्त
पहिलो सर्त के हो भने केवल टनेलको ट्रान्सपोर्ट बाहिर जानुपर्ने हो कि होइन। यदि एपको बाँकी ट्राफिक अझै VPN बाट जानुपर्ने हो भने, सकेट सुरक्षा नै सही दायरा हो। दोस्रो सर्त के हो भने सकेट सिर्जना तपाईंको नियन्त्रणमा छ कि छैन। भित्र गहिरोमा आफ्नै सकेट खोल्ने लाइब्रेरीले तपाईंलाई protect() कल गर्ने ठाउँ दिँदैन, जबसम्म त्यसले हुक दिँदैन वा तयार सकेट स्वीकार गर्दैन। तेस्रो सर्त के हो भने एपले स्थानीय सञ्जाल वा captive portal सिधै पुग्नुपर्ने हो कि होइन, जो टनेल जीवित राख्नुभन्दा फरक आवश्यकता हो।
एपलाई addDisallowedApplication() द्वारा बहिष्कृत गर्नु यो ठूलो हतियार हो। यसले एपले गर्ने हरेक जडान VPN बाट हटाउँछ, तपाईंले जाँच्न चाहेको पनि, र केही यन्त्रहरूमा स्थानीय पत्ता लगाउने व्यवहार पनि बदल्छ।
तेस्रो विकल्प ट्रान्सपोर्टलाई छानिएको सञ्जालमा बाँध्नु हो:bindProcessToNetwork() वा सकेट-स्तरको सञ्जाल ह्यान्डलद्वारा। यन्त्रमा एकै समयमा Wi-Fi र मोबाइल हुँदा र टनेल कुनै निश्चित माथिल्लो लिङ्कबाट जाओस् भन्ने चाहँदा यो उपयोगी हुन्छ।
ट्रान्सपोर्ट बन्दै गर्दा नै त्यसलाई कल गर्नुहोस्
कल गर्नुहोस्protect() ट्रान्सपोर्ट बनाउने त्यही ब्लकमा,connect() वाsend() अघि। कलले false फर्काएमा सकेट बन्द गर्नुहोस् र सेटअप असफल बनाउनुहोस्; जारी राख्दा प्याकेटहरू तपाईंकै इन्टरफेसमा फेरि छिर्न सक्ने ट्रान्सपोर्ट तपाईंसँग रहन्छ।
आकार एकै ठाउँमा राख्न सकिने गरी सानो छ:
DatagramSocket transport = new DatagramSocket();
if (!protect(transport)) {
transport.close();
throw new IOException("transport not protected");
}
transport.connect(serverAddress);यहाँ तीन विवरणले टोक्छन्। पहिलो,बुलियन नै तपाईंले पाउने एकमात्र सङ्केत हो, त्यसैले फिर्ता लिइएको सहमति र अस्वीकृत कल छुट्याउन पुग्ने सन्दर्भसहित असफलता अभिलेख गर्नुहोस्। दोस्रो,protect() सकेट ढाक्छ, डेस्क्रिप्टर नम्बर होइन: सकेट बन्द गरेर पछि त्यही पूर्णाङ्क अर्को सकेटका लागि प्रयोग गर्नुभयो भने नयाँ सकेट सुरक्षित हुँदैन। तेस्रो, नेटिभ लाइब्रेरीले ट्रान्सपोर्ट खोल्दा नेटिभ कोड जडान हुनुअघि डेस्क्रिप्टर सुरक्षित गर्नुहोस्, नत्र मार्ग पहिले नै छानिएको हुन सक्छ।VpnService सन्दर्भ तपाईंको लक्ष्य API स्तरले वास्तवमा कुन ओभरलोड दिन्छ भनी पुष्टि गर्ने ठाउँ हो।
खुसीको मार्ग मात्र होइन, अवरुद्ध मार्ग पनि परीक्षण गर्नुहोस्
टनेल उठाएर प्रमाणित गर्नुहोस्, किनकि दुई मार्ग फरक हुन सक्ने त्यही एउटै अवस्था हो। सुरक्षित ट्रान्सपोर्टबाट एउटा अनुरोध र protect() कहिल्यै कल नगरेको कोड मार्गबाट अर्को पठाउनुहोस्, त्यसपछि टाढाको छेउले के देख्छ भनी तुलना गर्नुहोस्: सुरक्षित जडान तल्लो सञ्जाललाई स्रोत बनाएर आउनुपर्छ, जबकि असुरक्षितले टनेलकै ठेगाना देखाउँछ र टनेलको बाइट गणक हल्लाउँछ। यन्त्रमाss वाnetstat रेडियोबाट केही बाहिर निस्कनुअघि नै त्यही विभाजन देखाउँछन्।
फिर्ता लिने परीक्षण अलग गर्नुहोस्, किनकि सहमतिको परिवर्तनले तपाईंको सकेट कोड छुँदै नछोडी इन्टरफेस भत्काउँछ। VPN सहमति फिर्ता लिनुहोस् वा सेवा रोक्नुहोस्, ट्रान्सपोर्ट पुनः बनाउनुहोस् र protect() अझै true फर्काउँछ र सहमति फेरि दिइएपछि ट्रान्सपोर्ट फेरि जोडिन्छ भनी पुष्टि गर्नुहोस्।
सुरक्षित अनुरोध तैपनि टनेल पछ्याउँछ भने, सुरक्षा कल सकेट पहिले नै राउट भइसकेपछि भइरहेको हुन सक्छ। यसलाई अगाडि सार्नुहोस् र फेरि परीक्षण गर्नुहोस्।
निर्णय ट्रान्सपोर्ट सेटअपको छेउमा लेखेर राख्नुहोस्: कुन सकेट सुरक्षित छन्, कुन एप ट्राफिक बहिष्कृत छ, र सुरक्षा असफल हुँदा एपले के गर्छ। त्यही पङ्क्तिले एउटा परीक्षण असफल भएकै कारण बहिष्कारलाई पूरै एपसम्म फैलाउनबाट पछिको पुनर्संरचना रोक्छ। यसले अर्को व्यक्तिलाई म्यानिफेस्ट उल्टो इन्जिनियरिङ नगरी मनसाय जाँच्ने बाटो पनि दिन्छ।