Linux VPN-এর উত্তর হারিয়ে যাচ্ছে? rp_filter ও রুট পরীক্ষা করুন

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

সোর্স যাচাই কী নির্ধারণ করে

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

গুরুত্বপূর্ণ শব্দটি হলো যুক্তিসঙ্গত। প্যাকেট সম্পূর্ণ বৈধ হয়েও যাচাইয়ে ব্যর্থ হতে পারে, কারণ এখানে বৈধতা যাচাই হচ্ছে না।

কার্যকর মোড পড়ুন, একটি ফিল্ড নয়

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

তৃতীয় লাইনের রুট লুকআপটাই মানুষ এড়িয়ে যায়। এটি বলে কার্নেল সোর্স সম্পর্কে কী ভাবে, আর সেটাই যাচাইয়ের ইনপুট।

যাচাই বদলানোর আগে অমিলটি খুঁজুন

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

বিপরীত রুট যদি কেবল অনুপস্থিত থাকে, তবে তা যোগ করা যাচাই বন্ধ করার বদলে কারণটাই ঠিক করে। অনুপস্থিত রুট, ফায়ারওয়াল প্রত্যাখ্যান আর ভুল ট্র্যাফিক সিলেক্টর—সবগুলো একই দৃশ্যমান উপসর্গ তৈরি করে, আর তার মধ্যে কেবল একটি সোর্স যাচাই সম্পর্কে।

প্রথম প্রতিক্রিয়া হিসেবে সোর্স যাচাই বৈশ্বিকভাবে বন্ধ করবেন না। এটি একটি নির্দিষ্ট রোগনির্ণয়ের বদলে বিস্তৃত আচরণ পরিবর্তন ডেকে আনে, যা পরে আপনাকে মনে রাখতে হবে।

একটি বাছাই করা সমন্বয় যা আপনি সমর্থন করতে পারেন

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

এমন একটি ঘটনা রাখুন যা এখনও প্রত্যাখ্যাত হওয়া উচিত। সেই ঘটনা যদি এখন সফল হয়, তবে সমন্বয়টি আপনি যে একটিমাত্র পথ সারাতে চেয়েছিলেন তার চেয়ে বেশি দুর্বল করে দিয়েছে।

IPv4 ও IPv6 আলাদা রাখুন

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

মোড, ইন্টারফেস, রুট লুকআপের ফলাফল এবং পরিবর্তনের কারণ এক জায়গায় লিখে রাখুন। পরের ব্যক্তি সেটিংটি পাবেন কিন্তু কোনো ব্যাখ্যা পাবেন না, আর তিনি হয় এটি সরিয়ে দেবেন, নয়তো এমন জায়গায় কপি করবেন যেখানে এটি থাকার কথা নয়।