एन्ड्रोइड हटस्पट पोर्ट फर्वार्डिङ: तीन प्रवेश बिन्दु

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

सेवा वास्तवमै चल्ने ठाउँबाट सुरु गर्नुहोस्

जडान स्वीकार गर्नुपर्ने एप खोल्नुहोस् र त्यसको स्थिति पृष्ठ पढ्नुहोस्। यदि यसले सुनिरहेको छ भन्छ भने, यसले बाँध्यो भनेको ठेगाना नोट गर्नुहोस्, किनकि त्यो एउटै विवरणले तलका धेरै केसहरू निर्धारण गर्छ। 127.0.0.1 मा बाँधिएको एप फोनबाट मात्र पुग्न सकिन्छ, र कुनै पनि हटस्पट क्लाइन्ट, क्यारियर म्यापिङ वा VPN निकासले त्यो बदल्ने छैन।

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

डिबग गर्न मिल्ने बिल्डमा adb shell ले /proc/net/tcp मार्फत सकेटहरू सूचीबद्ध गर्न सक्छ, तर धेरै मानिसका लागि एपको आफ्नै स्थिति इमानदार स्रोत हो। यसले तपाईंले अपेक्षा नगरेको ठेगानामा एपले खोलेको सकेट परीक्षण गर्ने जालबाट पनि बचाउँछ।

पहिलो प्रवेश बिन्दु: हटस्पटमा अर्को यन्त्र

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

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

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

दोस्रो प्रवेश बिन्दु: क्यारियर मार्ग

मोबाइल नेटवर्कबाट फोनमा पुग्नु फरक समस्या हो, र प्रायः IPv4 का लागि यो सिधै काम गर्दैन। क्यारियरहरूले ह्यान्डसेटहरूलाई साझा अनुवाद पछाडि राख्छन्, त्यसैले RFC 6598 ले ठ्याक्कै त्यस्तै व्यवस्थाका लागि साझा ठेगाना दायरा छुट्याएको छ। नमागिएको भित्रिने जडानसँग आउन कुनै म्यापिङ हुँदैन, र जतिसुकै स्थानीय कन्फिगरेसन गरे पनि त्यो सिर्जना हुँदैन, किनकि अनुवादक तपाईंको यन्त्र होइन।

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

तेस्रो प्रवेश बिन्दु: VPN निकास

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

स्थानीय अनुमति नियमले त्यस्तो म्यापिङ सिर्जना गर्न सक्दैन। यसले गर्न सक्ने भनेको एपका जवाफहरू कुन मार्गबाट जान्छन् भन्ने बदल्नु हो, र एप टनेलबाट बाहिर राखिएको बेला यो महत्त्वपूर्ण हुन्छ: अनुरोध र जवाफ फरक नेटवर्क सन्दर्भमा पुग्न सक्छन्, र जडान फायरवाल समस्याजस्तो देखिने तरिकाले असफल हुन्छ।

एउटा मार्ग सुरुदेखि अन्त्यसम्म परीक्षण गर्नुहोस्, त्यसपछि मालिकको नाम दिनुहोस्

परीक्षण गर्नु अघि टपल लेख्नुहोस्: इच्छित स्रोत, गन्तव्य ठेगाना, यातायात, पोर्ट र सुन्ने सकेटको मालिक मेसिन। यदि कुनै तत्व अनुमान हो भने, परीक्षणले तपाईंलाई उपयोगी केही बताउने छैन, र अन्त्यमा पहिलो व्याख्या गर्न दोस्रो तह बदल्नुहुनेछ।

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

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

• सुन्ने सकेट इच्छित सहकर्मीले पुग्न सक्ने ठेगानामा छ, लूपब्याकमा होइन।
• सहकर्मीले त्यो प्रवेश बिन्दुको ठेगाना प्रयोग गरिरहेको छ, स्थिति पृष्ठको निकास ठेगाना होइन।
• क्यारियर वा प्रदायक पक्षको कुनै पनि म्यापिङ समर्थित सुविधा हो, तपाईंले स्थानीय रूपमा थपेको नियम होइन।
• अनुरोध र जवाफ एउटै नेटवर्क सन्दर्भबाट जान्छन्, र एपको प्रमाणीकरण अझै पास हुन्छ।