Android चा एक-VPN नियम होस्ट केलेल्या SSH सर्व्हरला अडवत नाही

हा विश्वास इतका सामान्य आहे की तो वस्तुस्थिती म्हणून घेतला जातो: Android फक्त एक VPN ला परवानगी देते, त्यामुळे फोनवर चालणारा SSH सर्व्हर त्या टनेलमधून काम करू शकत नाही. पहिला अर्धा भाग खरा आहे आणि निष्कर्ष त्यातून निघत नाही. प्लॅटफॉर्मची मर्यादा याबद्दल आहे की किती अॅप्स VPN सेवेचा स्लॉट धरू शकतात, याबद्दल नाही की किती सॉकेट असू शकतात किंवा फोनशी कोण जोडू शकतो. ऐकणारे सॉकेट असलेले SSH डीमन सामान्य पोर्ट असलेले सामान्य अॅप आहे, आणि टनेल हा त्याच्या रहदारीला जाता येणाऱ्या मार्गांपैकी एक आहे.

एक-VPN नियम प्रत्यक्षात काय मर्यादित करतो

VpnService एक-स्लॉट संसाधन आहे. जेव्हा अॅप टनेल स्थापित करते तेव्हा ते डिव्हाइसचे VPN होते, आणि टनेल स्थापित करण्याचा प्रयत्न करणारे दुसरे अॅप पहिले जाईपर्यंत नाकारले जाते. हा टनेलच्या मालकीचा नियम आहे, आणि दोन VPN क्लायंट एकाच वेळी का चालू शकत नाहीत हे स्पष्ट करतो.

ते ऐकणाऱ्या सॉकेटबद्दल काहीही सांगत नाही. SSH सर्व्हर VpnService ला कॉल करत नाही, पॅकेट अडवत नाही आणि त्या स्लॉटसाठी स्पर्धा करत नाही. तो पोर्ट बांधतो आणि कनेक्शन स्वीकारतो, जे VPN अजिबात नसतानाही तो करत असेल. त्यामुळे ही दंतकथा टनेल पुरवठादारांवरील मर्यादा नेटवर्क कनेक्शनवरील मर्यादेशी गोंधळते, आणि दोघांचा परस्पर संबंध नाही.

लिसनर हे गंतव्य आहे, टनेलचा भाग नाही

टनेल असल्यावर फोनचा त्यावर पत्ता असतो आणि पीअर उपकरणाचा त्या पत्त्यापर्यंत मार्ग असतो. काही उत्तर देते का हे लिसनर ठरवतो. loopback ला बांधलेला डीमन फोनमधूनच पोहोचू शकतो; जुन्या टनेल पत्त्याला बांधलेला डीमन पुन्हा जोडल्यावरही आपले बंधन टिकवू शकतो, पण ज्या पत्त्याला तो बांधला होता तो बदलला असतो.

बंधनाचे नियम सामान्य SSH कॉन्फिगरेशन आहेत: ऐकण्याचा पत्ता आणि पोर्ट, आणि कोण प्रमाणित करू शकतो. Android वर ती सेटिंग्ज अॅपच्या स्वतःच्या कॉन्फिगरेशनमध्ये असतात, आणि अॅपच्या प्रोसेसच्या मालकाला विशेषाधिकारित पोर्ट वापरण्याची परवानगी नसू शकते, त्यामुळे root म्हणून पोर्ट 22 बांधण्याची डेस्कटॉप सवय बदलाशिवाय हस्तांतरित होत नाही.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

मग मार्गावरच परवानगी आहे. बाहेर जाणारी वेब रहदारी आनंदाने वाहून नेणारे ग्राहक VPN आपल्या क्लायंटकडे येणाऱ्या कनेक्शनला अजिबात परवानगी देऊ शकत नाही; अनेक देत नाहीत, कारण त्याने एक ग्राहक दुसऱ्यासमोर उघड होईल. पीअर कोठूनही फोनच्या टनेल पत्त्यापर्यंत पोहोचू शकत नसेल, तर समस्या सेवेच्या धोरणात आहे, फोनमध्ये नाही.

प्रत्युत्तर मार्ग हेच सहसा तुटण्याचे ठिकाण

समजा पीअर फोनच्या टनेल पत्त्यापर्यंत पोहोचतो आणि SYN येतो. आता प्रत्युत्तर त्याच मार्गाने बाहेर पडले पाहिजे, आणि हा फोनच्या आतला मार्गनिर्धारणाचा निर्णय आहे. प्रत्युत्तर Wi-Fi ने बाहेर जाते कारण ते डीफॉल्ट नेटवर्क आहे, तर पीअरला कधीही पूर्ण न होणारे कनेक्शन दिसते, जे फायरवॉलसारखेच दिसते.

Android हे डेस्कटॉपपेक्षा अधिक गुंतागुंतीचे करते कारण डीफॉल्ट नेटवर्क प्रत्येक प्रोसेससाठी निवडले जाते आणि 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 हँडशेकपूर्वी किंवा नंतर अयशस्वी होते. कधीही जोडणार न बांधणारे सॉकेट आणि नाकारलेले लॉगिन वेगवेगळे टप्पे आहेत, जबाबदारही वेगळे.

डीबग करताना होस्ट-की पडताळणी आणि खाते निर्बंध अभंग ठेवा. लिसनर आणि परवानगी असलेल्या वापरकर्त्यांना मर्यादित करणे हेच पोहोचण्यायोग्य सर्व्हरला स्वीकारार्ह बनवते; कनेक्शन चालावे म्हणून ते सैल करणे एक समस्या अधिक वाईटाने बदलते. तुमची Android अंमलबजावणी तीच कॉन्फिगरेशन नावे पाळत असेल तर OpenSSH सर्व्हर संदर्भ ऐकणे आणि प्रवेश नियंत्रणे व्यापते.