Windows ও strongSwan সাইফার: সঠিক স্তরটি মেলান

দুই প্রান্তই AES-128 বলে, তবু টানেল তৈরি হতে অস্বীকার করে। CBC ও GCM ভিন্ন ট্রান্সফর্ম, যারা কেবল একই কী-দৈর্ঘ্য ভাগ করে, আর একটি প্রস্তাব করা ক্লায়েন্ট কেবল অন্যটি গ্রহণ করা গেটওয়েকে সন্তুষ্ট করে না। AES শব্দটি একটি পরিবার বোঝায়, কোনো চুক্তি নয়।

একটি দ্বিতীয় অক্ষও আছে, আর বিভ্রান্তিকর ত্রুটিগুলো সেই অক্ষ থেকেই আসে।

দুই স্তর, দুই স্বাধীন তালিকা

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

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

গেটওয়ের সঙ্গে তুলনা করার আগে দুই তালিকাই লিখে রাখুন। স্মৃতি থেকে তুলনা করলে একই ক্ষেত্র দুবার সম্পাদিত হয় আর অন্যটি কখনোই নয়। প্রোফাইলের পাশে গেটওয়ে কনসোল খোলা রাখুন।

প্রস্তাবগুলোর পাশে ত্রুটিটি পড়ুন

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

প্রাপ্ত প্রস্তাব, কনফিগার করা প্রস্তাব ও নির্বাচিত প্রস্তাব তুলনা করুন সেই একক প্রচেষ্টার জন্য। এখানে তিনটি ভিন্ন তালিকা গুরুত্বপূর্ণ, আর কেবল শেষটিই বলে দেয় আসলে কী ব্যবহার হয়েছে। সারসংক্ষেপ না করে টিকেটে এটি হুবহু উদ্ধৃত করুন।

CBC ও GCM-কে আলাদা বিকল্প হিসেবে রাখুন

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

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

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

ESP প্রস্তাব পুনঃনামকৃত IKE প্রস্তাব নয়

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

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

দুই স্যুট যাচাই করুন, তারপর কী পুনর্নবীকরণ

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

পরিবর্তনের সঙ্গে সেই প্রমাণ রাখুন। বারবার সংযোগ বিচ্ছিন্ন হলে কারো টাইমার বা প্ল্যাটফর্ম ত্রুটিকে দোষারোপের আগে তার নিজস্ব ব্যর্থ-বিনিময় রেকর্ড দরকার।