आपके VPN पर SOCKS प्रॉक्सी के रूप में SSH डायनामिक फ़ॉरवर्डिंग
जो ऐप केवल SOCKS बोलता है, उसके पास सामान्य VPN पर कोई प्रॉक्सी एंडपॉइंट नहीं होता। दो हॉप, एक लूपबैक श्रोता और एक नाम खोज जो SSH सर्वर को खुद करनी होती है।
जो ऐप केवल SOCKS बोलता है, उसके पास सामान्य VPN पर बात करने को कुछ नहीं होता, क्योंकि टनल पैकेट ले जाती है और ऐप को एक प्रॉक्सी एंडपॉइंट चाहिए। OpenSSH वह एंडपॉइंट तब दे सकता है जब एक्सेस का मालिक अनुमति दे, क्योंकि डायनामिक फ़ॉरवर्डिंग एक SSH सत्र को स्थानीय प्रॉक्सी बना देती है। उसके बाद दो हॉप अलग रखने होते हैं: वह टनल जो SSH होस्ट तक पहुँचती है, और वह कनेक्शन जो वह होस्ट आगे खोलता है। इन्हें अलग करने से दोनों बातें साफ़ होती हैं: यह व्यवस्था क्यों काम करती है और यह कभी क्या नहीं करेगी।
SSH श्रोता क्या बनता है और क्या नहीं
डायनामिक फ़ॉरवर्डिंग SSH क्लाइंट को स्थानीय रूप से सुनने और जो भी जुड़ता है उससे SOCKS4 या SOCKS5 बोलने पर मजबूर करती है। हर अनुरोध एक गंतव्य का नाम बताता है और SSH सर्वर आगे का कनेक्शन खोलता है, इसीलिए गंतव्य की खोज दूर की ओर हो सकती है। यह एप्लिकेशन-स्तर की TCP फ़ॉरवर्डिंग है, पूरे डिवाइस के लिए VPN नहीं। यह कोई UDP एसोसिएशन, कोई ICMP, और उन ऐप्स के लिए कुछ नहीं ले जाती जो प्रॉक्सी सेटिंग्स को पूरी तरह नज़रअंदाज़ करते हैं। SSH सर्वर से ऐप तक की हॉप भी आपकी टनल के अंदर नहीं है, जो तब मायने रखता है जब गंतव्य केवल ज्ञात नेटवर्क से ट्रैफ़िक स्वीकार करता है।
पूर्वापेक्षाएँ वास्तविक हैं: SSH होस्ट तक मार्ग, अधिकृत खाता, सत्यापित सर्वर होस्ट कुंजी और फ़ॉरवर्ड करने की अनुमति। इनमें से कोई भी प्रॉक्सी नहीं बनाती, और अंतिम आमतौर पर सबसे पहले गायब होती है। बाकी कुछ भी डिबग करने से पहले चारों की पुष्टि करें, क्योंकि क्लाइंट की ओर से विफलता एक जैसी दिखती है, चाहे कोई भी गायब हो।
इसे स्पष्ट पोर्ट के साथ लूपबैक पर शुरू करें
कोई अप्रयुक्त स्थानीय पोर्ट चुनें और पता छोड़ने के बजाय उसे स्पष्ट रूप से लूपबैक से बाँधें। नीचे के तीन विकल्पों में से हर एक एक कारण से मौजूद है।
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N दूर के कमांड को छोड़ देता है और -T स्यूडो-टर्मिनल को छोड़ देता है, इसलिए सत्र केवल फ़ॉरवर्ड करने के लिए है। ExitOnForwardFailure श्रोता न बन पाने पर क्लाइंट को बाहर निकाल देता है, आपकी माँगी फ़ॉरवर्डिंग के बिना चलने के बजाय। ControlPath=none सत्र को किसी मौजूदा मल्टीप्लेक्स कनेक्शन से बाहर रखता है जो अपनी फ़ॉरवर्डिंग जोड़ सकता है। लूपबैक श्रोता को LAN से बाहर रखता है, लेकिन साझा मशीन पर यह अनुमति की सीमा नहीं है, क्योंकि अन्य स्थानीय प्रक्रियाएँ भी उस तक पहुँच सकती हैं। OpenSSH क्लाइंट संदर्भ इन सभी फ़्लैग का दस्तावेज़ीकरण करता है, और लूपबैक चेतावनी इसी से निकलती है कि सुनता हुआ सॉकेट क्या होता है।
नाम प्रॉक्सी से होकर भेजें, उसके चारों ओर से नहीं
SOCKS5 क्लाइंट गंतव्य को स्वयं हल कर सकता है या प्रॉक्सी से ऐसा करने को कह सकता है, और यही चुनाव तय करता है कि कौन सा रिज़ॉल्वर उत्तर देता है। socks5h के साथ curl होस्टनाम प्रॉक्सी से होकर भेजता है, इसलिए खोज SSH सर्वर पर होती है। सादे socks5 के साथ लैपटॉप पहले हल करता है और केवल कनेक्शन जाता है, जो नाम आंतरिक होने पर उद्देश्य को चुपचाप विफल कर देता है। नीचे का अनुरोध नो-प्रॉक्सी सूची भी साफ़ करता है, इसलिए विरासत में मिला NO_PROXY मान उसे प्रॉक्सी के चारों ओर से नहीं ले जा सकता।
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthप्रमाणपत्र सत्यापन और ऐप का अपना लॉगिन अभी भी लागू होते हैं, क्योंकि प्रॉक्सी दोनों में से किसी को नहीं बदलती। दो खोजें बची रहती हैं: लैपटॉप को अनुमत VPN और DNS मार्ग से SSH होस्ट तक पहुँचना है, और SSH सर्वर को ऐप का नाम स्वयं हल करना है। दूसरी को कोई ट्रैफ़िक प्रॉक्सी से गुज़रने से पहले अलग से जाँचा जा सकता है।
ssh [email protected] getent hosts app.corp.exampleएक अनुमत गंतव्य सिद्ध करें, फिर सत्र बंद करें
ऐसा गंतव्य जाँचें जिसे नीति अनुमति देती है और वह भी जिसे उसे अस्वीकार करना चाहिए, क्योंकि काम करती फ़ॉरवर्डिंग केवल यह सिद्ध करती है कि श्रोता काम करता है, और कुछ नहीं। ऐप वह स्रोत पता देखता है जो SSH सर्वर चुनता है, और वह आपके लैपटॉप का टनल पता नहीं है। जहाँ दूर का सिरा कनेक्शन स्रोत के अनुसार लॉग करता है, वहाँ अनुरोध अस्वीकार होने पर पहली जाँच यही अंतर होती है।
सत्र को उसकी मालिक प्रक्रिया से रोकें, किसी असंबंधित शेल को मारकर नहीं। फिर पुष्टि करें कि श्रोता गया, क्योंकि अब भी उत्तर देता पोर्ट वह सत्र है जिसे आपने वास्तव में बंद नहीं किया। केवल वही प्रॉक्सी सेटिंग हटाएँ जो इस अभ्यास ने जोड़ी, और ऐप कॉन्फ़िगरेशन का बाकी हिस्सा अछूता रहने दें। फ़ॉरवर्डिंग नियम रखता एक बिना निगरानी वाला टर्मिनल सेवा नहीं है, और स्थायी प्रॉक्सी को स्वीकृत जीवनचक्र चाहिए, भूली हुई विंडो नहीं।
ss -ltn | grep 1080वे विफलताएँ जिन्हें यह व्यवस्था ठीक नहीं कर सकती
कुछ लक्षण सीधे ऊपर की सीमाओं की ओर इशारा करते हैं, और उन्हें जल्दी पहचानना प्रॉक्सी डिबगिंग की एक दोपहर बचाता है। तालिका आप जो देखते हैं उसे उससे जोड़ती है जो इसका सामान्य अर्थ होता है। अंतिम स्तंभ में जो भी है वह डिज़ाइन का सवाल है, कॉन्फ़िगरेशन की गलती नहीं।
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
पहली तीन पंक्तियाँ वही हैं जिनका लोग गलत निदान करते हैं, क्योंकि हर एक प्रॉक्सी के बारे में त्रुटि के बजाय कनेक्शन का प्रयास पैदा करती है। लैपटॉप पर हल होता नाम सर्वर के रिज़ॉल्वर के बारे में कुछ नहीं कहता, और विफलता को इसके बजाय प्रमाणपत्र या समय-समाप्ति की समस्या के रूप में पढ़ा जाता है। केवल UDP वाले ऐप डिज़ाइन के बाहर रहते हैं, उसके अंदर टूटे हुए नहीं, और कोई अतिरिक्त ssh विकल्प इसे नहीं बदलता। ब्राउज़र की पंक्ति यह सामान्य याद दिलाती है कि प्रॉक्सी सेटिंग्स हर ऐप के लिए अलग होती हैं। अंतिम पंक्ति ही कारण है कि बंद करने की जाँच मौजूद है: अब भी सुनता पोर्ट इसका अर्थ है कि अब कुछ और उसका मालिक है।