नीति राउटिङ बनाम 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 छ? ICMP लाई राउट गरिएको वा NAT गेटवेले मात्र बोक्छ, र UDP लाई दुवै छेउले समर्थन गर्ने SOCKS5 सङ्घ चाहिन्छ। मेसिनका हरेक प्रक्रिया, तपाईं कन्फिगर गर्न नसक्नेहरू सहित, ढाक्नुपर्छ? त्यसो भए इन्टरफेसको मालिक हुने र प्रवाह अन्त्य गर्ने एडाप्टर चाहिन्छ। तपाईंले यसको राउटिङ, DNS र लुप-रोकथाम अपवाद पनि लिन सक्नुहुन्छ? नसकेमा साधारण गेटवे चलाउन कम खर्चिलो हुनेछ।

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