এক IKEv2 লগইনে দুটি পরিচয়: আগে মেশিন, পরে ব্যবহারকারী

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

উপসর্গ: সফল প্রথম প্রমাণের পরে ব্যর্থতা

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

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

এক্সটেনশনটি কী যোগ করে আর কী যোগ করে না

IKEv2 একটি একক সেশনের ভিতরে একাধিক প্রমাণীকরণ বিনিময় চালানোর একটি এক্সটেনশন বহন করে। RFC 4739 অন্যান্য ক্রমের মধ্যে এমন একটি ক্লায়েন্টের বর্ণনা দেয় যে সার্টিফিকেট পরিচয় প্রমাণ করে তারপর EAP-এর মাধ্যমে একজন ব্যক্তিকে প্রমাণীকরণ করে। নথিটি Experimental, অর্থাৎ কোনো বাস্তবায়ন আপনাকে এই সুবিধা দিতে বাধ্য নয়। সহযোগী পক্ষ এটি নিয়ে সমঝোতা না করা পর্যন্ত সহায়তা সম্পর্কে কিছু ধরে নেবেন না।

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

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

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

একই ফাইল গেটওয়েতে ভিন্নভাবে পড়া হয়

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

কোনো রাউন্ড নম্বর তা অগ্রাহ্য না করলে একটি সেকশনের অবস্থানই তার ক্রম নির্ধারণ করে। তাই অতিরিক্ত local বা remote সেকশন বিকল্প নয়, অতিরিক্ত রাউন্ড বর্ণনা করে, আর swanctl.conf রেফারেন্স নথিতে থাকা স্পষ্ট রাউন্ড নম্বরটি ঠিক সেই ক্রমকে ইচ্ছাকৃত করতে বিদ্যমান। তা ছাড়া একটি ব্লক সরালে আচরণ বদলে যায়। এ কারণেই কাগজে সমতুল্য দেখানো দুটি কনফিগারেশন বিপরীত ক্রমে কাজ করতে পারে।

সেই ক্রম-নিয়মটি মনে রাখার মতো ব্যর্থতার ধরন তৈরি করে। দ্বিতীয় remote ব্লক আরেকটি গ্রহণযোগ্য বিকল্প নয়, এটি দ্বিতীয় দাবি, তাই হয়/নয় পড়া একটি নীতি এবং-তারপর হিসেবে আচরণ করে। একটি গেটওয়ে নীতি নিবন্ধিত মেশিনের সার্টিফিকেট গ্রহণ করে তারপর সেই ব্যবহারকারীর EAP বিনিময় দাবি করতে পারে, ঠিক সেই ক্রমে।

রাউন্ড আর স্বাধীন ফ্যাক্টরের পার্থক্য করুন

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

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

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

জোড়া-নিয়ম লিখুন এবং প্রত্যাখ্যানগুলো পরীক্ষা করুন

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

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

swanctl --list-conns
swanctl --list-sas

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