IPsec ট্রাফিক সিলেক্টর: তারা কী ঢাকে আর কী ঢাকে না

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

দুই প্রান্ত থেকেই পড়ুন

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

মানগুলো সবসময় একক সাবনেট নয়। IKEv2 সিলেক্টর ঠিকানা-রেঞ্জ, প্রোটোকল নম্বর ও পোর্ট-রেঞ্জ বহন করতে পারে, আর এভাবেই একটি নীতি পুরো নেটওয়ার্কের বদলে একটি সার্ভিস রক্ষা করে। অভীষ্ট ট্রাফিকের চেয়ে সংকীর্ণ সিলেক্টর এমন টানেল তৈরি করে যা কিছু গন্তব্য বহন করে আর বাকিগুলোকে নীরবে বাদ দেয়।

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

সংকোচন রেসপন্ডারের সিদ্ধান্ত

ইনিশিয়েটর প্রস্তাব দেয়, আর রেসপন্ডার শুধু একটি উপসেট গ্রহণ করতে পারে। IKEv2 রেসপন্ডারকে প্রস্তাবিত ট্রাফিক সিলেক্টর সংকুচিত করার অনুমতি দেয়, এবং সংকুচিত ফলাফলই বাস্তবে ইনস্টল হয়। তাই ইনিশিয়েটিং কনফিগারেশন পড়া মানে একটি প্রস্তাব পড়া, চুক্তি নয়।

সেজন্যই ক্লায়েন্টে যোগ করা একটি সাবনেট কাজ করা টানেল তৈরি করেও নতুন গন্তব্য প্রত্যাখ্যান করতে পারে। সার্ভার প্রস্তাবটি নিজের নীতি যতটা অনুমতি দেয় ততটা সংকুচিত করেছে, অথচ ক্লায়েন্টের ফাইলে এখনো বিস্তৃত রেঞ্জ লেখা আছে। কেবল দর-কষাকষি করা অবস্থাই সত্য দেখায়: Linux-এ ip xfrm policy এবং strongSwan-এর IKEv2 ডকুমেন্টেশনে child SA তালিকা যা চাওয়া হয়েছিল তা নয়, যা ইনস্টল হয়েছে তা জানায়। দুটি যখন দ্বিমত করে, তখন রেসপন্ডারের নীতিই বদলাতে হবে।

প্রত্যাখ্যান করা প্রস্তাব সংকুচিত প্রস্তাবের চেয়ে আলাদা লক্ষণ। প্রত্যাখ্যান দর-কষাকষির লগে দেখা যায় এবং কোনো child অ্যাসোসিয়েশনই রাখে না।

একটি গন্তব্য শুরু থেকে শেষ পর্যন্ত অনুসরণ করুন

ক্লায়েন্ট যে সোর্স ঠিকানা ব্যবহার করবে তা সহ একটি বাস্তব গন্তব্য বেছে নিন, তারপর সেই জোড়াটিকে তিনটি স্বতন্ত্র সিদ্ধান্তের মধ্য দিয়ে অনুসরণ করুন। রুট একটি পথ বেছে নেয়, সিলেক্টর ঠিক করে সেই পথ সুরক্ষিত কি না, আর ফায়ারওয়াল ঠিক করে প্যাকেটটি অনুমোদিত কি না। প্রত্যেকে নিজে নিজে ব্যর্থ হতে পারে, আর বিস্তৃত সিলেক্টর বাকিগুলোর কোনোটিই সারায় না।

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

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

অ্যাপ্লিকেশন এখনো ব্যর্থ হওয়া সত্ত্বেও child কাউন্টার নড়লে সমস্যাটি টানেলের ওপাশে। এতে তদন্ত সিলেক্টরের বদলে দূরের হোস্টের লিসেনার বা ফায়ারওয়ালের দিকে সরে যায়।

দুই লক্ষ্য আলাদা রাখুন

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

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