अपने SSH क्लाइंट के ज़रिए दूर के Pi को SOCKS प्रॉक्सी दें

दूरस्थ गतिक फ़ॉरवर्ड SOCKS श्रोता को Pi पर रखता है और आगे का कनेक्शन आपके लैपटॉप के स्वीकृत VPN पथ से करता है। दूसरे SSH सर्वर की ज़रूरत नहीं।

आप मान लेते हैं कि SOCKS प्रॉक्सी वहीं चलना चाहिए जहाँ नेटवर्क पहुँच पहले से मौजूद है। OpenSSH श्रोता को बिल्कुल कहीं और रख सकता है। दूरस्थ गतिक फ़ॉरवर्ड दूर के होस्ट पर SOCKS पोर्ट खोलता है और हर कनेक्शन आपके स्थानीय SSH क्लाइंट से शुरू करता है, जो आपके लैपटॉप का स्वीकृत VPN पथ ले जाता है। Pi को सीमित प्रॉक्सी मिलती है; वह आपकी टनल या आपके विशेषाधिकार विरासत में नहीं लेता.

श्रोता और जिस ओर से कनेक्शन शुरू होता है वह अलग हो सकते हैं

सामान्य ssh -D 1080 श्रोता को आपकी अपनी मशीन पर चलाता है और वहीं से कनेक्शन भेजता है। दूरस्थ गतिक फ़ॉरवर्ड इसे उलट देता है: श्रोता दूर के होस्ट पर दिखाई देता है, और वह जो भी कनेक्शन स्वीकार करता है वह स्थानीय ओर से खुलता है। OpenSSH क्लाइंट मैनुअल बिना किसी निश्चित गंतव्य के -R को ठीक इसी SOCKS4/5 व्यवस्था के रूप में दर्ज करता है।

लैपटॉप से एक समर्थित कमांड ऐसा दिखता है, जिसमें खाता, होस्ट और पोर्ट प्लेसहोल्डर माने गए हैं:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

वहाँ तीन ब्यौरे उपयोगी काम करते हैं। -S none सत्र को साझा नियंत्रण मास्टर से दूर रखता है, ExitOnForwardFailure आपको आधा खुला सत्र छोड़ने के बजाय जल्दी विफल होता है, और PermitRemoteOpen सीमित करता है कि दूर का श्रोता कहाँ तक पहुँच सकता है। कोई अधिकृत Pi खाता इस्तेमाल करें और इनमें से कुछ भी जोड़ने से पहले होस्ट कुंजी सत्यापित करें।

दूर का श्रोता वास्तव में क्या उजागर करता है

श्रोता पर भरोसा करने से पहले सर्वर की फ़ॉरवर्डिंग नीति जाँचें। GatewayPorts no के साथ दूरस्थ फ़ॉरवर्ड loopback से बँधा रहता है, और वही वह जोखिम है जो आप चाहते हैं। वाइल्डकार्ड फ़ॉरवर्डिंग थोपने के लिए कॉन्फ़िगर किया गया सर्वर वही पोर्ट हर इंटरफ़ेस पर प्रकाशित करता है, जिससे निजी प्रॉक्सी ऐसी चीज़ बन जाती है जिस तक स्थानीय नेटवर्क पहुँच सकता है।

loopback भी प्रति-उपयोगकर्ता सीमा नहीं है। Pi पर कोई दूसरी प्रक्रिया पोर्ट जानती हो तो 127.0.0.1:1080 से जुड़ सकती है, इसलिए Pi के स्थानीय खाते और उस पर चलने वाला सब कुछ आपके पहुँच-डिज़ाइन का हिस्सा हैं। यह गंतव्यों की सूची संकरी रखने का कारण है, नीति जाँच छोड़ने का कारण नहीं।

स्वीकृत गंतव्य को उसी ऐप्लिकेशन के लिए विशिष्ट रखें जिस तक आप पहुँचना चाहते हैं। किसी असंबंधित प्रोग्राम को चलाने के लिए उसे असीमित फ़ॉरवर्डिंग से बदलना उस समस्या से कहीं आगे पथ को चौड़ा कर देता है जिससे आपने शुरू किया था। गंतव्यों की सूची यह भी दर्ज करती है कि सत्र किसलिए था, जो आगे चलकर ऑडिट करने वाले की मदद करता है। इसे उस खाते के पास लिखें जिसे आपने इस्तेमाल किया।

एक ऐप्लिकेशन को प्रॉक्सी से भेजें

Pi पर प्रॉक्सी समझने वाला क्लाइंट तब अनुरोध कर सकता है। socks5h उपसर्ग गंतव्य का नाम प्रॉक्सी को सौंपता है, इसलिए खोज और कनेक्शन दोनों लैपटॉप की ओर होते हैं, और यह PermitRemoteOpen में नामित गंतव्य से मेल खाता है:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

सामान्य प्रमाणपत्र सत्यापन और ऐप्लिकेशन का अपना प्रमाणीकरण बनाए रखें। प्रॉक्सी बदलता है कि TCP कनेक्शन कहाँ बनता है; यह बिना प्रमाणीकरण की सेवा को सुरक्षित नहीं बनाता, और स्व-हस्ताक्षरित एंडपॉइंट को भरोसेमंद नहीं बनाता।

लैपटॉप को अब भी अपना मार्ग और SSH सर्वर तथा ऐप्लिकेशन दोनों के लिए रिज़ॉल्वर पहुँच चाहिए। उसके SSH क्लाइंट का ट्रैफ़िक स्वीकृत VPN नीति से चुना जाना चाहिए, और split-tunnel अपवाद उस ट्रैफ़िक को उस पथ से अलग भेज सकता है जिसे आपने जाँचा था।

पथ साबित करें और उसे बंद करें

पुष्टि करें कि श्रोता वहीं है जहाँ आप उम्मीद करते हैं और केवल इच्छित गंतव्य ही उत्तर देता है:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure साबित कर सकता है कि फ़ॉरवर्डिंग स्थापित हुई, और फिर भी यह प्रमाणित नहीं कर सकता कि ऐप्लिकेशन में लॉगिन आगे सफल होता है। ऐप्लिकेशन जाँचें, केवल पोर्ट नहीं। स्वीकार करके फिर हर अनुरोध विफल करने वाला श्रोता आमतौर पर बताता है कि गंतव्य का नाम या लैपटॉप का मार्ग गलत है, यह नहीं कि टनल विफल हुई।

यह व्यवस्था केवल TCP ले जाती है। UDP, ICMP और प्रॉक्सी सेटिंग अनदेखा करने वाले प्रोग्राम इससे बाहर रहते हैं, और फ़ॉरवर्डिंग उसी क्षण समाप्त होती है जब SSH सत्र समाप्त होता है। काम पूरा होने पर वह सत्र रोकें और ऐप्लिकेशन में जोड़ी गई प्रॉक्सी सेटिंग हटा दें।

स्थायी पहुँच के लिए इसके बजाय नेटवर्क मालिक का समर्थित नामांकन या प्रबंधित गेटवे इस्तेमाल करें। VPN के डिवाइस या संसाधन प्रतिबंधों से बचने के लिए रिवर्स प्रॉक्सी गलत औज़ार है; उनके भीतर इस्तेमाल किए जाने पर यह स्पष्ट सीमाओं वाला केवल एक अधिकृत ऐप्लिकेशन पथ है।

संबंधित लेख