Android VpnService अनुमति सूची: अनुमति दिइएका पृष्ठ अझै किन अड्किन्छन्

तपाईंको अनुमति सूची सम्भवतः ठीक छ। पृष्ठहरू DNS उत्तर, मार्ग तालिका, रिजोल्भर सकेट वा MTU का कारण अड्किन्छन्। जाँचको क्रम यही हो।

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

मिलाउने नै दोषी हुने कमै हुन्छ

पहिले छुट्याउनुपर्ने कुरा अवरुद्ध र बिग्रिएको हो। अवरुद्ध नाम छिटो र देखिने गरी असफल हुनुपर्छ, किनकि ब्राउजरले नाम अवस्थित छैन भन्ने उत्तर पाएर रोकिन्छ। बिग्रिएको नाम अड्किन्छ, IPv6 मार्फत पुनः प्रयास गर्छ, अर्को यातायातमा जान्छ, र तपाईंलाई घुम्ने सूचक छोड्छ। यदि तपाईंले घुम्ने सूचक देख्नुभयो भने, तपाईंको अनुमति सूचीले क्लाइन्टले केही गर्न नसक्ने कुराको उत्तर दिइरहेको छ।

खाली A रेकर्ड सामान्य गल्ती हो। शून्य उत्तरसहित NOERROR फर्काउनु वैध उत्तर जस्तो देखिन्छ, त्यसैले stub रिजोल्भरले स्वीकार्छ, ब्राउजरले पुनः प्रयास गर्छ, AAAA प्रयास गर्छ, अर्को रिजोल्भर प्रयास गर्छ, र धेरै पछि हार्छ। प्रश्न खण्ड दोहोर्याएर र लेनदेन ID प्रतिलिपि गरेर दिइएको उत्तर कोड 3, अर्थात् NXDOMAIN, कुराकानी तुरुन्तै अन्त्य गर्छ। तपाईंले जानाजान अस्वीकार गर्ने प्रत्येक नामका लागि यो प्रयोग गर्नुहोस्।

IPv6 पनि डिफल्टको सट्टा त्यही निर्णयको योग्य छ। यदि तपाईंले A का लागि NXDOMAIN उत्तर दिनुभयो र AAAA पास गर्न दिनुभयो भने, क्लाइन्ट IPv6 मार्फत अवरुद्ध नामसम्म पुग्न सक्छ र फिल्टर चुहिन्छ। केही कार्यान्वयनले अवरुद्ध AAAA क्वेरीहरूलाई loopback ठेगानासँग उत्तर दिन्छन् ताकि जडान विकल्पमा नगई तुरुन्तै असफल होस्। एउटा नीति छान्नुहोस्, दुवै रेकर्ड प्रकारमा लागू गर्नुहोस्, र दुवै लग गर्नुहोस्।

सबै समात्ने मार्ग सबैको मालिक हुन्छ

केवल DNS भएको डिजाइनले कहिल्यै addRoute("0.0.0.0", 0) थप्दैन, त्यसैले TUN इन्टरफेसमा क्वेरी मात्र पस्छन् र बाँकी सबै तलको सञ्जाल प्रयोग गरिरहन्छ। यही सुरक्षित आकार हो, र केही अनुमति सूचीहरू Wi-Fi मा काम गरेजस्तो देखिने तर मोबाइल सञ्जालमा असफल हुने कारण पनि यही हो।

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

रिजोल्भर सकेट सुरुङबाट बाहिर जानुपर्छ

फर्वार्डिङ अर्को जाल बस्ने ठाउँ हो। वाहकका रिजोल्भरहरू प्रायः सुरुङले पुग्न नसक्ने निजी ठेगानामा बस्छन्, त्यसैले तपाईंले अगाडि पठाउनुभएको क्वेरी कतै जाँदैन र एपले पढ्ने समय सकिएको रिपोर्ट गर्छ। स्वीकृत क्वेरीहरू पुग्न सक्ने भन्ने थाहा भएको रिजोल्भरमा पठाउनुहोस्, र त्यो सकेट पहिले VpnService.protect() लाई दिनुहोस्। असुरक्षित सकेटले क्वेरी तपाईंको आफ्नै सुरुङमा फर्काउँछ, जहाँ त्यो फेरि एपसम्म पुग्छ र समयसीमा सक्रिय नहुन्जेल घुम्छ।

खराबी सञ्जाल अवरोधजस्तै देखिन्छ, र त्यसैले बग रिपोर्टमा यति लामो बाँच्छ। पठाइएका क्वेरी र प्राप्त उत्तरका लागि गणक राख्नुहोस्: पहिलो संख्या बढ्यो र दोस्रो शून्यमै रह्यो भने, तपाईं सूची होइन, सकेटतिर हेरिरहनुभएको छ।

आकार र चेकसम सन्देश बिना असफल हुन्छन्

चुपचाप छोड्ने काम आकारबाट पनि हुन्छ। ठूलो उत्तर समूह भएको DNS उत्तर, वा प्रशस्त विकल्प भएको TCP ह्यान्डसेक, तपाईंले कहिल्यै स्पष्ट रूपमा सेट नगरेको मार्ग MTU नाघ्न सक्छ; टुक्रा माथि हराउँछ र क्लाइन्टले सानो आकारमा पुनः प्रयास गर्छ वा प्रयास छोड्छ। इन्टरफेस MTU 1280 मा सेट गर्नु रूढिवादी विकल्प हो जुन धेरै मोबाइल मार्गमा टिक्छ, र कसैले ननापेको डिफल्ट मूल्य पाउँदा स्पष्ट हुनु राम्रो हो।

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

VpnService ले तपाईंका लागि के गर्दैन

यसका वरिपरि डिजाइन गर्नु अघि दुई सीमा जान्न लायक छन्। कुनै पनि सामान्य एपले Wi-Fi बाहिर प्रणाली-व्यापी प्रोक्सी वा PAC फाइल स्थापना गर्न सक्दैन, र त्यो भाग बदलिएको छैन। प्रति-एप मार्ग भने बदलिएको छ: API 29 अघि VpnService.Builder ले प्रोक्सी नै बोक्न सक्दैनथ्यो, र API 29 देखि setHttpProxy(ProxyInfo.buildPacProxy(uri)) ले VPN सञ्जालका लागि मूल्याङ्कन गर्न प्लेटफर्मलाई PAC स्क्रिप्ट दिन्छ। पुराना API लक्षित गर्दा वा PAC मोडेलले नियम व्यक्त गर्न नसक्दा नियमहरू आफ्नै कोडमा मूल्याङ्कन गर्नुहोस्। UDP पनि निःशुल्क छैन: ब्राउजरहरूले SOCKS प्रोक्सीमार्फत TCP मात्र पठाउँछन्, र धेरैजसो SOCKS5 क्लाइन्टहरूले UDP ASSOCIATE कहिल्यै कार्यान्वयन गर्दैनन्, त्यसैले प्रोक्सी-आधारित डिजाइनले TCP स्वस्थ देखिँदा UDP छोड्छ वा चुहाउँछ।

त्यही दोस्रो सीमा UDP-आधारित प्रोटोकल सामान्य सञ्जालमा काम गरेर तपाईंको VPN जोडिने क्षणमा असफल हुने कारण हो। यदि सुरुङले UDP बोक्नुपर्ने अपेक्षा छ भने, फर्वार्डरले त्यसका लागि फर्वार्डिङ मार्ग कार्यान्वयन गर्नुपर्छ, अर्को सकेट प्रकार भएको TCP मार्ग मात्र होइन।

यही क्रममा जाँच्नुहोस्

सूची क्रममा काम गर्नुहोस् र असफल हुने पहिलो चरणमा रोक्नुहोस्, किनकि अघिल्लो नटिकेसम्म हरेक पछिको जाँच कोलाहल मात्र हो।

  1. स्थापित मार्गहरू सूचीबद्ध गर्नुहोस् र DNS नभएका प्याकेटहरू TUN इन्टरफेसमा पस्छन् कि पस्दैनन् पुष्टि गर्नुहोस्।
  2. एउटा अवरुद्ध र एउटा स्वीकृत नामका लागि क्वेरी नाम, निर्णय र उत्तर कोड लग गर्नुहोस्।
  3. रिजोल्भर सकेट सुरक्षित छ र छानिएको रिजोल्भरले सुरुङभित्रबाट उत्तर दिन्छ भनी पुष्टि गर्नुहोस्।
  4. इन्टरफेस MTU र हातले बनाइएको एउटा उत्तरको चेकसम पुष्टि गर्नुहोस्।
  5. त्यही पृष्ठ Wi-Fi र मोबाइल सञ्जालमा दोहोर्याउनुहोस्, किनकि वाहकका रिजोल्भर र मार्ग MTU फरक हुन्छन्।

पाँचै टिके र पृष्ठ अझै अड्कियो भने, अर्को शंकास्पद फर्वार्डर आफैं हो: समातिएको अनुरोधलाई समातिएको उत्तरसँग तुलना गर्नुहोस् र हराएको बाइट गणना वा आधा बन्द सकेट खोज्नुहोस्। VpnService.Builder सन्दर्भ ले मार्ग, DNS र MTU सम्झौता समेट्छ, र protect() builder विकल्प होइन, अलग VpnService कल हो; जोडिएको इन्टरफेसले पहिलो सम्झौता पूरा भएको मात्र बुझाउँछ।

सम्बन्धित लेखहरू