প্রিফিক্স সরানোর পরও proxychains থেকে যায়

আপনি একটি কমান্ড থেকে proxychains সরিয়ে আবার চালান, তবুও র‍্যাপারের শুরুর বার্তা দেখতে পান। অ্যাপ্লিকেশন সেটিং খোঁজার আগে লঞ্চ এনভায়রনমেন্ট পরীক্ষা করুন।

লিনাক্সে LD_PRELOAD ডাইনামিক লিংকারকে সাধারণ লাইব্রেরির আগে নির্দিষ্ট শেয়ার্ড অবজেক্ট লোড করতে বলে। প্রক্সি র‍্যাপারগুলি সমর্থিত নেটওয়ার্ক কল আটকাতে এই প্রক্রিয়া ব্যবহার করতে পারে। কেউ যদি শেলে ভেরিয়েবলটি এক্সপোর্ট করে, তবে পরবর্তী চাইল্ড প্রোগ্রামগুলি তা উত্তরাধিকারসূত্রে পেতে পারে, যদিও তাদের কমান্ড লাইনে কোনো র‍্যাপার প্রিফিক্স না থাকে।

সেই শেলে প্রথম শুধু-পড়ার পরীক্ষা হলো:

printf '%s\n' "$LD_PRELOAD"

প্রক্সি র‍্যাপার লাইব্রেরি খুঁজুন, তবে ভেরিয়েবলটি অন্য ইচ্ছাকৃতভাবে লোড করা লাইব্রেরিও তালিকাভুক্ত করতে পারে—এই সম্ভাবনা রাখুন। সব এন্ট্রি অন্ধভাবে মুছে ফেলা অন্য কোনো টুল ব্যাহত করতে পারে।

লঞ্চার বদলান, তারপর প্রোগ্রামটি আবার চালান

আক্রান্ত প্রোগ্রাম চালু করে এমন এনভায়রনমেন্ট থেকে দুর্ঘটনাবশত প্রক্সি প্রিলোড সরান। কোনো স্টার্টআপ ফাইল বা লঞ্চার এটি এক্সপোর্ট করলে সেই উৎসও সংশোধন করুন। Bash লঞ্চের জন্য স্টার্টআপ ফাইলের ক্রম অনুসরণ করুন। পরিষ্কার শেলের নতুন চাইল্ড আর পুরোনো টার্মিনাল বা IDE-এর চাইল্ড—যা এখনও ভেরিয়েবলটি ধরে রাখে—আলাদা বিষয়।

এনভায়রনমেন্ট ভেরিয়েবল আনসেট করলে ইতিমধ্যে শুরু হওয়া প্রসেস থেকে লাইব্রেরি আনলোড হয় না। তাই চলমান অ্যাপ্লিকেশন সংশোধিত লঞ্চ পথে পুনরায় চালু না হওয়া পর্যন্ত র‍্যাপারটি ধরে রাখতে পারে।

ভেরিয়েবলটি অনুপস্থিত থাকলে /etc/ld.so.preload-এর মতো অন্য কনফিগার করা প্রিলোড উৎস এবং প্রকৃত লঞ্চার পরীক্ষা করুন। এই প্রক্রিয়ার সীমা আছে: স্ট্যাটিক এক্সিকিউটেবল, সরাসরি সিস্টেম কল এবং সিকিউর-এক্সিকিউশন বিধিনিষেধ ভিন্নভাবে আচরণ করতে পারে। sudo-এর সাথে র‍্যাপারের ক্রম গুরুত্বপূর্ণ। উত্তরাধিকারসূত্রে পাওয়া প্রিলোড অপ্রত্যাশিত আটকানো ব্যাখ্যা করে; এটি প্রমাণ নয় যে সব ধরনের নেটওয়ার্ক ট্রাফিক প্রক্সি ব্যবহার করে।