একটি IPsec প্রস্তাবে কী থাকে? IKE ও ESP ক্ষেত্রগুলি
একটি প্রস্তাব মানে একটি সম্পূর্ণ প্রস্তাবনা, অ্যালগরিদমের থলি নয়। দেখুন কোন ক্ষেত্রগুলি IKE-র এবং কোনটি ESP-র, আর কেন একটি অসঙ্গতি পুরো সেটটিই বাতিল করে।
IKE শুরু হয়, দুই পক্ষই AES ঘোষণা করে, তবুও টানেলটি NO_PROPOSAL_CHOSEN নিয়ে ব্যর্থ হয়। লগটি প্রস্তাবের নাম বলে, কিন্তু যে ক্ষেত্রটি মেলেনি তা বলে না। একটি প্রস্তাব হলো একটি সম্পূর্ণ প্রস্তাবনা, আর একটি অসামঞ্জস্যপূর্ণ ক্ষেত্র শুধু ওই লাইনটি নয়, পুরো সমন্বয়টিকেই অকার্যকর করে। এটিকে স্বাধীন অ্যালগরিদম পছন্দের থলি হিসেবে পড়াই হলো সেই সাধারণ কারণ যার জন্য অসঙ্গতিটি অদৃশ্য থাকে।
আলাদা প্রস্তাব-তালিকা নিয়ে দুটি আলাপ
IKEv2 দুটি নিরাপত্তা সংযোগ গড়ে। প্রথমটি IKE SA, যা নিয়ন্ত্রণ বিনিময়কে নিজেই সুরক্ষিত রাখে, আর দ্বিতীয়টি CHILD SA, যা ESP-র মাধ্যমে আপনার ট্রাফিক বহন করে। প্রতিটির নিজস্ব প্রস্তাব-তালিকা আছে, এবং এক পক্ষ একটি গ্রহণ করে অন্যটি প্রত্যাখ্যান করতে পারে।
এই বিভাজন একটি সাধারণ বিভ্রান্তির ব্যাখ্যা দেয়: কার্যকর IKE SA কেবল প্রমাণ করে যে নিয়ন্ত্রণ-চ্যানেলের অ্যালগরিদমগুলি মিলেছে। CHILD প্রস্তাব ব্যর্থ হলে, প্রথম পর্যায় সম্পন্ন হলেও এবং লগ উপরের দিকে সুস্থ দেখালেও, টানেল কোনো প্যাকেট বহন করে না।
প্রতিটি তালিকার ভেতরের ক্রমও গুরুত্বপূর্ণ। উত্তরদাতা সূচনাকারীর ক্রমবদ্ধ প্রস্তাবগুলি থেকে বেছে নেয়, তাই বিস্তৃতভাবে সামঞ্জস্যপূর্ণ একটি এন্ট্রিকে সংকীর্ণ একটির উপরে সরালে কোন স্যুটটি ইনস্টল হবে তা বদলে যায়, যদিও কোনো অ্যালগরিদমের নাম বদলায় না। ডিফল্টের উপর নির্ভর না করে ওই ক্রমটি কনফিগারেশনে পিন করুন। স্থিতিশীল ক্রম সাইটগুলির মধ্যে লগ তুলনাকেও অর্থবহ করে।
কোন ক্ষেত্র কোন প্রস্তাবের
ক্ষেত্রের সেটটি ছোট, কিন্তু দুই আলাপে এটি অভিন্ন নয়। টেবিলটি সারি ধরে পড়ুন, কারণ এক কলামের একটি ক্ষেত্র অন্যটিতে অনুপস্থিত থাকতে পারে। বিন্যাস বাস্তবায়নভেদে বদলায়; strongSwan-এর প্রস্তাব-সংক্রান্ত ডকুমেন্টেশন একটি নির্দিষ্ট রেফারেন্স।
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
এনক্রিপশন ক্ষেত্রটি সাইফার এবং বেশিরভাগ বিন্যাসে তার কী-দৈর্ঘ্য বলে। ইন্টিগ্রিটি ক্ষেত্রটি সাইফারটেক্সট প্রমাণীকরণে ব্যবহৃত হ্যাশ বলে, আর PRF সেই ফাংশন বলে যা IKE SA-র জন্য কী উপাদান তৈরি করে। DH গ্রুপ নতুন সাধারণ গোপন উপাদান প্রতিষ্ঠা করে, তাই এটি দুই পক্ষেই থাকে, তবে ভিন্ন উদ্দেশ্যে।
বর্ধিত ক্রম-সংখ্যাগুলি কেবল ডেটা পথের। সেগুলি ক্রম-স্থানকে প্রসারিত করে এবং CHILD প্রস্তাবের অংশ হিসেবে আলোচিত হয়, তাই সেখানে অসঙ্গতি একটি CHILD প্রস্তাব বাতিল করে, অথচ IKE SA অক্ষত থাকে।
একটি সম্পূর্ণ প্রস্তাবনা কীভাবে বেছে নেওয়া হয়
প্রতিটি প্রস্তাব একটি সেট, আর উত্তরদাতা এমন সেট খোঁজে যেখানে প্রতিটি আবশ্যক ক্ষেত্র গ্রহণযোগ্য। দুটি তালিকাতেই AES ও SHA-256 থাকতে পারে এবং তবুও কোনো সামঞ্জস্যপূর্ণ এন্ট্রি না থাকতে পারে, কারণ কী-দৈর্ঘ্য, PRF বা DH গ্রুপ আলাদা। তুলনা প্রতিটি প্রস্তাব ধরে হয়, প্রতিটি অ্যালগরিদম ধরে নয়।
কিছুই না মিললে উত্তরদাতা যে SA ধরনটি ব্যর্থ হয়েছে তা নিয়ে NO_PROPOSAL_CHOSEN পাঠায়। কনফিগারেশন সম্পাদনার আগে দেখুন বিজ্ঞপ্তিটি কোন প্রস্তাব-তালিকাকে বোঝাচ্ছে; IKE প্রস্তাব প্রত্যাখ্যাত হলে ESP অ্যালগরিদম বদলানো ডিবাগিং চক্র নষ্ট করে।
প্রোফাইল সাজানোর সময় নির্বাচন-আচরণ জানা ভালো। কিছু বাস্তবায়ন সূচনাকারীর ক্রম পছন্দ করে, অন্যরা স্থানীয় নীতিমালা অনুযায়ী পুনর্বিন্যাস করে, তাই দুই বিক্রেতার মধ্যে কাজ করা একটি স্যুট হারিয়ে যেতে পারে যখন আপনি উল্টে দেন কোন পক্ষ সংযোগ শুরু করছে।
AEAD একটি ক্ষেত্র যোগ করে না, বাদ দেয়
AES-GCM ও ChaCha20-Poly1305 একই ক্রিয়ায় প্রমাণীকরণ ও এনক্রিপশন করে। ESP-র জন্য এদের যেকোনোটি নির্বাচিত হলে ইন্টিগ্রিটি অ্যালগরিদম আলাদাভাবে আলোচিত হয় না, কারণ AEAD গঠনটি ইতিমধ্যেই তা ঢেকে দেয়। তাই AES-GCM-কে SHA-256-এর সঙ্গে জোড়া দেওয়া প্রস্তাবটি সবচেয়ে ভালো ক্ষেত্রে অপ্রয়োজনীয়, আর সবচেয়ে খারাপ ক্ষেত্রে প্রত্যাখ্যাত।
IKE পাশে PRF এখনও আলাদা, কারণ এটি পেলোড সুরক্ষার বদলে নিয়ন্ত্রণ চ্যানেলের কী তৈরি করে। এ কারণেই একটি IKE প্রস্তাব বৈধভাবে AEAD সাইফারের সঙ্গে PRF ও DH গ্রুপ মিলিয়ে দিতে পারে, অথচ সংশ্লিষ্ট ESP প্রস্তাব কেবল AEAD সাইফার ও ঐচ্ছিক PFS গ্রুপ তালিকাভুক্ত করে।
কী-দৈর্ঘ্য এনক্রিপশন টোকেনের অংশ, তাই AES-128-GCM ও AES-256-GCM আলাদা প্রস্তাব। যে নির্দেশিকায় 256-bit কী ধরা হয়েছে সেখান থেকে কপি করা প্রোফাইল 128-bit-এর জন্য কনফিগার করা এন্ডপয়েন্টের সঙ্গে মিলবে না, যদিও দুই লাইনই AES-GCM বলে। দুই পক্ষ সাইফার পরিবারে একমত হয়েও ড্যাশের পরের সংখ্যার কারণে একে অপরকে প্রত্যাখ্যান করতে পারে।
ইনস্টল হওয়া SA পড়ুন, কনফিগারেশন নয়
কনফিগার করা প্রস্তাব-তালিকা একটি প্রস্তাবনা; ইনস্টল হওয়া SA হলো ফলাফল। strongSwan ও Linux কার্নেলে দুই দৃশ্যই পাওয়া যায়:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas প্রতি SA-তে আলোচিত অ্যালগরিদমগুলি ছাপে, CHILD AEAD ব্যবহার করে কি না তাও সহ। ip xfrm state কার্নেল আসলে কী ইনস্টল করেছে তা দেখায়, আর এখানেই নিশ্চিত করতে হয় যে কী পুনর্নবীকরণ আপনার নথিভুক্ত স্যুটির বদলে ভিন্ন কোনো স্যুটে ফিরে যায়নি।
সংশোধনের পরে ওই আউটপুটটি কনফিগারেশনের পাশে সংরক্ষণ করুন। ক্লায়েন্ট আপডেট তার ডিফল্ট বদলালে, রেকর্ড করা স্যুটটি আপনাকে তুলনার জন্য একটি ভিত্তিরেখা দেয়, আর তুলনাটি তদন্ত শূন্য থেকে শুরু করার বদলে যে ক্ষেত্রটি সরে গেছে তা দেখায়।