Android हॉटस्पॉट पोर्ट फ़ॉरवर्डिंग: तीन प्रवेश बिंदु

आपने हॉटस्पॉट चालू किया, VPN जोड़ा, ऐप में पोर्ट खोला, और फिर भी दूसरा डिवाइस जुड़ नहीं पाता। गायब हिस्सा लगभग कभी पोर्ट खुद नहीं होता, बल्कि यह सवाल होता है कि कौन सी मशीन सुनने वाला सॉकेट रखती है और दूसरे डिवाइस को किस पते तक पहुँचना है। मैं फ़ोन से बाहर की ओर चलता हूँ, क्योंकि आपके सामने की स्क्रीन बताती है कि आप तीन प्रवेश बिंदुओं में से कौन सा वास्तव में जाँच रहे हैं।

वहीं से शुरू करें जहाँ सेवा वास्तव में चलती है

वह ऐप खोलें जिसे कनेक्शन स्वीकार करना है और उसका स्थिति पृष्ठ पढ़ें। अगर वह कहता है कि वह सुन रहा है, तो जिस पते से वह बंधा है उसे नोट करें, क्योंकि यही एक ब्यौरा नीचे के अधिकांश मामले तय करता है। 127.0.0.1 से बंधा ऐप सिर्फ़ फ़ोन से ही पहुँचा जा सकता है, और हॉटस्पॉट क्लाइंट, ऑपरेटर मैपिंग या VPN एग्ज़िट इसे नहीं बदलेंगे।

फिर पुष्टि करें कि सेवा कौन सा डिवाइस चलाता है। फ़ोन हो तो सॉकेट उसी ऐप का है; हॉटस्पॉट के पीछे लैपटॉप हो तो सुनने वाला और उसका फ़ायरवॉल लैपटॉप का है और फ़ोन सिर्फ़ पैकेट आगे भेजता है। ये दो अलग रचनाएँ हैं, और इन्हें मिलाना ही वह कारण है कि एक जगह खोला पोर्ट दूसरी जगह कुछ नहीं करता।

डीबग करने योग्य बिल्ड में adb shell सॉकेट की सूची /proc/net/tcp से बनाता है, पर अधिकतर लोगों के लिए ऐप की अपनी स्थिति ही ईमानदार स्रोत है।

पहला प्रवेश बिंदु: हॉटस्पॉट पर दूसरा डिवाइस

यह स्थानीय मामला है और सबसे आसान भी। दूसरा डिवाइस फ़ोन तक उस पते पर पहुँचता है जिसे वह अपना गेटवे देखता है, उस पोर्ट पर जहाँ ऐप सुन रहा है, और हॉटस्पॉट के बाहर कोई शामिल नहीं होता। ऑपरेटर मैपिंग की ज़रूरत नहीं, क्योंकि ट्रैफ़िक स्थानीय खंड से कभी बाहर नहीं जाता।

दो चीज़ें इसे तोड़ती हैं: ऐप का लूपबैक से बंधा होना, या फ़ोन की क्लाइंट नीति का स्थानीय कनेक्शन की अनुमति न देना। ऐप के अपने प्रोटोकॉल से जाँचें, नंगे TCP से नहीं, क्योंकि स्वीकार करके फिर मना करने वाला सुनने वाला दूर से बंद पोर्ट जैसा दिखता है।

अगर सेवा जुड़े लैपटॉप पर चलती है, तो फ़ोन का हॉटस्पॉट पता बिलकुल भी लक्ष्य नहीं है; लैपटॉप का हॉटस्पॉट इंटरफ़ेस पर पता और वहाँ सुनने वाला चाहिए।

दूसरा प्रवेश बिंदु: ऑपरेटर का रास्ता

मोबाइल नेटवर्क से फ़ोन तक पहुँचना दूसरी समस्या है, और IPv4 के लिए यह अक्सर काम ही नहीं करता। ऑपरेटर डिवाइसों को साझा अनुवाद के पीछे रखते हैं, इसीलिए RFC 6598 ऐसी ही व्यवस्था के लिए साझा पता श्रेणी अलग रखता है। बिना माँगे आने वाले कनेक्शन के पास आने का कोई मैपिंग नहीं होता, और कोई स्थानीय कॉन्फ़िगरेशन एक भी नहीं बनाता, क्योंकि अनुवादक आपका डिवाइस नहीं है।

रूट पहुँच भी इसे नहीं बदलती; वह फ़ोन के स्टैक पर नियंत्रण देती है, ऑपरेटर के अनुवादक पर नहीं। जहाँ ऑपरेटर सार्वजनिक IPv6 उपसर्ग देता है वहाँ आने वाला रास्ता हो सकता है, पर सुनने वाले और फ़ायरवॉल को अब भी स्पष्ट अनुमति चाहिए।

तीसरा प्रवेश बिंदु: VPN एग्ज़िट

सुरंग चालू रहने पर कोई वेबसाइट जो पता बताती है वह ढके हुए बाहर जाने वाले ट्रैफ़िक के लिए एग्ज़िट का पता है। यह आपकी ओर से आने वाले कनेक्शन स्वीकार करने वाला पता नहीं है। इसे अंदर की दिशा में इस्तेमाल करने के लिए वह सुविधा चाहिए जो प्रदाता सचमुच देता है, जैसे अग्रेषित पोर्ट, साथ में एग्ज़िट से क्लाइंट तक काम करने वाला रास्ता।

स्थानीय अनुमति नियम वह मैपिंग नहीं बना सकता। वह जो करता है वह यह बदलना है कि ऐप के उत्तर कौन सा रास्ता लेते हैं, और यह तब मायने रखता है जब ऐप सुरंग से बाहर रखा गया हो: अनुरोध और उत्तर अलग नेटवर्क संदर्भों में पड़ सकते हैं और कनेक्शन फ़ायरवॉल की समस्या जैसा विफल हो जाता है।

एक रास्ता शुरू से अंत तक जाँचें, फिर मालिक का नाम लें

जाँच से पहले चौकड़ी लिखें: इच्छित स्रोत, गंतव्य पता, परिवहन, पोर्ट और वह मशीन जो सुनने वाला सॉकेट रखती है। कोई भी तत्व अनुमान हो तो जाँच कुछ उपयोगी नहीं बताएगी।

फिर उस एक अनुमत रास्ते को ऐप के प्रमाणीकरण के साथ जाँचें। अस्पष्ट पता जाँच को उत्तर देने के लिए चौड़ा सुनने वाला प्रकाशित न करें और असंबंधित नियंत्रण बंद न करें, क्योंकि दोनों बदलाव जाँच के बाद भी रहते हैं।

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

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