नीति राउटिंग बनाम SOCKS: कौन सी परत वास्तव में ट्रैफ़िक को प्रॉक्सी करती है

आपने एक नीति रूट जोड़ा जो VPN क्लाइंट का ट्रैफ़िक उस होस्ट पर भेजता है जहाँ पोर्ट 1080 पर SOCKS श्रोता चलता है। पैकेट आते हैं, श्रोता कुछ दर्ज नहीं करता, और कनेक्शन अटक जाता है। रूट में कुछ गलत नहीं है: अगला हॉप चुनता है कि पैकेट कहाँ जाएगा, और SOCKS एक बातचीत है जिसे क्लाइंट को शुरू करना होता है। उन तीन आर्किटेक्चरों की तुलना करें जिन्हें लोग प्रॉक्सी से ट्रैफ़िक भेजने से आम तौर पर मतलब रखते हैं, और स्पष्ट हो जाएगा कि आपके सेटअप में कौन सा हिस्सा गायब है।

राउटिंग, DNAT और SOCKS अलग-अलग चीज़ें बदलते हैं

नीति रूट परत 3 के निर्णय को फिर से लिखता है। एक क्लाइंट के ट्रैफ़िक को चुने गए अगले हॉप पर भेजने के लिए दो पंक्तियाँ पर्याप्त हैं:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

इसके बाद कर्नेल पैकेट को 10.50.0.2 को सौंपता है, जबकि मूल गंतव्य अभी भी IP हेडर में रहता है। यदि 10.50.0.2 राउटर है, तो वह पैकेट आगे भेजता है। यदि वह 1080 पर SOCKS डेमॉन वाला होस्ट है, तो पैकेट ऐसी किसी चीज़ को संबोधित नहीं है जो उसे स्वीकार कर सके, और पोर्ट 1080 पर DNAT भी मदद नहीं करता, क्योंकि रूपांतरित पैकेट अभी भी SOCKS अभिवादन के बजाय मूल एप्लिकेशन पेलोड ले जाता है।

SOCKS5 एक संस्करण बाइट, विधियों की सूची, प्रमाणीकरण की अदला-बदली और गंतव्य का नाम लेने वाले अनुरोध से शुरू होता है। वह एप्लिकेशन डेटा है। कोई राउटिंग प्रविष्टि या netfilter लक्ष्य उसे उत्पन्न नहीं करता, और एक पंक्ति में तुलना यही है: राउटिंग एक पथ चुनता है, SOCKS सर्वर से दूसरा कनेक्शन बनाने को कहता है।

पहला मामला: एप्लिकेशन स्वयं SOCKS बोल सकता है

जब प्रोग्राम में प्रॉक्सी सेटिंग होती है, तो यह सबसे छोटा रास्ता है और इसमें कर्नेल में कोई बदलाव नहीं चाहिए। इसे श्रोता की ओर इंगित करें, यदि सर्वर माँगे तो क्रेडेंशियल दें, और तय करें कि नाम स्थानीय रूप से हल होंगे या प्रॉक्सी को भेजे जाएँगे। curl में ये अलग-अलग फ़्लैग हैं, और अंतर तब मायने रखता है जब गंतव्य केवल प्रॉक्सी की ओर से हल होता है:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

जो एप्लिकेशन प्रॉक्सी पर्यावरण चरों को अनदेखा करते हैं, या कच्चे सॉकेट खोलते हैं, उनकी इस तरह मदद नहीं की जा सकती। ब्राउज़र और अधिकांश HTTP उपकरण ठीक हैं; गेम क्लाइंट, मेल डेमॉन या किसी विक्रेता की मनमानी बाइनरी आम तौर पर नहीं। सीमा हर एप्लिकेशन और हर प्रोटोकॉल के लिए है, इसलिए यह विकल्प परीक्षण के लिए उत्कृष्ट और पूरे VPN के उत्तर के रूप में कमज़ोर है।

दूसरा मामला: एक अडैप्टर जो IP प्रवाहों को प्रॉक्सी सत्रों में बदलता है

जो प्रोग्राम SOCKS नहीं बोल सकते, उनके लिए रूपांतरण ऐसी किसी चीज़ में होना चाहिए जो IP ट्रैफ़िक समाप्त करे और उनकी ओर से प्रॉक्सी सत्र खोले। वह घटक एक टनल इंटरफ़ेस रखता है, नीति राउटिंग द्वारा चुने गए प्रवाहों को स्वीकार करता है, हर एक के लिए SOCKS हैंडशेक करता है और उत्तरों को फिर से बनाता है। रूट ट्रैफ़िक को उसकी ओर भेजता है; अडैप्टर ही सत्र बनाता है।

पूरे सबनेट को इसके भरोसे छोड़ने से पहले इसका दस्तावेज़ पढ़ें। कई अडैप्टर TCP अच्छी तरह ले जाते हैं और UDP को केवल SOCKS5 UDP एसोसिएशन के ज़रिये संभालते हैं, और उनमें से कोई ICMP को प्रॉक्सी ट्रैफ़िक में नहीं बदलता, इसलिए सफल ping प्रॉक्सी पथ के बारे में कुछ नहीं कहता। DNS दूसरा जाल है: यदि अडैप्टर नाम स्थानीय रूप से हल करता है, तो केवल-आंतरिक रिकॉर्ड गलत उत्तर में, या बिल्कुल कुछ नहीं में हल होते हैं।

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

तीसरा मामला: होस्ट वास्तव में राउटेड गेटवे है

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

तीनों मामले जल्दी अलग हो जाते हैं। जाँचें कि वास्तव में कौन सुन रहा है, फिर होस्ट तक पहुँचने वाले पहले बाइट देखें:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

असली SOCKS क्लाइंट का पहला पेलोड बाइट 0x05 है, अभिवादन में संस्करण। यदि कैप्चर इसके बजाय मूल एप्लिकेशन डेटा दिखाता है, तो कोई SOCKS डेमॉन उत्तर नहीं देगा, क्योंकि बातचीत कभी शुरू ही नहीं हुई। यदि 1080 पर कुछ भी नहीं सुन रहा है, तो होस्ट गेटवे है, और सवाल यह हो जाता है कि क्या वह आगे भेजता है और क्या वापसी पथ मौजूद है।

चार प्रश्नों से परत चुनें

क्या प्रोग्राम में प्रॉक्सी सेटिंग है? उसका उपयोग करें और वहीं रुकें। क्या ट्रैफ़िक में ऐसा UDP या ICMP है जिसे बचना है? केवल राउटेड या NAT गेटवे ICMP ले जाता है, और UDP को ऐसा SOCKS5 एसोसिएशन चाहिए जिसे दोनों सिरे समर्थन दें। क्या मशीन के हर प्रक्रिया को कवर करना है, उन सहित जिन्हें आप कॉन्फ़िगर नहीं कर सकते? तब आपको ऐसा अडैप्टर चाहिए जो इंटरफ़ेस रखे और प्रवाह समाप्त करे। क्या आप उसका राउटिंग, DNS और लूप-रोक अपवाद भी संभाल सकते हैं? यदि नहीं, तो सादा गेटवे चलाने में कम खर्चीला होगा।

एक भेद सीधा रखना चाहिए। VPN क्लाइंट का अपना socks-proxy विकल्प बताता है कि बाहरी टनल कनेक्शन अपने सर्वर तक कैसे पहुँचता है, और भीतरी क्लाइंट प्रवाहों के रूपांतरण के बारे में कुछ नहीं कहता। दोनों को एक ही टिकट में लगातार मिला दिया जाता है। रूट को छूने से पहले तय करें कि आपको कौन सा संबंध चाहिए।