धोरण राउटिंग विरुद्ध 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 पर्याय बाह्य टनेल कनेक्शन त्याच्या सर्व्हरपर्यंत कसे पोहोचते हे वर्णन करतो, आणि आंतरिक क्लायंट प्रवाहांच्या रूपांतराबद्दल काहीही सांगत नाही। दोन्ही एकाच तिकिटात सतत गोंधळले जातात। मार्गाला हात लावण्यापूर्वी तुम्हाला कोणते नाते हवे आहे ते ठरवा।