কেন একটি OpenVPN রুট strongSwan XFRM নীতির কাছে হেরে যায়

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

দুটি সিদ্ধান্ত, একটি নয়

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

প্রশস্ত IPsec সিলেক্টরই সাধারণ কারণ। যে নীতি 172.16.0.0/12 রক্ষা করে তা 172.20.8.0/24-ও কভার করে, যেখানে প্রশাসক হয়তো OpenVPN টানেল দিয়ে পৌঁছাতে চান। উদ্দেশ্যটি কেবল রাউটিং টেবিলে আছে, এবং নীতি ডেটাবেস তা কখনো জানেনি।

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

কার্নেল আসলে যে রুট বেছে নেয় তা পড়ুন

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

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

শেষ কমান্ডটিই আসল, কারণ এটি বাছাই করা রুটের সঙ্গে কার্নেল যে সোর্স ঠিকানা ব্যবহার করত তা দেখায়। এই আউটপুটটি IPsec নীতি যে সিলেক্টরের সঙ্গে মেলে তার সঙ্গে তুলনা করুন। যখন রুটটি OpenVPN ইন্টারফেসের দিকে এবং নীতিটি এখনো একই জোড়ার সঙ্গে মেলে, তখন আপনি অনুমান ছাড়াই সংঘাতটি পুনরুৎপাদন করেছেন।

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

যে নীতিও প্রযোজ্য তা পড়ুন

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

ip -s xfrm policy
swanctl --list-sas

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

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

উভয় পথ বৈধ হলে তিনটি বিকল্প

প্রশস্ত প্রিফিক্স সুবিধা ছিল, প্রয়োজন নয়—এমন ক্ষেত্রে IPsec সিলেক্টর সংকুচিত করাই সবচেয়ে পরিচ্ছন্ন বিকল্প। রিমোট ট্রাফিক সিলেক্টরকে সত্যিই IPsec-এর পেছনে থাকা সাবনেটে কমিয়ে দিলে একসঙ্গে প্রতিটি হোস্টের জন্য সংঘাত দূর হয়, এবং এর খরচ একটি রিকি, নতুন উপাদান নয়।

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

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

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

বাকিটা দুর্বল না করে ব্যতিক্রমটি প্রমাণ করুন

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

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