VPN গেটওয়ের মাধ্যমে EAP: পদ্ধতিটি কে সমাপ্ত করে

হেল্পডেস্ক টিকিটে ব্যর্থ VPN লগইন আর আরও শক্তিশালী পদ্ধতি দাবি করা RADIUS নীতি একই সমস্যা বলে বর্ণিত হয়, কিন্তু তা নয়। গেটওয়ে হয় শংসাপত্র গ্রহণ করে পাঠিয়ে দেয়, নয়তো ক্লায়েন্ট ও প্রমাণীকরণ সার্ভারের মধ্যে EAP কথোপকথন বহন করে। কোনটি ঘটছে তা ঠিক করে সার্ভার-পাশের পরিবর্তন আদৌ কিছু ঠিক করতে পারবে কি না। সার্ভার গ্রুপ সম্পাদনার আগে বিনিময়টি পড়ুন।

লগে একই রকম দেখানো দুটি প্রমাণীকরণ পথ

প্রথম পথে VPN গেটওয়ে ব্যবহারকারীর নাম ও পাসওয়ার্ড সংগ্রহ করে পাসওয়ার্ড অ্যাট্রিবিউটসহ RADIUS Access-Request পাঠায়। প্রমাণীকরণ সার্ভার তা নিজের শংসাপত্র ভাণ্ডারের সঙ্গে তুলনা করে গ্রহণ বা প্রত্যাখ্যান জানায়। ক্লায়েন্ট কখনও EAP পদ্ধতি চালায় না, কারণ কেউ তা চায়নি।

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

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

পদ্ধতিটি আসলে কোথায় চলে

RFC 3579 পাস-থ্রু ব্যবস্থা নির্ধারণ করে: NAS RADIUS অ্যাট্রিবিউটে EAP প্যাকেট বহন করে এবং প্রতিটি EAP ধরনের জন্য পদ্ধতি-নির্দিষ্ট কোড লাগে না। তাই গেটওয়ে PEAP ও EAP-TLS সমর্থন করতে পারে, কোনোটিই বাস্তবায়ন না করে।

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

PPP প্রমাণীকরণ সেটিংস PPP সেবার অন্তর্গত। একই AAA সার্ভার ব্যবহার করা প্রতিটি IPsec বা পুরনো XAuth পথ তারা নিঃশব্দে পুনঃকনফিগার করে না, তাই এক অ্যাক্সেস ধরনের জন্য কাজ করা পরিবর্তন অন্যটিকে অক্ষত রাখতে পারে।

NAS-কে কী সমর্থন করতে হবে

পাস-থ্রু চাহিদা পদ্ধতির কোড থেকে বাহক সমর্থনে সরিয়ে দেয়। গেটওয়েকে নিজের VPN প্রোটোকলে EAP বহন করতে হবে, আর তার RADIUS ক্লায়েন্টকে সংশ্লিষ্ট আকারের EAP-Message অ্যাট্রিবিউট পাঠাতে ও গ্রহণ করতে হবে।

IKEv2-তে EAP একটি নির্দিষ্ট প্রমাণীকরণ প্রবাহের অংশ, এবং সার্ভার পরিচয় ও বিশ্বাস যাচাই ওই প্রবাহ থেকেই আসে। 802.1X স্থাপনা থেকে ধার করা PEAP লেবেল স্বয়ংক্রিয়ভাবে সরে না, কারণ এর চারপাশের দরকষাকষি আলাদা।

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

নীতি বদলানোর আগে একটি প্রচেষ্টা পড়ুন

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

Linux গেটওয়েতে RADIUS পোর্টে ক্যাপচার দেখায় তারে কোন অ্যাট্রিবিউট আছে:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

তারপর প্রত্যাখ্যানের বিন্দু তুলনা করুন। কোনও RADIUS প্যাকেটের আগে গেটওয়েতে ব্যর্থতা মানে ক্লায়েন্ট ও গেটওয়ে পদ্ধতি নিয়ে একমত হয়নি। EAP অ্যাট্রিবিউটসহ RADIUS প্রত্যাখ্যান মানে প্রান্ত দুটি পদ্ধতি চালিয়েছে এবং তার একটি ফলাফল প্রত্যাখ্যান করেছে।

স্থানান্তরকে একই শুরু-থেকে-শেষ পরিবর্তন হিসেবে পরিকল্পনা করুন

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

যে সমন্বয় কাজ করে তা লিখে রাখুন: VPN প্রোটোকল, EAP বাহক, সমকক্ষ পদ্ধতি, সার্ভার পদ্ধতি, শংসাপত্রের ধরন ও সার্ভার পরিচয় যাচাই।

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