Android SSH SOCKS प्रॉक्सी: आपके आधे ऐप्स ही क्यों कनेक्ट होते हैं

आप 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 सर्वर की होस्ट कुंजी सत्यापित करें, और अंतिम साइट के लिए सामान्य HTTPS सत्यापन जगह पर छोड़ें। SSH फ़ोन-से-सर्वर हिस्से की रक्षा करता है; यह उस चीज़ को एन्क्रिप्ट नहीं करता जो सर्वर बाद में करता है।

दो जीवनकाल जाँचें और निर्णय लें

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

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

अगर कार्यप्रवाह को पूर्वानुमेय विफलता मोड के साथ पूरे डिवाइस की कवरेज चाहिए, तो असली IP VPN, या इस श्रृंखला के लिए बनाया गया अनुरक्षित अडैप्टर, ईमानदार उत्तर है। किसी असंबंधित कैप्चर ऐप के पास चलता छोड़ा गया शेल सत्र अनुरक्षित डिवाइस टनल नहीं है; वे दो घटक हैं जिनके बीच इस पर कोई सहमति नहीं कि उनमें से एक खत्म होने पर क्या होता है।