strongSwan-এ পূর্ণ টানেলের জন্য দুই পাশেই 0.0.0.0/0 দরকার

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

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

ক্লায়েন্ট দূর পাশে যা সুরক্ষিত রাখতে চায় তা remote_ts হিসেবে বর্ণনা করে, আর সে যা পাঠায় সবই তার নিজের বরাদ্দ ঠিকানা থেকে উৎপন্ন হয়। ইন্টারনেট ট্রাফিকের জন্য সেই মানটিকে ব্যবহারকারীর প্রকৃতপক্ষে পৌঁছানো গন্তব্যগুলো কভার করতে হবে, যার মানে বাস্তবে সম্পূর্ণ IPv4 পরিসর। যে ক্লায়েন্ট এখনো একটি সাবনেট তালিকাভুক্ত করে, ইন্টারফেসে প্রোফাইলের নাম যা-ই হোক, সে একটি বিভক্ত টানেল চাইছে। উৎসের পাশ সাধারণত dynamic হয়, কারণ সংযোগের সময়েই ঠিকানা বরাদ্দ হয়। সেখানে লেখা স্থির উৎস পুল বদলালেই ভেঙে যায়।

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

এই খণ্ডটি সম্পূর্ণ সংযোগ ফাইল নয়, আর এটি ধরে নেয় প্রমাণীকরণ, পরিচয় ও ভার্চুয়াল ঠিকানা পুল ইতিমধ্যে কনফিগার করা আছে। ক্লায়েন্টের উৎস সিলেক্টর ও সার্ভারের বরাদ্দ করা ঠিকানা এখনো মিলতে হবে, নাহয় child SA এমন পরিধি নিয়ে উঠবে যা কোনো পক্ষই প্রত্যাশা করেনি। এটি swanctl --load-all দিয়ে লোড করুন এবং সফল ধরে নেওয়ার আগে আউটপুট পড়ুন। পার্স হওয়া একটি ফাইলও এমন সিলেক্টরের কারণে প্রত্যাখ্যাত হতে পারে যা পিয়ারের প্রস্তাবের সাথে ওভারল্যাপ করে না।

গেটওয়ের নিজের পাশের সিলেক্টর যাচাই করুন

গেটওয়ে একই ধারণা উল্টো দিক থেকে পড়ে। ইন্টারনেট গন্তব্যগুলো গেটওয়ের কাছে স্থানীয়, তাই তার local_ts হলো প্রশস্তটি আর remote_ts ক্লায়েন্ট পুল বর্ণনা করে। এই উল্টো অবস্থানই পূর্ণ-টানেল কনফিগারেশনে সবচেয়ে সাধারণ ভুল, আর এটি পর্যালোচনা পার করে কারণ দুই লাইনই আলাদাভাবে বিশ্বাসযোগ্য দেখায়।

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

পুরোনো ipsec.conf ভিন্ন কী দিয়ে বাঁ ও ডান ভূমিকা ব্যবহার করে, আর rightsubnet লাইনটি swanctl মানের সরাসরি প্রতিস্থাপন নয়। দুটি সিনট্যাক্স আলাদা ফাইলে রাখুন, একটিকে অন্যের মধ্যে পেস্ট না করে। একই ডিরেক্টরিতে মিশিয়ে দেওয়াই হলো সক্রিয় সংযোগ রিবুটের পর চুপচাপ আগের অবস্থায় ফিরে যাওয়ার উপায়।

ফাইল নয়, দর-কষাকষি করা child SA যাচাই করুন

সংরক্ষিত কনফিগারেশন অভিপ্রায় প্রমাণ করে, তার বেশি কিছু নয়। পিয়ার অনুরোধকৃত পরিধি সংকীর্ণ করতে পারে, আর নিচের ফাইল বদলেছে বলেই বিদ্যমান child SA প্রতিস্থাপিত হয় না। অন্য কিছু বদলানোর আগে প্রকৃতপক্ষে কী ইনস্টল হয়েছে তা নিশ্চিত করুন।

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

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

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

ফরওয়ার্ডিং ও ফেরত পথ যাচাই করুন

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

টানেল এখনো কী কভার করে না তা যাচাই করুন

সিলেক্টর জোড়া IPv4 কভার করে, আর কিছুই না। IPv6, DNS এবং যেকোনো অ্যাপ্লিকেশন-স্তরের নীতি আলাদা সিদ্ধান্ত, যা প্রশস্ত IPv4 সিলেক্টর চুপচাপ উপেক্ষা করে। প্রতিটি IPv4 প্যাকেট বহন করা টানেলও প্রতিটি নাম-অনুসন্ধান ফাঁস করতে পারে।

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

উপরের তালিকা থেকে দর-কষাকষি করা সিলেক্টরসহ ওই দুই কমান্ড দিয়ে শৃঙ্খলটি নিশ্চিত করুন। traceroute যদি স্থানীয় রাউটারকে প্রথম হপ দেখায়, সিলেক্টর যা-ই দাবি করুক, ট্রাফিক টানেল ব্যবহার করছে না। ইন্টারনেট অ্যাক্সেস তখনই সম্পূর্ণ যখন নির্বাচিত ট্রাফিক পরিকল্পিত গেটওয়ে দিয়ে গৃহীত, ফরওয়ার্ডকৃত ও ফেরত পাঠানো হয়। প্রোফাইলে 0.0.0.0/0 খুঁজে পাওয়া ওই শৃঙ্খলের প্রমাণ নয়, শুরু।