অ্যাপটি ইন্টারফেসে বাঁধা? এর VPN পথ ডিফল্ট নয়

মেশিনের একটি অ্যাপ্লিকেশন VPN দিয়ে বেরোয়, আরেকটি বেরোয় না, অথচ দুই ব্যবহারকারীই শপথ করে বলেন তারা কিছুই বদলাননি। পার্থক্যটি প্রায়ই অ্যাপ্লিকেশন নিজেই নেওয়া একটি বাঁধাইয়ের সিদ্ধান্ত: ডিভাইসে বাঁধা সকেট, সংযোগের আগে বেছে নেওয়া সোর্স ঠিকানা, বা নিজের রাউটিং টেবিলসহ একটি namespace। প্রত্যেকটি বদলে দেয় কোন পথ প্রযোজ্য হবে, এবং এর কোনোটিই ব্রাউজারের সাধারণ IP পরীক্ষায় দেখা যায় না।

তিন রকম বাঁধাই, তিন রকম ফল

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

নেটওয়ার্ক namespace হলো তৃতীয় ঘটনা। এর নিজের ইন্টারফেস ও রাউটিং টেবিল আছে, তাই ভিতরের অ্যাপ্লিকেশন হোস্টের ডিফল্ট দ্বারা একেবারেই প্রভাবিত হয় না। তিনটিকেই একই জিনিস ভাবলে আত্মবিশ্বাসী ব্যাখ্যা তৈরি হয়, যা প্রথম পরীক্ষাতেই টিকে না।

অ্যাপটি আসলে কী সেট করে তা নির্ধারণ করুন

রুটে হাত দেওয়ার আগে অ্যাপ্লিকেশনের নেটওয়ার্কিং কনফিগারেশন বা তার নথিভুক্ত আচরণ পড়ুন। যদি এটি ইন্টারফেসের পছন্দ, সোর্স ঠিকানার ঘর বা namespace-এর অপশন দেয়, তাহলে সেই সেটিংই প্রথম দেখার জিনিস। যদি না দেয়, বাঁধাইটি ভেতরের হতে পারে এবং কেবল ট্রেসিং বা নিজের ডায়াগনস্টিকসে দেখা যায়।

Linux-এ SO_BINDTODEVICE-এর মতো সকেট অপশনের নথিভুক্ত পরিধি ও অনুমতির প্রয়োজন আছে, এবং অনধিকারপ্রাপ্ত প্রসেস সেগুলো একেবারেই সেট করতে নাও পারে। এই সীমাবদ্ধতা দরকারি সূত্র: অপশনটি প্রয়োগ করা না গেলে সম্ভবত অ্যাপ্লিকেশনই পার্থক্যের উৎস নয়।

পলিসি রাউটিং সোর্স পড়ে

যখন পলিসি রাউটিং কনফিগার করা থাকে, একটি নিয়ম প্যাকেটের সোর্স অনুযায়ী টেবিল বাছতে পারে। তাই যে সকেট সোর্স ঠিকানা বাঁধে, সেটি এমন নিয়ম অনুসরণ করতে পারে যা ডিফল্ট পথ স্পর্শই করে না, যদিও কোনো ইন্টারফেস স্পষ্টভাবে নাম দেওয়া হয়নি।

অ্যাপ্লিকেশন যে অ্যাড্রেস ফ্যামিলি, সোর্স ও namespace ব্যবহার করে, ঠিক সেইগুলো দিয়েই অনুসন্ধানটি পুনরুৎপাদন করুন। হোস্ট namespace-এর শেল থেকে সাধারণ রুট অনুসন্ধান ভিন্ন প্রশ্নের উত্তর দেয়, আর এই অমিলই কার্যকর রুটকে ভাঙা দেখানোর সবচেয়ে সাধারণ কারণ।

স্প্লিট টানেলিং ও সহায়ক প্রসেস

প্রতি-অ্যাপ স্প্লিট টানেলিং আরেকটি স্তর যোগ করে। ক্লায়েন্ট অ্যাপ্লিকেশনের প্যাকেজ বা প্রসেস মেলাতে পারে, আর নিজের সকেট খোলে এমন সহায়ক আলাদা বিষয়। একটি লঞ্চার ও তার ব্যাকগ্রাউন্ড সার্ভিস একই দৃশ্যমান নামের অধীনে ভিন্ন সংযোগ তৈরি করতে পারে।

স্প্লিট-টানেল নিয়মটি আসলে যে প্রসেস সংযোগ করে তাকে ঢেকে রাখে কি না দেখুন। অ্যাপ যদি নির্দিষ্ট ইন্টারফেসে বাঁধে আর VPN ক্লায়েন্ট প্যাকেজ অনুযায়ী মেলায়, দুটি সিদ্ধান্ত কোনোটি ভুল না হয়েও বিরোধী হতে পারে।

অ্যাপের নিজের পথ পরীক্ষা করুন

প্রতিটি পরিবর্তনের পরে অ্যাপ্লিকেশন থেকে নতুন অনুরোধ চালান। আপনি যে প্রস্থান চেয়েছিলেন তা দেখানো ব্রাউজার অন্য ইন্টারফেসে বাঁধা অন্য প্রোগ্রামের জন্য সমতুল্য প্রমাণ নয়, আর ক্যাশে করা সংযোগ সেটিং বদলানোর অনেক পরে পুরনো পথ ব্যবহার করে চলতে পারে। নতুন নিয়ম বিচার করার আগে পুরনো সেশন বন্ধ করুন। নইলে পরীক্ষাটি অতীত মাপে।

Linux সকেট রেফারেন্স SO_BINDTODEVICE ও তার প্রয়োজনীয়তা নথিভুক্ত করে। আগে অ্যাপ্লিকেশনের নিজের কনফিগারেশন পড়ুন, একই প্রসঙ্গে অনুসন্ধানটি পুনরুৎপাদন করুন, তারপরেই ঠিক করুন রুট না বাঁধাই বদলানো দরকার।