VPN ঠিকানায় বাঁধা অ্যাপ্লিকেশনও ভুল রুট ব্যবহার করে

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

এই রানবুকের বাকি অংশ হলো আমি যে ক্রমে যাচাই করি, প্রতিটি পর্যবেক্ষণ দেওয়া কমান্ডসহ।

বাইন্ড আসলে কী ঠিক করে

বাইন্ড সকেটকে একটি লোকাল ঠিকানা দেয়। এরপর কার্নেল আগের মতোই একই রুট লুকআপ চালায়, যদি না কোনো নীতি নিয়ম ওই লুকআপ কোন টেবিল পড়বে তা বদলে দেয়।

তাই প্যাকেট ভৌত ইন্টারফেসে VPN সোর্স ঠিকানা নিয়ে বেরিয়ে যেতে পারে। ওপাশে এটি এমন একটি প্রাইভেট রেঞ্জ থেকে আসে যা নেটওয়ার্ক ওই পথে প্রত্যাশা করেনি, ফেরত ট্রাফিকের ফিরে যাওয়ার রুট থাকে না, এবং সংযোগ আটকে যায় বা রিসেট হয়।

Linux IP সকেট রেফারেন্স বাইন্ডের অর্থ লিখিতভাবে দেয়। রাউটিং-এর অংশটি থাকে ip-rule ও ip-route-এ, এবং এগুলো আলাদা ম্যানুয়াল হওয়ার কারণ আছে।

নিশ্চিত করুন ঠিকানাটি এই নেমস্পেসের

যে ঠিকানায় আপনি বাঁধতে পারবেন তা অ্যাপ্লিকেশন যে নেটওয়ার্ক নেমস্পেসে চলে তার ভেতরের কোনো ইন্টারফেসে থাকতে হবে। পিয়ার ঠিকানা, গেটওয়ে ঠিকানা, বা কেবল অন্য নেমস্পেসে থাকা ঠিকানায় বাঁধা যায় না, এবং কলটি EADDRNOTAVAIL দিয়ে ব্যর্থ হয়।

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

এই তিনটি অ্যাপ্লিকেশনের মতো একই প্রসঙ্গে চালান: একই নেমস্পেস, এবং সম্ভব হলে একই ব্যবহারকারী। পুরোনো net30 চিত্র বর্তমান টপোলজি ক্লায়েন্টকে কোন ঠিকানা দিয়েছে তার প্রমাণ নয়। যে ইন্টারফেস সত্যিই আপ আছে সেটিই পড়ুন।

ওই সোর্স ও গন্তব্যের লুকআপ পড়ুন

একটি কমান্ডই সেই প্রশ্নের উত্তর দেয় যা বাইন্ড দেয়নি:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

এরপর ip rule show বলে দেয় কোনো নিয়ম অন্য টেবিল বাছত কি না। এখানে অগ্রাধিকার গুরুত্বপূর্ণ, কারণ প্রথম মিলে যাওয়া নিয়মই জেতে, আর আপনার নিয়মের উপরে থাকা একটি সর্বগ্রাহী নিয়ম আপনার নিয়মকে অদৃশ্য করে দেয়।

নীতি নিয়ম বসান কেবল যদি সেটাই নকশা হয়

সোর্স-ভিত্তিক রাউটিং একটি সচেতন নকশা, এক অ্যাপ্লিকেশনের জন্য মেরামত নয়। নীতি-মালিক চাইলে যে টানেল সাবনেটের ট্রাফিক টানেল ব্যবহার করবে, নিয়মটি তাঁর কনফিগারেশনে থাকা উচিত, আপনার ল্যাপটপে এককালীন কমান্ডে নয়।

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del ও ip route flush table 100 দিয়ে ফিরিয়ে নিন। এভাবে যোগ করা সব কিছু রিবুটে হারিয়ে যায়, যদি না কোনো ম্যানেজার তা লেখে; এটি একদিকে নিরাপত্তার বৈশিষ্ট্য, অন্যদিকে একমাত্র কপিটি আপনার শেল হিস্টোরিতে না রাখার কারণ।

তিনটি পর্যবেক্ষণ দিয়ে যাচাই করুন

অ্যাপ্লিকেশন যে সোর্স চেয়েছিল, লুকআপ যে রুট বেছেছিল, এবং সার্ভার যে সোর্স সত্যিই দেখেছে — তিনটিই লিখে রাখুন।

এই তিনটি ভিন্ন হতে পারে, এবং প্রতিটি ভিন্নতা অন্য জায়গায় ইশারা করে। টানেল ইন্টারফেসে ক্যাপচার প্রমাণ করে প্যাকেট সঠিক সোর্স নিয়ে বেরিয়েছে। ভৌত ইন্টারফেসে ক্যাপচার প্রমাণ করে এটি ভুল পথে বেরিয়েছে। সার্ভার-পক্ষের দৃশ্যই একমাত্র যা পথটি শুরু থেকে শেষ পর্যন্ত প্রমাণ করে।

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