সাধারণ একটি Linux অ্যাপ TUN স্পর্শ না করেই VPN ব্যবহার করে

প্রতিষ্ঠিত Linux VPN ব্যবহার করা একটি ব্রাউজার /dev/net/tun খোলে না। এটি একটি সকেট খোলে, আর কার্নেল ঠিক করে ওই সকেটের প্যাকেট কোন ইন্টারফেস দিয়ে বেরোবে। টানেল তৈরি করা প্রসেসটি যে প্রসেসের ট্রাফিক বহন করছে তার থেকে আলাদা কাজ করছে। এই দুটি ভূমিকা আলাদা রাখলে বেশিরভাগ অনুমতির প্রশ্ন জিজ্ঞাসা করার আগেই উত্তর পাওয়া যায়।

সকেট থেকে টানেল পর্যন্ত একটি প্যাকেট অনুসরণ করুন

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

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

দুই অর্ধেক একবার আঁকুন, অনুমতির প্রশ্ন বসানো সহজ হয়ে যাবে। উপরের অর্ধেক অ্যাপ্লিকেশনের জগৎ, নিচের অর্ধেক ডেমনের।

কার ডিভাইস দরকার এবং কার নয় তা ঠিক করুন

TUN ইন্টারফেস তৈরি করা বা তাতে যুক্ত হওয়া ডিভাইসে অ্যাক্সেস এবং অতিরিক্ত তা কনফিগার করার সক্ষমতা দরকার, তাই সমর্থিত VPN সেবা নেটওয়ার্ক প্রশাসনের ক্ষমতা নিয়ে শুরু হয় বা বিশেষাধিকারপ্রাপ্ত হেল্পার ব্যবহার করে। এই প্রয়োজনটি ডেমনের। এটি ব্রাউজার, ডেটাবেস ক্লায়েন্ট বা ফাইল স্থানান্তর টুল সম্পর্কে কিছুই বলে না। যে সেবার এই সক্ষমতা দরকার, তার নিজের সেটআপ ধাপের জন্য দরকার, গ্রাহকদের জন্য নয়।

রুট ও নীতি প্রস্তুত হলে সাধারণ একটি প্রসেস তার স্বাভাবিক সকেট কলে প্রাপ্ত পথ ব্যবহার করে। এর ডিভাইস নোড দরকার নেই, root-ও দরকার নেই।

ডিভাইসের অনুমতি বদলানো কোনো অ্যাপ্লিকেশনকে গন্তব্যে অ্যাক্সেস দেওয়ার উপায় নয়। এটি কেবল ডিভাইসের সীমা অন্য জায়গায় সরায়।

অ্যাপ্লিকেশনটি আসলে কোন নেমস্পেসে চলছে তা যাচাই করুন

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

ip netns list ও ip -n NAME route দিয়ে, অথবা প্রসেসের নেমস্পেস লিংক দেখে যাচাই করুন। উত্তর সাধারণত একটি কমান্ডেই দেখা যায়।

একই হোস্টের দুই ব্যবহারকারীকেও নীতি দিয়ে আলাদা পথ দেওয়া যায়। এটি নেটওয়ার্কের সিদ্ধান্ত, ডিভাইসের মালিকানার প্রমাণ নয়।

ক্ষমতাকে নেটওয়ার্ক নীতি থেকে আলাদা করুন

কিছু টুলের সকেটের চেয়ে বেশি দরকার। প্যাকেট ক্যাপচারের জন্য কাঁচা সকেট দরকার, আর রুট বদলানোর জন্য প্রশাসনিক ক্ষমতা দরকার। এগুলো আলাদা অনুমোদনসহ আলাদা কাজ, আর একটির অনুমোদনকে VPN ব্যবহারের সার্বজনীন শর্ত হিসেবে পড়া উচিত নয়।

নিজের টানেল তৈরি করা প্রোগ্রাম তৃতীয় ঘটনা। এটি সত্যিই TUN খোলে, কারণ এটি ডেমনের ভূমিকা নিচ্ছে, তাই এর ডেমনের বিশেষাধিকার দরকার।

বিশেষাধিকারের নাম দেওয়ার আগে কাজটির নাম দিন। দুটোকে আলাদা করা সাধারণত যতটা কঠিন মনে হয় ততটা নয়।

দুই অ্যাকাউন্ট দিয়ে বিভাজনটি যাচাই করুন

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

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