एन्ड्रोइडको एकल-VPN नियमले होस्ट गरिएको SSH सर्भरलाई रोक्दैन

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

एक-VPN नियमले वास्तवमा के सीमित गर्छ

VpnService एउटै स्लटको स्रोत हो। जब एपले टनेल स्थापना गर्छ त्यो यन्त्रको VPN बन्छ, र टनेल स्थापना गर्न खोज्ने दोस्रो एप पहिलो नहटेसम्म अस्वीकार गरिन्छ। यो टनेलको स्वामित्वको नियम हो, र दुई VPN क्लाइन्ट एकैसाथ किन चल्न सक्दैनन् भन्ने व्याख्या गर्छ।

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

लिस्नर गन्तव्य हो, टनेलको भाग होइन

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

बन्धनका नियम सामान्य SSH कन्फिगरेसन हुन्: सुन्ने ठेगाना र पोर्ट, र कसले प्रमाणीकरण गर्न सक्छ। एन्ड्रोइडमा ती सेटिङ एपको आफ्नै कन्फिगरेसनमा हुन्छन्, र एपको प्रक्रियाको मालिकलाई विशेषाधिकार प्राप्त पोर्ट प्रयोग गर्न अनुमति नहुन सक्छ, त्यसैले root को रूपमा पोर्ट 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 सर्भर सन्दर्भ ले सुन्ने र पहुँच नियन्त्रण समेट्छ।