IKEv1, XAuth ও OTP: প্রতিটি প্রম্পট আসলে কী চায়

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

আরেকটি ক্লায়েন্ট ইনস্টল বা একটি ক্রেডেনশিয়াল রিসেট করার আগে প্রতিটি প্রম্পটকে যে স্তরটি তা চাইছে তার সঙ্গে মিলিয়ে নিন।

তিনটি গোপনীয়তা, তিনটি মালিক

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

তিনটি কলাম লিখে রাখুন: মালিক, স্থায়িত্বকাল এবং প্রতিটি যে ব্যর্থতার বার্তা দেয়। ওই টেবিলটাই ডায়াগনস্টিক হাতিয়ার, ক্লায়েন্টের ফিল্ডের নাম নয়।

PSK: ব্যক্তি নয়, পিয়ার

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

ব্যবহারকারীর ক্রেডেনশিয়াল প্রথম ফেজের ব্যর্থতা সারাতে পারে না। এটি ঘোরালে আপনি নিরাপদে ঘোরাতে পারেন এমন একমাত্র ক্রেডেনশিয়াল নষ্ট হয়, আর ভুল তত্ত্বটাই জোর পায়।

XAuth: পুরোনো ব্যবহারকারী বিনিময়

XAuth IKEv1 পিয়ার প্রমাণীকরণের উপরে একটি ব্যবহারকারী প্রমাণীকরণ বিনিময় যোগ করে, আর কোন ব্যাকএন্ড এটি যাচাই করবে তা গেটওয়ে ঠিক করে। সেই ব্যাকএন্ডের উপর নির্ভর করে বিনিময়টি ডিরেক্টরি পাসওয়ার্ড, RADIUS ক্রেডেনশিয়াল বা টোকেন উত্তর নিতে পারে। XAuth শব্দটি ক্রেডেনশিয়ালের ধরন নয়, বিনিময়ের পরিবহনকে বোঝায়।

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

OTP: ব্যাকএন্ড যা চায়

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

নথিভুক্ত ফরম্যাটটি এমন ক্লায়েন্টের সঙ্গে ব্যবহার করুন যা গেটওয়ে যে বিনিময় দেয় তা সম্পূর্ণ করতে পারে।

ক্লায়েন্টের সীমা কোথায় কামড়ায়

Fortinet নথিভুক্ত করে যে FortiClient 7.4.4 ও পরবর্তী সংস্করণ IPsec VPN-এর জন্য IKEv1 আর সমর্থন করে না, যা সর্বজনীন অপসারণ নয় বরং পণ্য ও সংস্করণের সীমা, যেমন FortiClient সামঞ্জস্য নোট লিপিবদ্ধ করে। অন্য ক্লায়েন্টরাও বিনিময়যোগ্য নয়: OpenConnect ও openfortivpn নির্দিষ্ট গেটওয়ে প্রোটোকল বলে, ইচ্ছামতো IKEv1 প্রোফাইল নয়। ইনস্টল করা ক্লায়েন্টের IKE সংস্করণ, PSK মোড, XAuth সমর্থন ও ইন্টারঅ্যাকশন মডেল আলাদা আলাদা করে দেখুন। ভিন্ন পদ্ধতিতে সংযোগ করা ক্লায়েন্ট মূল প্রয়োজনটি প্রমাণ করেনি।

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

ফ্যাক্টর না বন্ধ করে নির্ণয়

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

নিবন্ধন গোপনীয়তা ও শেয়ার্ড কী সংস্থার প্রক্রিয়া অনুযায়ী সুরক্ষিত স্টোরেজে রাখুন। স্থায়ী ফাইলে থাকা এক-বারের কোড এমন একটি ফ্যাক্টর যা আর ফ্যাক্টর নেই।