अनुप्रयोगसँग SOCKS विकल्प छैन, तर यो छानिएको TCP ठेगानामा जोडिन सक्छ। स्थिर-लक्ष्य एडाप्टरले एउटा गन्तव्यका लागि SOCKS कुराकानी प्रदान गर्न सक्छ। यसले अर्को सामान्य फर्वार्ड प्रोक्सी बन्नु पर्दैन।

SOCKS4A प्रदान गर्ने socat बिल्डका लागि एउटा उदाहरणीय व्यवस्था यो हो:

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

SOCKS अन्तबिन्दु स्थानीय पोर्ट 1080 हो। एडाप्टर स्थानीय पोर्ट 9443 मा सुन्छ र त्यो अन्तबिन्दुसँग service.example.net:443 माग्छ। यी उदाहरण मान हुन्, पूर्ण सेवा परिनियोजन होइन।

एडाप्टरको एउटा स्थिर लक्ष्य छ

स्वीकार गरिएको हरेक TCP जडानले एउटै सेवा माग्छ। 9443 मा जोडिने अनुप्रयोगले आफ्ना सामान्य प्रोटोकल बाइट दिन्छ; socat ले SOCKS4A वार्ता दिन्छ। 9443 मा नयाँ HTTP CONNECT अनुरोध पठाउँदा अर्को गन्तव्य छानिँदैन—त्यसले ती बाइट स्थिर सेवातर्फ पठाउँछ।

SOCKS4A ले टाढाको समाधानका लागि SOCKS अन्तबिन्दुलाई होस्टनाम दिन्छ। यो ग्राहकले छानेको ठेगाना प्रयोग गर्ने SOCKS4 रूपभन्दा फरक छ। छानिएको अपस्ट्रिम—SOCKS4 प्रोक्सी सूचीबाट सार्वजनिक उम्मेदवार सहित—ले SOCKS4A होस्टनाम ह्यान्डलिङ र आवश्यक प्रमाणीकरण समर्थन गर्नुपर्छ; यो उदाहरण SOCKS5 पासवर्ड-लगइन विधि होइन।

स्थानीय रूपमा जोडिनुहोस्, साँचो सेवा पहिचान गर्नुहोस्

HTTPS URL लाई https://127.0.0.1:9443/ मा बदल्दा ग्राहकले TLS र HTTP का लागि प्रयोग गर्न सक्ने होस्टनाम बदलिन्छ। service.example.net का लागि प्रमाणपत्र loopback का लागि वैध प्रमाणपत्र हुँदैन।

जहाँ ग्राहकले छुट्टै जडान रुटिङ समर्थन गर्छ, त्यहाँ मूल URL को पहिचान राख्नुहोस्। Curl ले त्यो भिन्नता देखाउन सक्छ:

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

सकेट स्थानीय एडाप्टरतर्फ जान्छ जबकि TLS प्रमाणीकरण र HTTP गन्तव्य service.example.net नै रहन्छ। अरू अनुप्रयोगलाई आफ्नै समान समर्थित नियन्त्रण चाहिन्छ; हरेक ग्राहकले त्यो दिँदैन।

loopback बाइन्डले सञ्जाल जोखिम सीमित गर्छ, तर अरू योग्य स्थानीय प्रक्रियाहरूले अझै पुग्न सक्छन्। सेवाको आयु र प्रयोगकर्ता उपयुक्त राख्नुहोस्। loopback URL का कारण हुने पहिचान त्रुटि दबाउनुको सट्टा TLS प्रमाणीकरण राख्नुहोस्।

सम्बन्धित लेखहरू