socat SOCKS ब्रिज: साइटचे TLS होस्टनाव जपून ठेवा

ॲपमध्ये 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 पडताळणी ठेवा.