Android SSH SOCKS प्रोक्सी: तपाईंका आधा एप मात्र किन जोडिन्छन्
ssh -D ले SOCKS श्रोता बनाउँछ, पूरै यन्त्रको टनेल होइन। एपबाट अनुकूलक र SSH सम्मको शृंखला हिँड्नुहोस्, त्यसपछि DNS र जीवनचक्रका खाडल जाँच्नुहोस्।
तपाईं SSH मार्फत लगइन गर्नुहुन्छ, -D 1080 थप्नुहुन्छ र आदेश सफल हुन्छ। अब फोनमा SOCKS श्रोता छ, र आधा एप अझै मोबाइल डेटाबाट बाहिर जान्छन्। यो सामान्य परिणाम हो, बिग्रिएको टनेल होइन: ssh -D ले प्रोक्सी अन्त्यबिन्दु बनाउँछ, र Android एपले केहीले बाध्य पारेमा मात्र प्रोक्सी प्रयोग गर्छन्। शृंखला पाइला पाइला हिँड्दा कामको प्रत्येक भाग वास्तवमै कहाँ छ भन्ने देखिन्छ।
ट्राफिक सुरु हुने ठाउँबाट सुरु गर्नुहोस्
टनेल प्रयोग गर्नुपर्ने एउटा एप छान्नुहोस् र त्यसको आफ्नै प्रोक्सी सेटिङ छ कि जाँच्नुहोस्। SOCKS फिल्ड भएको ब्राउजर सजिलो अवस्था हो: त्यसलाई 127.0.0.1:1080 मा देखाउनुहोस्, सेटिङ भए टाढाको DNS सक्रिय गर्नुहोस्, र अनुरोध जान्छ। च्याट क्लाइन्ट, नक्सा एप वा त्यस्तो फिल्ड नभएको खेलसँग श्रोता प्रयोग गर्ने बाटो छैन, र SSH आदेशमा तपाईंले लेख्ने कुराले त्यो बदल्दैन।
अरू केही संलग्न गर्नुअघि, श्रोता फोनको आफ्नै शेलबाट SOCKS सिधै बोल्ने क्लाइन्टसँग चल्छ भनी प्रमाणित गर्नुहोस्:
ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me
फर्किने ठेगाना SSH सर्भरको हुनुपर्छ, फोनको होइन। यदि छ भने प्रोक्सीको आधा भाग सकियो र बाँकी काम कभरेजको हो। छैन भने पहिले SSH पक्ष सुधार्नुहोस्: कुञ्जी प्रमाणीकरण, सर्भरको गन्तव्यमा पुग्ने क्षमता र SSH सर्भरको आफ्नै निकास।
Android लाई चाहिने भाग थप्नुहोस्
प्रोक्सी सेटिङ नभएका एपलाई तिनका प्याकेट समातेर प्रोक्सी जडानमा बदल्ने कुरा चाहिन्छ। root नभएको यन्त्रमा त्यो VPN सेवा अनुकूलक हो: भर्चुअल इन्टरफेस लिएर छानिएको ट्राफिक स्थानीय SOCKS श्रोतामा पठाउने एप। शृंखला एप, अनुकूलक, SOCKS श्रोता, SSH जडान, गन्तव्य बन्छ।
अनुकूलक स्थापना गर्नुहोस्, त्यसलाई VPN अनुमति दिनुहोस् र त्यसले समात्नुपर्ने एप वा मार्ग छान्नुहोस्। स्टाटस बारको चाबी आइकनले त्यसपछि अनुकूलक जनाउँछ, छुट्टै व्यापारिक VPN होइन। Android ले प्रत्येक प्रयोगकर्ता प्रोफाइलका लागि एउटा मात्र सक्रिय VPN सेवा जडान अनुमति दिन्छ, त्यसैले दोस्रो VPN एप सुरु गर्दा शृंखलामा तह थपिँदैन: त्यो उही भूमिकाका लागि प्रतिस्पर्धा गर्छ।
यो त्यो चरण पनि हो जहाँ सफल परीक्षणले तपाईंलाई भ्रमित गर्न सक्छ। यदि अनुकूलकले तपाईंले पहिले नै प्रोक्सीमा देखाएको ब्राउजर मात्र समात्ने गरी सेट गरिएको छ भने सबै चल्छ र अरू केही ढाकिएको हुँदैन। यन्त्र टनेलमा छ भन्ने निष्कर्ष निकाल्नुअघि समात्ने सूची पढ्नुहोस्।
SSH यातायात समात्ने बाहिर राख्नुहोस्
SSH जडान आफैले पालना गर्ने SOCKS टनेलमा फर्केर जानु हुँदैन। यदि अनुकूलकले SSH एपको ट्राफिक समात्यो भने टनेल टनेलको प्रतीक्षा गर्ने जडानमा निर्भर हुन्छ, र परिणाम अनुकूलक सुरु हुनासाथ अड्किने वा असफल हुने लूप हो।
एकीकृत कार्यान्वयनले आफ्नै यातायात सकेट सुरक्षित राख्छन्। छुट्टै एपसँग समर्थित बहिष्करण चाहिन्छ: SSH एप समात्ने बाहिर राख्नुहोस्, वा ठेगानाद्वारा SSH अन्त्यबिन्दु बहिष्कृत गर्नुहोस्। दुवैको मूल्य छ। पूरै टर्मिनल एप बहिष्कृत गर्दा त्यसको असम्बन्धित सञ्जाल गतिविधि पनि टनेलबाट निस्कन्छ, र ठेगाना बहिष्करण सर्भरको ठेगाना बदलिँदा वा अर्को जडानमा नाम फरक तरिकाले हल हुँदा टुट्छ।
बहिष्करण बाहिरबाट जाँच्नुहोस्: अनुकूलक पुनः जोड्नुहोस्, त्यसपछि SSH सत्र टिक्छ र प्रोक्सी गरिएको अनुरोध अझै सर्भरको ठेगाना बताउँछ भनी पुष्टि गर्नुहोस्। अनुकूलक सुरु नहुँदासम्म चल्ने र त्यसपछि जम्ने सत्र त्यही लूप हो।
DNS र UDP लाई शृंखलाको अन्त्यसम्म पछ्याउनुहोस्
OpenSSH को गतिशील अग्रसारणले TCP जडान बोक्छ। त्यो UDP-associate वा ICMP यातायात होइन, र अनुकूलकले UDP प्याकेट स्वीकारेर UDP अग्रसारण बनाउन सक्दैन। UDP मा जोर दिने सबै, QUIC र WebRTC मिडिया सहित, एपअनुसार असफल हुन्छ वा TCP मा फर्किन्छ।
DNS लाई आफ्नै निर्णय चाहिन्छ। नाम स्थानीय रूपमा हल गर्ने एपले जोडिनुअघि सामान्य रिजोल्भरमार्फत प्रश्न पठाउँछ, त्यसैले टनेलले जडान बोक्छ तर खोज होइन। टाढाको DNS विकल्प भएको प्रोक्सी-सचेत क्लाइन्टले त्यो टार्छ; त्यो नभएको समातिएको एपले टार्दैन। अनुकूलकले बदल्यो भनी मान्नुको सट्टा कुन रिजोल्भरले जवाफ दियो जाँच्नुहोस्।
SOCKS श्रोतालाई loopback मा बाँधिएको राख्नुहोस्, पहिलो प्रयोगमा SSH सर्भरको host कुञ्जी प्रमाणित गर्नुहोस्, र अन्तिम साइटका लागि सामान्य HTTPS प्रमाणीकरण यथास्थान राख्नुहोस्। SSH ले फोन-देखि-सर्भर खण्ड सुरक्षित गर्छ; सर्भरले त्यसपछि गर्ने कुरा यसले इन्क्रिप्ट गर्दैन।
दुई जीवनचक्र जाँच्नुहोस् र निर्णय गर्नुहोस्
अनुकूलक र SSH सत्रका जीवनचक्र छुट्टाछुट्टै छन्। अनुकूलक समातिरहेको बेला SSH खस्यो भने एप स्पष्ट त्रुटिबिना अड्किन सक्छन्, किनकि तिनका प्याकेट अझै चल्ने निकास नभएको भर्चुअल इन्टरफेसमा प्रवेश गर्छन्। अनुकूलक रोकियो भने यन्त्रको VPN नीतिअनुसार एप सिधै जान्छन् वा अवरुद्ध हुन्छन्।
दुवै दिशा जानाजान जाँच्नुहोस्: अनुकूलक चलिरहेको बेला SSH सत्र मार्नुहोस्, त्यसपछि SSH माथि रहँदा अनुकूलक रोक्नुहोस्। प्रत्येक अवस्थामा फोनले गर्ने काम नै तपाईंले वास्तवमै लागू गरिरहेको नीति हो, स्थापना निर्देशनले जे भने पनि।
यदि कार्यप्रवाहलाई अनुमानयोग्य असफलता ढाँचासहित पूरै यन्त्रको कभरेज चाहिन्छ भने साँचो IP VPN, वा यो शृंखलाका लागि बनाइएको मर्मत गरिएको अनुकूलक, इमानदार उत्तर हो। असम्बन्धित समात्ने एपको छेउमा चलिरहन दिइएको शेल सत्र मर्मत गरिएको यन्त्र टनेल होइन; ती दुई घटक हुन् जसबीच एक सकिएपछि के हुन्छ भन्ने सहमति छैन।