तुमच्या 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 पर्याय ते बदलत नाही। ब्राउझरची ओळ प्रॉक्सी सेटिंग्ज प्रत्येक अॅपसाठी वेगळ्या असतात हे सांगणारी नेहमीची आठवण आहे। शेवटची ओळ बंद करण्याची तपासणी का आहे हे सांगते: अजूनही ऐकणारा पोर्ट म्हणजे आता दुसरे काहीतरी त्याचे मालक आहे।