curl socks5h बनाम socks5: होस्टनेम कौन हल करता है

लोग socks5h को socks5 जैसा ज़्यादा सहज वर्तनी वाला रूप मानते हैं, और अपेक्षा करते हैं कि दोनों वही अनुरोध उसी जगह भेजेंगे। अतिरिक्त अक्षर इसके बजाय DNS क्वेरी को स्थानांतरित करता है। जिस मशीन में रिज़ॉल्वर और प्रॉक्सी अलग नेटवर्क में होते हैं, वहाँ यह काम करने वाले और विफल होने वाले अनुरोध के बीच का अंतर है।

एक अक्षर, दो रिज़ॉल्वर

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

स्कीम में कुछ भी एन्क्रिप्शन या प्रमाणीकरण नहीं बदलता; केवल DNS पथ सरकता है। इसीलिए अक्षर को अनदेखा करना आसान और गलत करना महँगा है।

वही प्रॉक्सी, अलग अनुरोध

दोनों कॉल एक ही अक्षर से भिन्न हैं। बाकी सब कुछ समान है:

curl --proxy socks5://proxy.example:1080 https://service.example/
curl --proxy socks5h://proxy.example:1080 https://service.example/

The curl प्रॉक्सी संदर्भ इन स्कीमों को अलग-अलग दस्तावेज़ित करता है, और यही उन्हें उपनाम न मानने का प्रामाणिक कारण है। दोनों को किसी हानिरहित एंडपॉइंट के विरुद्ध चलाएँ जिसका उपयोग करने की आपको अनुमति है और अंतर पढ़ें। सफल दूरस्थ खोज अन्य अनुप्रयोगों के बारे में कुछ नहीं कहती, क्योंकि ब्राउज़र, पैकेज प्रबंधक और भाषा रनटाइम हर एक अपने लिए चुनते हैं।

प्रॉक्सी का अपना नाम स्थानीय रूप से हल होता है

उस आदेश में, proxy.example को कुछ और होने से पहले एक पता बनना पड़ता है, और वह खोज हमेशा स्थानीय होती है। service.example के रिज़ॉल्यूशन को प्रॉक्सी पर ले जाने से प्रॉक्सी के अपने नाम के लिए कुछ नहीं होता, जिसे अब भी ऐसा रिज़ॉल्वर चाहिए जो आपकी मशीन तक पहुँच सके। यहीं VPN तस्वीर बदलता है।

यदि प्रॉक्सी का नाम केवल सुरंग के अंदर हल होता है, तो कनेक्शन इस पर निर्भर करता है कि curl शुरू होने से पहले सुरंग चालू हो। तब कौन-सी स्कीम जीतेगी यह इस पर निर्भर है कि कौन-सा पक्ष उत्तर दे सकता है। जब आपकी मशीन गंतव्य हल नहीं कर सकती पर प्रॉक्सी कर सकता है, तो socks5 विफल होता है और socks5h सफल होता है। जब आपकी मशीन उसे सुरंग से होकर हल करती है और प्रॉक्सी नहीं कर सकता, तो socks5 काम करता है और socks5h विफल होता है।

स्कीम प्रॉक्सी से कनेक्शन को VPN के अंदर या बाहर नहीं रखती; रूटिंग तालिका ऐसा करती है, और स्कीम उसे कभी नहीं देखती। इसीलिए एक सुरंग एक ही मशीन पर एक स्कीम ठीक कर सकती है और दूसरी बिगाड़ सकती है। अक्षर केवल यह तय करता है कि प्रश्न कौन पूछता है।

हर पक्ष क्या हल कर सकता है

सार्वजनिक प्रॉक्सी ऐसा नाम हल नहीं कर सकता जो केवल कंपनी में मौजूद है, इसलिए उसे होस्टनेम भेजना प्रॉक्सी पर विफल होता है और स्थानीय DNS त्रुटि के बजाय प्रॉक्सी त्रुटि के रूप में सामने आता है। उसी निजी नेटवर्क के अंदर का प्रॉक्सी सामान्यतः ऐसे नाम हल कर सकता है, और यहीं socks5h अपना मूल्य सिद्ध करता है। रिज़ॉल्वर का स्थान उसी नीति से चुनें जो आपको वास्तव में चाहिए, क्योंकि दूरस्थ DNS अपने आप अधिक सक्षम नहीं होता और वह नाम किसी तीसरे पक्ष को सौंपता है। सार्वजनिक गंतव्य के लिए दोनों रूप काम करते हैं, इसलिए वही चुनें जो आपके अन्य उपकरण पहले से उपयोग करते हैं।

उस चयन को टिप्पणी में नहीं, रनबुक में लिखें, और क्रेडेंशियल को साझा इतिहास और नैदानिक आउटपुट से बाहर रखें। फिर एक बार में एक चर बदलें: वही गंतव्य, वही बाइनरी, वही रिज़ॉल्वर, एक अक्षर।

किस बाइनरी ने उत्तर दिया

एक ही मशीन पर दो curl बाइनरी संस्करण और बिल्ड सुविधाओं में भिन्न हो सकती हैं। Unix जैसे शेल में type -a curl पथ पर हर मिलान को सूचीबद्ध करता है और curl --version उसकी विशेषताएँ दिखाता है जो चलेगा। पथ में पहले आने वाली रैपर स्क्रिप्ट या उपनाम एक सामान्य कारण है कि परिणाम उस बाइनरी से मेल नहीं खाते जिसे आप परख रहे हैं।

असमर्थित स्कीम, नाम हल न कर पाने वाला प्रॉक्सी और अगम्य गंतव्य तीन अलग त्रुटियाँ हैं, इसलिए अक्षर बदलने से पहले संदेश पढ़ें। socks5h सिंटैक्स के बिना बिल्ड प्रॉक्सी स्ट्रिंग को असमर्थित बताता है, जो उस नाम के समान नहीं है जो हल नहीं हो सका। सिस्टम curl के बारे में एक पुरानी रिपोर्ट को हर प्लेटफ़ॉर्म के लिए स्थायी नियम न बनाएँ।