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 দূর থেকে সমাধান হয়েছিল কি না তা লিখে রাখুন; ওই চারটি তথ্যই যাচাই করা পরিধি আর আশাভরসার পরিধির মধ্যে পার্থক্য।