विद्यमान HTTP प्रॉक्सीकडे SSH स्थानिक फॉरवर्ड: दोन loopback पत्ते

तुमची मंजूर प्रॉक्सी जंप होस्टवर चालते जिथे ती फक्त loopback वर ऐकते, त्यामुळे त्या मशीनबाहेरून काहीही तिच्यापर्यंत पोहोचू शकत नाही। तुम्हाला VPN किंवा नवीन प्रॉक्सी आवश्यक नाही; तुम्हाला त्या मशीनचा एक पोर्ट तुमच्या एका पोर्टपर्यंत न्यायचा आहे। स्थानिक फॉरवर्ड नेमके तेच करते, आणि त्यासाठी एक आदेश आणि अनुप्रयोगाची एक सेटिंग लागते। गोंधळ सहसा कोणता loopback पत्ता कोणत्या मशीनचा आहे हे मिसळल्यामुळे होतो।

निश्चित प्रॉक्सी आधीपासून आहे का ते ठरवा

हे तंत्र आधीच चालू असलेल्या सेवेला फॉरवर्ड करते। जर दूरस्थ होस्टवर फक्त SSH डीमन असेल आणि प्रॉक्सी नसेल, तर कितीही फॉरवर्ड केले तरी ती तयार होणार नाही, आणि कनेक्शन दूरस्थ बाजूने नाकारले जाईल। प्रॉक्सी बद्ध आहे का, तिचा पोर्ट कोणता आहे, आणि ती 127.0.0.1 वर ऐकते की विशिष्ट इंटरफेस पत्त्यावर, याची खात्री करा, कारण फॉरवर्डने त्याच पत्त्याला लक्ष्य करायचे आहे।

हे आधी खात्री केल्यास कधीच कोणत्याही गोष्टीशी जोडले न गेलेल्या बोगद्याचे डीबगिंग टळते।

फॉरवर्ड तयार करा आणि आदेश वाचा

तुम्हाला हवा असलेला प्रकार तुमच्या लॅपटॉपवर एक loopback पोर्ट बांधतो आणि सर्व्हरच्या बाजूने त्याला प्रॉक्सीच्या पत्त्याशी जोडतो, जसा सर्व्हर तो पाहतो।

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N दूरस्थ आदेश दाबते आणि -T termios वाटप दाबते, कारण तुम्हाला शेल नाही तर बोगदा हवा आहे। पहिला loopback पत्ता म्हणजे लॅपटॉप जिथे ऐकतो ते ठिकाण; दुसरा SSH सर्व्हर सोडवतो, त्यामुळे तिथला 127.0.0.1 म्हणजे त्या मशीनवरील प्रॉक्सी। ExitOnForwardFailure स्थानिक पोर्ट आधीच घेतलेला असल्यास काहीही फॉरवर्ड न करणारे सत्र सुरू करण्याऐवजी आदेश मोठ्याने अयशस्वी करते। लक्ष्य पत्ता सर्व्हर जसा सोडवतो तसा लिहा, कारण फक्त तुमचा लॅपटॉप सोडवू शकणारे नाव पलीकडे अयशस्वी होईल।

यापैकी काहीही काम करण्यापूर्वी सर्व्हरचे स्वतःचे धोरण लागू होते। AllowTcpForwarding ने ते परवानगी द्यायला हवी, आणि PermitOpen सत्र कोणत्या गंतव्यांपर्यंत आणि पोर्टपर्यंत पोहोचू शकते हे मर्यादित करू शकते, त्यामुळे क्लायंट स्वीकारणारे फॉरवर्ड सर्व्हर तरीही नाकारू शकतो। नकार क्लायंटवर फॉरवर्ड किंवा चॅनेल त्रुटी म्हणून दिसतो, आणि तो संदेश वाचणे आदेश संपादित करण्यापेक्षा वेगवान आहे।

एक अनुप्रयोग फॉरवर्डकडे वळवा

अनुप्रयोगाला http://127.0.0.1:13128 वर HTTP प्रॉक्सी वापरण्यासाठी संरचीत करा, दूरस्थ प्रॉक्सी मागत असल्यास ओळखपत्रांसह। HTTPS गंतव्यांसाठी अनुप्रयोगाची स्वतःची प्रमाणपत्र पडताळणी ठेवा, कारण प्रॉक्सी बोगदा ती बदलत नाही। हे एका सेवेचे निश्चित फॉरवर्ड आहे, त्यामुळे अनुप्रयोगाला प्रॉक्सीबद्दल सांगायला हवे, त्याला स्वतः शोधू देऊ नये।

कोणतेही कायमस्वरूपी संरचन करण्यापूर्वी एक झटपट तपासणी: curl -x http://127.0.0.1:13128 -I https://example.com, जे प्रॉक्सीने समर्थित असावे अशा HTTP CONNECT पद्धतीचा सराव करते।

अधिकार जिथे होता तिथेच ठेवा

दूरस्थ प्रॉक्सी अजूनही कोणती गंतव्ये आणि पद्धतींना परवानगी देते हे ठरवते, आणि SSH लॉगिनने प्रत्येक खात्याला गुपचूप सामान्य वेब रिले देऊ नये। लॅपटॉपवर 127.0.0.1 वर बांधल्याने पोर्ट तुमच्या स्थानिक नेटवर्कवर प्रकाशित होणे टळते, आणि त्यामुळे पोर्ट त्याच मशीनवरील इतर प्रक्रियांपासून खाजगी होत नाही। ते बंधन प्रॉक्सी सामायिक करण्यासाठी wildcard पत्त्याने बदलणे हाच अनियंत्रित खुले रिले तयार होण्याचा मार्ग आहे।

SSH वाहतूक सर्व्हरपर्यंतच्या उडीचे रक्षण करते। त्या बिंदूपुढे प्रॉक्सी स्वतःचे कनेक्शन उघडते, त्यामुळे गंतव्याकडे जाणारी साधी HTTP विनंती सर्व्हरपुढेही साधी राहते, जरी पहिला भाग एन्क्रिप्ट केलेला होता।

दोन्ही टोके पडताळा, नंतर साफसफाई करा

स्थानिक बोगद्याची मांडणी आणि दूरस्थ सेवेचे यश वेगवेगळे निकाल आहेत, आणि आदेशाची निर्गम स्थिती तुम्हाला फक्त पहिल्याबद्दल सांगते। ss -ltn सह ऐकणारा अस्तित्वात आहे का ते तपासा, नंतर एक परवानगी असलेली अनुप्रयोग विनंती आणि प्रॉक्सीने नाकारावी अशी विनंती करा। दोन्ही अपेक्षेप्रमाणे वागल्यास मार्ग खरा आहे; बोगदा सुरू असून प्रत्येक विनंती अयशस्वी झाल्यास प्रॉक्सी नाकारत आहे किंवा गंतव्यापर्यंत पोहोचू शकत नाही।

पूर्ण झाल्यावर, तिला धारण करणारी SSH प्रक्रिया थांबवा, अनुप्रयोगातून प्रॉक्सी सेटिंग काढा, आणि कामापेक्षा जास्त जगणारा ऐकणारा सोडण्याऐवजी स्थानिक पोर्ट गेला आहे याची खात्री करा।