ProxyChains क्या पकड़ता है और क्या छोड़ देता है

ProxyChains-NG कोई टनल नहीं बनाता। यह जिस एक प्रोग्राम को शुरू करता है उसके भीतर नेटवर्क से जुड़े libc कॉल बदलने वाली लाइब्रेरी पहले से लोड करता है, इसलिए सीमा किसी प्रक्रिया में एक कॉल है, पूरे डिवाइस का रूट नहीं। यही अंतर तय करता है कि सफल परीक्षण वास्तव में क्या साबित करता है। शृंखला से होकर काम करता curl एक ही पकड़े गए कॉल की पुष्टि करता है, यह नहीं कि नाम-हल, UDP या हर चाइल्ड प्रक्रिया ने वही रास्ता लिया। नीचे की मार्गदर्शिका तीन चरणों में कवरेज जाँचती है और फिर सूची देती है कि हुक कहाँ तक नहीं पहुँच सकता।

प्रीलोड किसी कनेक्शन तक कैसे पहुँचता है

शुरू होते समय लॉन्चर libproxychains को LD_PRELOAD में रखता है और फिर लक्ष्य प्रोग्राम चलाता है। लाइब्रेरी असली libc प्रतीकों को हल करती है और connect तथा getaddrinfo जैसे फ़ंक्शनों के अपने संस्करण बदल देती है। उन प्रतीकों से गुज़रने वाले कॉल कॉन्फ़िगरेशन फ़ाइल के SOCKS या HTTP प्रॉक्सी पर फिर से लिखे जाते हैं। दूसरा रास्ता लेने वाले कॉल कभी हुक से नहीं मिलते, इसीलिए गारंटी हर कॉल के लिए है, पूरी मशीन के लिए नहीं।

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

पुष्टि करें कि लाइब्रेरी उस प्रक्रिया में लोड है

अनुरोध शुरू करें और उसे शुरू करने वाले शेल के बजाय जीवित प्रक्रिया का निरीक्षण करें। maps फ़ाइल वह हर साझा ऑब्जेक्ट दिखाती है जो इस समय प्रक्रिया में मैप है।

proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps

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

प्रक्रिया से बाहर जाने वाले कनेक्शनों का पता लगाएँ

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

strace -f -e trace=connect -o /tmp/pc.trace proxychains4 -q curl -sS https://example.com/ -o /dev/null
grep -o "sin_port=htons([0-9]*)" /tmp/pc.trace | sort -u

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

तय करें कि हुक क्या कवर नहीं कर सकता

proxychains-ng परियोजना पुनर्निर्देशन को TCP तक सीमित रखती है और चेतावनी देती है कि स्क्रिप्ट, पृष्ठभूमि प्रक्रियाएँ और लोड किए गए मॉड्यूल मुख्य प्रोग्राम से अलग व्यवहार कर सकते हैं। UDP और ICMP इस तंत्र से बाहर हैं, इसलिए उन पर निर्भर हर चीज़ को अपना समर्थित पथ चाहिए। DNS proxy_dns सेटिंग और अनुप्रयोग के अपने रिज़ॉल्वर व्यवहार का पालन करता है, यानी एक सफल HTTPS अनुरोध नाम-हल के बारे में आपको कुछ नहीं बताता। प्रमाणपत्र सत्यापन को भी उसकी जगह रखें: प्रॉक्सी के ज़रिए सर्वर तक पहुँचना पहचान जाँच बंद करने का कारण नहीं है।

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