আপনার IPsec টানেল কেন প্রথম CHILD SA কী পুনর্নবীকরণ পর্যন্ত কাজ করে

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

সংযুক্ত থাকার অর্থ PFS সেটিংস মিলে যাওয়া নয়

IKEv2-তে প্রথম child অ্যাসোসিয়েশন তৈরি হয় প্রমাণীকরণ বিনিময়ের সময়, আর তার কীগুলি এসেছে IKE অ্যাসোসিয়েশন ইতিমধ্যেই যে উপাদান তৈরি করেছে তা থেকে। ওই child-এর জন্য আলাদা Diffie-Hellman বিনিময় হয় না, তাই পুনর্নবীকরণে একটি দাবি করে এমন নীতি উত্থাপনের সময় পরীক্ষিত হয় না।

পুনর্নবীকরণ একটি ভিন্ন বিনিময়। কোনো child অ্যাসোসিয়েশনের কী পুনর্নবীকৃত হলে দুই প্রান্ত তাদের proposal-এ উল্লিখিত গ্রুপ নিয়ে নতুন কী বিনিময় করতে পারে, আর তখনই প্রথমবার গ্রুপ সেটিংস তুলনা করা হয়। তাই যে দুই প্রান্ত একমত নয় তারা প্রমাণীকরণ করতে, child অ্যাসোসিয়েশন বসাতে ও ট্রাফিক পার করতে পারে, কিন্তু পুনর্নবীকরণে ব্যর্থ হয়।

proposal স্ট্রিং-এ অমিল কোথায় লুকিয়ে থাকে

strongSwan-এ গ্রুপটি child proposal-এর সঙ্গে যুক্ত হয়, তাই aes256gcm16-prfsha256-ecp256 এর মতো স্ট্রিং দেখতে এনক্রিপশন পছন্দের মতো, কিন্তু এটি কী-বিনিময়ের দাবিও বহন করে। যে প্রান্ত কেবল aes256gcm16-prfsha256 প্রস্তাব করে তার এমন দাবি নেই, আর দুই তালিকা এনক্রিপশনে মেলে কিন্তু বিনিময়ে মেলে না।

child proposal ও IKE proposal-কে আলাদা তালিকা হিসেবে পড়ুন। IKE তালিকায় থাকা কোনো গ্রুপ child তালিকা সম্পর্কে কিছুই বলে না, আর একটি পড়তে পড়তে অন্যটি সম্পাদনা করাই এটি হাতছাড়া হওয়ার স্বাভাবিক উপায়।

ব্যর্থতাটি পড়ুন, আপনি যে ফাইল সম্পাদনা করেছেন তা নয়

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

ডিস্কে থাকা কনফিগারেশন নয়, চলমান কনফিগারেশন নিশ্চিত করুন। সংরক্ষিত কিন্তু লোড না হওয়া ফাইল, বা অন্য include থেকে আবার পড়া সংযোগ, এমন অমিল তৈরি করবে যা দৃশ্যমান ফাইল যতই সম্পাদনা করুন ঠিক হবে না।

তিনটি ঘটনা যাদের সবাই rekey বলে

IKE অ্যাসোসিয়েশন rekeying, IKE পুনঃপ্রমাণীকরণ আর child অ্যাসোসিয়েশন rekeying আলাদা proposal নিয়মসহ আলাদা কাজ। এগুলোর একটিতে রিপোর্ট করা ব্যর্থতা অন্যগুলো সম্পর্কে সরাসরি কিছু বলে না, আর যেসব লগ এগুলো মেশায় তা তিনটি ঘটনা হলেও একটি পুনরাবৃত্ত ত্রুটির মতো পড়া যায়।

প্রান্তটি কোন ঘটনার নাম নিচ্ছে তা খেয়াল করুন, তারপর কেবল সেই ঘটনার proposal পরীক্ষা করুন। একটি তালিকা বদলান, রিলোড করুন, আবার একই ঘটনা জোর করুন। লগ পুনঃপ্রমাণীকরণের নাম নিলে IKE proposal-ই পড়ার মতো। child rekey-এর নাম নিলে child proposal-ই গুরুত্বপূর্ণ গ্রুপটি বহন করে।

পুনর্নবীকরণ বন্ধ করা কোনো সমাধান নয়

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

বরং proposal-গুলো মিলিয়ে নিন। দুই প্রান্তই যে গ্রুপ বাস্তবায়ন করে তা বেছে নিন, দুই দিকেই সেটি child proposal-এ রাখুন, আর পুনর্নবীকরণ নীতিকে সংগঠনের সত্যিকার প্রয়োজনীয় পরিসরের মধ্যে রাখুন।

যে বিনিময়টি ব্যর্থ হয়েছিল তা দিয়েই প্রমাণ করুন

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

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