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

ফাইল নয়, প্যাকেট থেকে শুরু করুন

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

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

প্রথম ক্ষেত্র-গোষ্ঠী: যে সংজ্ঞা সত্যিই লোড হয়েছে

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

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

দ্বিতীয় ক্ষেত্র-গোষ্ঠী: প্রান্তবিন্দু পরিচয় নয়

পিয়ার যে ঠিকানা থেকে সংযোগ করে আর যে পরিচয় দিয়ে প্রমাণীকরণ করে সেগুলো আলাদা ক্ষেত্র। হোস্টনাম, বিশিষ্ট নাম, কী আইডি আর ঠিকানা—কনফিগারেশন অনুযায়ী সবই IKE পরিচয় হিসেবে কাজ করতে পারে, আর তাদের পাবলিক ঠিকানার মতো দেখতে হতেই হবে না।

প্রান্তবিন্দু মেলানোর সাথে NAT দৃষ্টিভঙ্গিও থাকতে পারে: নেটওয়ার্কে দেখা ঠিকানা আর পিয়ার যে ঠিকানা নিজের বলে মনে করে, সেগুলো আলাদা হতে পারে। libreswan-এর সংযোগ মডেলে left আর right হলো দুই অংশগ্রহণকারীর লেবেল, কোনো নির্দিষ্ট লোকাল-রিমোট ক্রম নয়, তাই অন্য সাইটের কাজ করা কনফিগ কপি করে ঠিকানা অদলবদল করা নির্ভরযোগ্য অনুবাদ নয়।

উভয় পক্ষের প্রত্যাশিত পরিচয় এবং তা যাচাই করা শংসাপত্র লিখে রাখুন। এই দুই লাইন না মিললে ঠিকানা খোঁটাখুঁটি করে কোনো মিল আসবে না।

তৃতীয় ক্ষেত্র-গোষ্ঠী: যে ট্রাফিক সুরক্ষিত হচ্ছে

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

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

চতুর্থ ক্ষেত্র-গোষ্ঠী: আপনি একটি বাস্তবায়ন পড়ছেন

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

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

সমন্বিত সংশোধনের পরে নির্বাচিত প্রোফাইল ও অ্যাসোসিয়েশন নিশ্চিত করুন, তারপর প্রকৃত অনুমোদিত সেবা ও তার উত্তর-পথ পরীক্ষা করুন। প্রোফাইল মিললে দর-কষাকষি সম্ভব হয়, আর দর-কষাকষি শেষ প্রবেশ-যাচাই নয়।

সম্পর্কিত নিবন্ধ