SSH मार्फत अवस्थित HTTP वा SOCKS प्रोक्सीमा पुग्नुहोस्
SSH मार्फत टाढाको loopback HTTP वा SOCKS प्रोक्सीमा यसको श्रोतालाई सार्वजनिक रूपमा नखोली पुग्नुहोस्।
यदि relay.example.net पहिले नै आफ्नो 127.0.0.1:1080 मा SOCKS चलाइरहेको छ भने, त्यो श्रोतालाई सार्वजनिक रूपमा नखोली पहुँच अगाडि पठाउनुहोस्:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| अन्तिम बिन्दु | भूमिका |
|---|---|
ल्यापटप 127.0.0.1:1081 | ल्यापटपको एपमा कन्फिगर गर्नुपर्ने SOCKS ठेगाना। |
रिले 127.0.0.1:1080 | SSH सर्भरको तर्फबाट पुगिने अवस्थित प्रोक्सी। |
स्थानीय फर्वार्डिङ सिन्ट्याक्स ले निश्चित गन्तव्यलाई सर्भरतर्फ तोक्छ। टाढाको loopback पोर्ट 3128 मा HTTP प्रोक्सी वा proxy.internal.example:8080 जस्तो इन्ट्रानेट अन्तिम बिन्दुले पनि त्यही सिद्धान्तमा काम गर्छ। क्लाइन्टलाई त्यो अवस्थित HTTP प्रोटोकल र खाताका लागि कन्फिगर गर्नुहोस्; SSH मार्फत लैजाँदा SOCKS वा TLS-सक्षम HTTPS श्रोता बन्दैन।
अवस्थित सेवाले अझै समर्थित प्रोटोकल संस्करण, प्रमाणीकरण, गन्तव्य र अन्तिम निकास छान्छ। यदि अर्को SSH प्रक्रियाले त्यो टाढाको प्रोक्सी बनाएको छ भने, दुवै प्रक्रिया जीवित रहनुपर्छ। ल्यापटप→रिले→गेटवे मार्गले वेबसाइटलाई अन्तिम बाहिरी जडान देखाउँछ, स्थानीय पोर्ट 1081 ले तोकेको पहिचान होइन।
ल्यापटपको बाइन्डिङ स्पष्ट रूपमा स्थानीय राख्नुहोस्। फराकिलो खुलासाले सेवामा को पुग्न सक्छ भन्ने बदल्छ, र SSH लगइनले श्रोतामा SOCKS पासवर्ड थप्दैन। अस्वीकार भएमा ल्यापटप श्रोता, SSH यातायात र टाढाको प्रोक्सीलाई छुट्टाछुट्टै चरणका रूपमा जाँच्नुहोस्।