একাধিক ক্লায়েন্টের জন্য উপযোগী IKEv2 সেটিংস পরিকল্পনা করুন
একটি কার্যকর ডেস্কটপ প্রোফাইল কেবল একটি ক্লায়েন্টকে পরীক্ষা করেছে। পরিচয় চুক্তিতে একমত হোন, সমর্থিত ছেদ বেছে নিন, তারপর প্রতিটি প্ল্যাটফর্মে নবীকরণ ও স্লিপ পরীক্ষা করুন।
একটি ডেস্কটপে কার্যকর প্রোফাইল মানে একটি ক্লায়েন্টের সফল পরীক্ষা। এটি আন্তঃপ্ল্যাটফর্ম স্থাপনা নয়, আর এটিকে তা ভাবলে পরিচিত সহায়তা-ধরনটি তৈরি হয়: Windows সংযুক্ত হয়, ফোন পরিচয় যাচাইয়ে ব্যর্থ হয়, এবং পরিচালিত ল্যাপটপ জেগে উঠলেই আবার সংযুক্ত হয়। পার্থক্যগুলি বাস্তব ও বেশিরভাগ ক্ষেত্রে অনুমেয়, তাই পরিকল্পনাটি স্ক্রিনশট নয়, একটি ম্যাট্রিক্স হওয়া উচিত।
প্রথমে পরিচয় চুক্তি নির্ধারণ করুন
অ্যালগরিদম আলোচনার আগে সার্ভার পরিচয়, সার্টিফিকেট বিশ্বাস এবং ক্লায়েন্ট প্রমাণীকরণ পদ্ধতি নথিভুক্ত করুন। এই তিনটিই ঠিক করে ক্লায়েন্ট আদৌ প্রমাণীকরণ করতে পারবে কি না, এবং প্ল্যাটফর্মগুলি এগুলোকেই ভিন্নভাবে প্রকাশ করে।
প্রতিটি প্ল্যাটফর্ম প্রত্যাশিত শনাক্তকারীকে কীভাবে নাম দেয় এবং বিষয়-বিকল্প নামগুলি কীভাবে পরিচালনা করে তা দেখুন। যে প্রোফাইল একটি ক্লায়েন্টে সার্ভার নাম গ্রহণ করে, সে অন্যটিতে একই সার্টিফিকেট প্রত্যাখ্যান করতে পারে, কারণ শনাক্তকারী ক্ষেত্রটি ভিন্ন মান থেকে পূরণ হয়।
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
তারপর ক্রিপ্টোগ্রাফিক ছেদ বাছুন
প্রতিটি সমর্থিত ক্লায়েন্ট যে প্রস্তাব দিতে পারে তা তুলনা করুন এবং এমন আধুনিক ছেদ বাছুন যা গেটওয়েও অনুমোদন করে। একটি পুরনো ডিভাইস সংযুক্ত হবে বলে অতিরিক্ত বড় পুরনো তালিকা সক্রিয় করবেন না, কারণ সেই তালিকাই পরবর্তী সবার জন্য গেটওয়ের ডিফল্ট হয়ে যায়। প্রতিটি পুরনো বিকল্প কেন এখনও আছে তা লিখে রাখুন। যে ডিভাইসটির প্রয়োজন তা যদি কেউ নাম বলতে না পারে, তবে এটি কোনো প্রয়োজনীয়তা নয়।
পরিকল্পনায় IKE ও CHILD সেটিংস আলাদা রাখুন। IKE বিনিময়ের জন্য গ্রহণযোগ্য প্রস্তাব স্বয়ংক্রিয়ভাবে সুরক্ষিত ট্র্যাফিকের জন্য গ্রহণযোগ্য নয়, আর দুটিই আলাদাভাবে আলোচিত হয়। যে গেটওয়ে এক স্তরে প্রস্তাব গ্রহণ করে, সে অন্য স্তরে তা প্রত্যাখ্যান করতে পারে, এবং লগ এমন ব্যর্থতা দেখাবে যা দেখতে প্রথম স্তরটি সফল হয়েছে বলে মনে হয়।
যাচাইকৃত প্রক্রিয়ায় পরিচয়পত্র সরবরাহ করুন, এবং ব্যবহারকারীর পাসওয়ার্ড, শেয়ার্ড সিক্রেট ও ক্লায়েন্টের ব্যক্তিগত কী আলাদা ক্ষেত্রে রাখুন। একই রকম নামের বাক্সে পরীক্ষা-নিরীক্ষা করাই একটি কার্যকর পরীক্ষাকে পুনরুৎপাদন-অযোগ্য পরীক্ষায় পরিণত করে।
স্থির অবস্থা নয়, জীবনচক্র পরীক্ষা করুন
প্রতিটি ক্লায়েন্টের জন্য প্রাথমিক প্রমাণীকরণ, উদ্দিষ্ট অ্যাপ্লিকেশন, DNS রিজলিউশন ও ঠিকানা-পরিবার কভারেজ পরীক্ষা করুন। তারপর যে অংশগুলি কেবল পরে দেখা যায় সেগুলি চালান: নবীকরণ, স্লিপ এবং স্বাভাবিক নেটওয়ার্ক পরিবর্তন।
MOBIKE সমর্থন ও পুনঃপ্রমাণীকরণের আচরণ এইমাত্র মাপা স্থির ফলাফল থেকে ভিন্ন হতে পারে। কেবল ইন্টারফেস শেষ পর্যন্ত সংযুক্ত দেখায় কি না তা নয়, সেই সময়ের ঘটনা ও অ্যাসোসিয়েশন অবস্থা লিপিবদ্ধ করুন।
VPN অনুপলব্ধ থাকাকালীন সরাসরি ট্র্যাফিক কী করতে পারে তা নির্ধারণ করুন। এটি ক্লায়েন্ট পুনরায় সংযুক্ত হবে কি না তা থেকে আলাদা একটি নীতি সিদ্ধান্ত, এবং বেশিরভাগ স্থাপনা দ্বিতীয় প্রশ্নের উত্তর দেয় প্রথমটি উপেক্ষা করে। উত্তরটি প্রোফাইল নামের পাশে স্থাপনা-নোটে লিখে রাখুন। কোনো বিভ্রাটের সময় কারও এটি প্রয়োজন হবে, আর পুনর্গঠনের সময় তার হাতে থাকবে না।
এক প্ল্যাটফর্ম ভিন্নমত পোষণ করলে সার্ভার পরিচয় যাচাই ব্যবহার করুন
যখন একটি প্রোফাইল এক প্ল্যাটফর্মে কাজ করে আর অন্যটি তার নাম প্রত্যাখ্যান করে, তখন ক্লায়েন্ট আসলে যে শনাক্তকারী পাঠিয়েছে তা সার্টিফিকেটে থাকা শনাক্তকারীগুলির সঙ্গে তুলনা করুন। এই তুলনাই সাইফার তালিকা বদলানোর চেয়ে এই ক্ষেত্রগুলির অধিকাংশ দ্রুত সমাধান করে।
পরীক্ষিত ম্যাট্রিক্সটি কনফিগারেশন উৎস ও হালনাগাদ পদ্ধতির সঙ্গে রাখুন। পুরনো ক্লায়েন্টের সমর্থন শেষ হলে পরবর্তী নিরীক্ষায় খুঁজে পাওয়ার জন্য গেটওয়েতে দুর্বল সামঞ্জস্য সেটিংস লুকিয়ে না রেখে সচেতনভাবে তার ব্যতিক্রমটি সরিয়ে দিন। strongSwan IKEv2 ডকুমেন্টেশন বিনিময়গুলি কীভাবে কনফিগার হয় তার জন্য দরকারি রেফারেন্স।