কেন IPsec নিরাপত্তা নীতি রাউট টেবিলের একটি এন্ট্রি নয়

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

টেবিল দিয়ে নয়, লুকআপ দিয়ে শুরু করুন

কার্নেলকে জিজ্ঞাসা করুন সে সত্যিই কী করবে: ip route get 10.20.0.5 নির্বাচিত রাউট, বহির্গামী ইন্টারফেস ও যে সোর্স ঠিকানা ব্যবহার করবে তা দেখায়। একটি প্রিফিক্স, নীতির নিয়ম, মার্ক বা পছন্দের সোর্স—সবই সেই উত্তর বদলে দিতে পারে, তাই জীবন্ত লুকআপ চোখে টেবিল পড়ার চেয়ে ভালো।

সুরক্ষিত পরিসরের ভেতরের একটি গন্তব্য পরীক্ষা করুন, গেটওয়ে ঠিকানা নয়। ওপারের গেটওয়েতে পৌঁছানো কেবল প্রমাণ করে কোনো একটি রাউট আছে; আপনার আসলে যে সাবনেট দরকার তা নিয়ে এটি কিছুই বলে না। তারপর নিশ্চিত করুন লুকআপ যে ইন্টারফেস বেছেছে সেটিই আপনার প্রত্যাশিত, যেটি টানেলের ব্যবহার করা উচিত।

দুই পাশেই সিলেক্টর মিলিয়ে নিন

নীতি ডেটাবেসের নিজস্ব এন্ট্রি থাকে, আর প্রতিটি একটি দিক, সোর্স, গন্তব্য ও প্রোটোকল নামায়, তারপর বলে মিলে যাওয়া প্যাকেটের কী হওয়া উচিত। সেগুলো তালিকাভুক্ত করতে ip xfrm policy ব্যবহার করুন; ফ্ল্যাগ দেখায় কাজটি সুরক্ষা, বাইপাস নাকি ব্লক। যে নীতির সিলেক্টর আপনার পরীক্ষার প্রবাহের চেয়ে চওড়া বা সরু তা মিলবে না, আর প্যাকেটটি অসুরক্ষিত অবস্থায় বেরিয়ে যায়। আপনি যে ত্রুটি খুঁজছেন সেটিই এটা, অনুপস্থিত রাউট নয়।

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

নীতির মিল মানে ইনস্টল করা অবস্থা নয়

মিলে যাওয়া নীতি কেবল বলে প্যাকেটটি সুরক্ষিত হতে হবে; সুরক্ষা করতে কার্নেলের এখনো একটি নিরাপত্তা অ্যাসোসিয়েশন দরকার। ip xfrm state দিয়ে সেগুলো তালিকাভুক্ত করুন, বা strongSwan দরপত্র চালালে swanctl --list-sas দিয়ে, আর প্রতিটি এন্ট্রির সিলেক্টর ও কাউন্টার পড়ুন।

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

রাউট-ভিত্তিক টানেলের এখনো যা দরকার

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

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

কিছু সম্পাদনার আগে মালিকানা ঠিক করুন

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

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