एंड्रॉइड का एकल-VPN नियम होस्ट किए गए SSH सर्वर को नहीं रोकता

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

एकल-VPN नियम वास्तव में क्या सीमित करता है

VpnService एकल-स्लॉट संसाधन है। जब कोई ऐप टनल स्थापित करता है तो वह डिवाइस का VPN बन जाता है, और दूसरा ऐप जो टनल स्थापित करने की कोशिश करता है, पहले के हटने तक अस्वीकार कर दिया जाता है। यह टनल के स्वामित्व का नियम है, और यही बताता है कि दो VPN क्लाइंट एक साथ क्यों नहीं चल सकते।

यह सुनने वाले सॉकेट के बारे में कुछ नहीं कहता। SSH सर्वर VpnService को कॉल नहीं करता, पैकेट रोकता नहीं और उस स्लॉट के लिए प्रतिस्पर्धा नहीं करता। यह एक पोर्ट बाइंड करता है और कनेक्शन स्वीकार करता है, जो बिना VPN इंस्टॉल किए भी वही करता। इसलिए यह मिथक टनल प्रदाताओं की सीमा को नेटवर्क कनेक्शन की सीमा से मिला देता है, और दोनों का आपस में कोई संबंध नहीं है।

लिसनर एक गंतव्य है, टनल का हिस्सा नहीं

टनल बन जाने के बाद फ़ोन का उस पर एक पता होता है और पीयर डिवाइस का उस पते तक मार्ग होता है। कुछ जवाब देता है या नहीं, यह लिसनर तय करता है। loopback से बंधा डेमन केवल फ़ोन से ही पहुँचा जा सकता है; पुराने टनल पते से बंधा डेमन फिर से कनेक्ट होने के बाद अपना बंधन बनाए रख सकता है जबकि जिस पते से वह बंधा था वह बदल चुका है।

बाइंडिंग नियम साधारण SSH कॉन्फ़िगरेशन हैं: सुनने का पता और पोर्ट, और कौन प्रमाणित कर सकता है। एंड्रॉइड पर ये सेटिंग्स ऐप के अपने कॉन्फ़िगरेशन में रहती हैं, और ऐप की प्रक्रिया के स्वामी को विशेषाधिकार प्राप्त पोर्ट उपयोग करने की अनुमति नहीं हो सकती, इसलिए रूट के रूप में पोर्ट 22 बाइंड करने की डेस्कटॉप आदत बिना बदलाव के स्थानांतरित नहीं होती।

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

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

रिप्लाई पथ वह जगह है जहाँ यह आमतौर पर टूटता है

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

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

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

VPN को बायपास करना आने वाली सेवा को ठीक नहीं करता

लोकप्रिय उपाय, SSH ऐप को VPN से बाहर रखना ताकि उसका ट्रैफ़िक पुनर्निर्देशित होना बंद हो जाए, उलटी समस्या का समाधान है। यह तब मदद करता है जब बाहर जाते SSH क्लाइंट का परिवहन टनल के कारण बार-बार टूटता है। होस्ट किए गए सर्वर के लिए यह जवाबों को उस टनल से बाहर ले जा सकता है जिसका पीयर उपयोग कर रहा है, जिससे आंशिक विफलता पूर्ण विफलता बन जाती है।

यही राउटर पर सार्वजनिक पोर्ट खोलने पर भी लागू होता है। अगर आवश्यकता यह है कि एक अधिकृत डिवाइस VPN से फ़ोन तक पहुँचे, तो SSH को इंटरनेट पर उजागर करना एक अलग खतरा मॉडल है, मरम्मत नहीं।

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

एक बार में एक दिशा का निदान करें

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

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

पोर्ट जाँच पीयर से चलाएँ, फ़ोन से नहीं, और SSH क्लाइंट का विस्तृत आउटपुट पढ़ें कि यह TCP हैंडशेक से पहले या बाद में विफल होता है। जो सॉकेट कभी कनेक्ट नहीं होता और जो लॉगिन अस्वीकार होता है, वे अलग चरण हैं जिनके ज़िम्मेदार अलग हैं।

डिबग करते समय होस्ट-की सत्यापन और खाता प्रतिबंध अक्षुण्ण रखें। लिसनर और अनुमत उपयोगकर्ताओं को सीमित करना ही पहुँच योग्य सर्वर को स्वीकार्य बनाता है; कनेक्शन चलाने के लिए उन्हें ढीला करना एक समस्या को उससे बुरी समस्या से बदल देता है। अगर आपका एंड्रॉइड कार्यान्वयन वही कॉन्फ़िगरेशन नाम मानता है तो OpenSSH सर्वर संदर्भ सुनने और पहुँच नियंत्रणों को कवर करता है।