strongSwan ট্র্যাপ মোড: IPsec টানেল কেন ট্রাফিকের জন্য অপেক্ষা করে
নিষ্ক্রিয় অন-ডিমান্ড IPsec টানেল কোনো প্যাকেট তার ট্র্যাপ নীতির সঙ্গে মিলে না যাওয়া পর্যন্ত CHILD SA দেখায় না। অবস্থা পড়ুন, ট্রিগার যাচাই করুন এবং কখন start উপযুক্ত তা জানুন।
স্ট্যাটাস আউটপুটে কোনো CHILD SA দেখা যায় না, টানেলটি মৃত মনে হয়, তারপর দূরের সাবনেটে একটি ping তা তুলে আনে। অন-ডিমান্ড IPsec সেটআপে এই ক্রমটাই নকশা, কোনো ত্রুটি নয়। একটি ট্র্যাপ নীতি একটি সিলেক্টর ইনস্টল করে অপেক্ষা করে, আর যে প্রথম প্যাকেট তার সঙ্গে মেলে সেটাই IKE ও CHILD SA আলোচনা শুরু করে।
বিভ্রান্তির একটা অংশ শব্দভাণ্ডারে: “up” দুটি ভিন্ন অবস্থার জন্য ব্যবহৃত হয়। কনফিগারেশন লোড হয়েছে এবং কার্নেল নীতি বিদ্যমান, কিন্তু ডেটা অ্যাসোসিয়েশন নেই। যে মনিটর কেবল সক্রিয় SA গোনে সে একটি সুস্থ সাইটকে ডাউন দেখাবে, যতক্ষণ কেউ সেখানে ট্রাফিক না পাঠায়।
নিষ্ক্রিয় অন-ডিমান্ড টানেলের দেখানোর মতো কোনো CHILD SA নেই
একটি ট্র্যাপ এন্ট্রি নিজে নিজে কিছু প্রমাণ করে না। এটি কার্নেলকে নির্বাচিত ট্রাফিকের জন্য একটি নীতি ধরে রাখতে এবং প্যাকেটের সেই নীতি দরকার হলে একটি acquisition তুলতে বলে। ডেমন acquisition পায়, সেটি child সংজ্ঞার সঙ্গে মেলায় এবং সেখান থেকে আলোচনা করে। সেই সময় পর্যন্ত দেখানোর মতো IKE SA-ও থাকে না, তাই দুটি তালিকা একসঙ্গে খালি হতে পারে।
এই ক্রমটাই লগগুলোকে পাঠযোগ্য করে। আগে acquisition আসে, তারপর IKE_SA_INIT ও IKE_AUTH, তারপর CHILD SA। লগ যদি acquisition-এর ঠিক পরেই শেষ হয়, তবে ট্রিগার কাজ করেছে। আলোচনা ব্যর্থ হয়েছে, আর পরের প্রশ্নটি ট্র্যাপ নয়, বরং ক্রেডেনশিয়াল, প্রস্তাব বা পৌঁছানোর ক্ষমতা নিয়ে।
Linux কার্নেল ব্যাকএন্ডে আপনি যেকোনো SA তৈরির আগেই নীতিটি দেখতে পারেন। চালান ip xfrm policy এবং out দিকের ও সংযোগে নির্দেশ করা টেমপ্লেটযুক্ত সিলেক্টরটি খুঁজুন। সেই এন্ট্রিই অন-ডিমান্ড অবস্থা, আর তার উপস্থিতি প্রথমেই নিশ্চিত করার বিষয়।
start_action ঠিক করে কিছু আদৌ অপেক্ষা করবে কি না
প্রতিটি child-এর swanctl.conf ফাইলে start_action. start কনফিগারেশন লোড হওয়ার সময় শুরু করে, trap নীতিটি ইনস্টল করে অপেক্ষা করে, এবং none শুরু করার দায়িত্ব অন্য কিছুকে দেয়। কেবল trap উপরে বর্ণিত ping-এ-ওঠে এমন আচরণ তৈরি করে।
children {
office-lan {
local_ts = 192.168.50.0/24
remote_ts = 192.168.70.0/24
start_action = trap
}
}
দুটি ট্রাফিক সিলেক্টর ঠিক করে কী আগ্রহের বিষয়, আর সেই প্রিফিক্সগুলোর বাইরের হোস্ট থেকে আসা প্যাকেট ট্র্যাপ নিক্ষেপ করে না; সেটি স্বাভাবিকভাবেই রাউট হয়। ট্রিগারকে আরও আগ্রহী করতে সিলেক্টর প্রশস্ত করলে টানেল যে পরিধি সুরক্ষার দাবি করে সেটিও প্রশস্ত হয়, তাই আপনি সত্যিই যেসব ট্রাফিক এনক্রিপ্ট করতে চান তা থেকেই এগুলো নিন।
এখানে swanctl.conf রেফারেন্স গ্রহণযোগ্য মানগুলো তালিকাভুক্ত করে, সঙ্গে আলাদা close ও DPD অ্যাকশন, যেগুলো SA তৈরির পরে কী হয় তা নিয়ন্ত্রণ করে।
ট্রিগার আদৌ কাজ করেছে কি না বের করুন
শুরু করুন swanctl --list-conns দিয়ে এবং নিশ্চিত করুন child আপনার ইচ্ছাকৃত অ্যাকশনসহ লোড হয়েছে। তারপর local_ts এর ভিতরের একটি হোস্ট থেকে remote_ts এর ভিতরের ঠিকানায় একটি প্যাকেট পাঠান এবং swanctl --list-sas দেখুন। আউটপুট না বদলালে ডেমন পর্যন্ত কোনো acquisition পৌঁছায়নি।
নীরব ট্র্যাপের দুটি সাধারণ কারণ: প্যাকেটটি নীতিতে আঘাত করার আগেই source-NAT হয়েছে এবং আর local_ts এর সঙ্গে মেলে না, অথবা সিনট্যাক্স বা ক্রেডেনশিয়াল ত্রুটির কারণে সংযোগটি কখনো লোড হয়নি। আবার চালান swanctl --load-all এবং সিলেক্টর ছোঁয়ার আগে তার আউটপুট পড়ুন। যে সংযোগ লোড হয়নি সেটি কোনো নীতি ইনস্টল করে না, তাই ট্রাফিকের নিক্ষেপ করার কিছু থাকে না।
দিকও গুরুত্বপূর্ণ: বহির্গামী ট্রাফিকের জন্য ইনস্টল করা ট্র্যাপ ইনবাউন্ড প্যাকেটে শুরু হয় না। যদি দূরের পক্ষই টানেল তোলার কথা হয়, তবে তার নিজের ট্র্যাপ দরকার, অথবা এই পক্ষের দরকার start.
প্রথম প্যাকেটের জন্য অপেক্ষা করা সবসময় সঠিক বিনিময় নয়
ইন্টারঅ্যাকটিভ সেশন সেটআপ খরচ টের পায়। প্রথম অনুরোধ IKE বিনিময় ও CHILD আলোচনার দাম দেয়, আর কম সময়সীমার ক্লায়েন্ট SA তৈরির আগেই হাল ছেড়ে দিতে পারে। সক্রিয় start সেই প্রথম-প্যাকেট বিলম্ব দূর করে। এটি এমন ট্রাফিকের জন্য টানেল খোলা রাখে যা কখনো নাও আসতে পারে।
তিনটি তথ্য সিদ্ধান্ত ঠিক করে: পথটি কত ঘন ঘন ব্যবহৃত হয়, প্রথম অনুরোধের সময়সীমা কত টাইট, এবং বুটের সময় পিয়ার পৌঁছানো যায় কি না। মাঝে মাঝে ব্যাচ ট্রাফিক এবং বুটে অফলাইন থাকতে পারে এমন পিয়ার — দুটোই trap-এর পক্ষে। লেটেন্সি-সংবেদনশীল ক্লায়েন্ট এবং সর্বদা পৌঁছানো যায় এমন পিয়ার start-এর পক্ষে। দুই পক্ষই শুরু করতে পারলে ঠিক করুন কে ট্রিগারের মালিক, যাতে ডুপ্লিকেট আলোচনা না হয়।
ইনস্টল করা নীতি লিক-প্রুফ গ্যারান্টিও নয়। যদি প্রয়োজন fail-closed হয়, ফায়ারওয়ালকে SA-হীন ট্রাফিক ফেলে দিতে হবে, আর সেই নিয়ম child সংজ্ঞার বাইরে থাকে।
পরবর্তী তর্ক শেষ করার তিনটি লাইন লিখে রাখুন
সিলেক্টর, স্টার্টআপ অ্যাকশন এবং SA ছাড়া নীতি বিদ্যমান দেখানো কমান্ড আউটপুট লিখুন। এই তিনটি লাইন পরের বার কেউ টানেল ডাউন বললে “অন ডিমান্ড ও নিষ্ক্রিয়” আর “লোড হচ্ছে না”-র মধ্যে পার্থক্য করে। এগুলো ধরে রাখতে এক মিনিট লাগে। এগুলো ছাড়া একই তদন্ত শূন্য থেকে শুরু হয়।
এমন হোস্ট থেকে পরীক্ষা করুন যা সত্যিই সিলেক্টরের ভিতরে। রাউটার নিজেই ping করলে প্রায়ই ভিন্ন পথ ধরে এবং পিছনের সাবনেট সুরক্ষাকারী নীতির বিষয়ে কিছু প্রমাণ করে না।