RADIUS কেন VPN ব্যবহারকারীনামের বদলে IP ঠিকানা দেখে

strongSwan যেকোনো EAP বিনিময়ের আগেই IKE পরিচয় RADIUS User-Name-এ রাখতে পারে। কে অ্যাকাউন্ট পরিচয় চাইবে তা ঠিক করুন, তারপর একটি প্রচেষ্টা মিলিয়ে দেখুন।

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

একটি সংযোগে দুটি পরিচয় চলে

একটি সংযোগে দুটি নাম দেখা যেতে পারে। IKE পরিচয় টানেল সেটআপের সময় সমকক্ষকে চিহ্নিত করে, এবং eap-radius প্লাগইন প্রথমে এটি RADIUS User-Name-এ অনুলিপি করে। EAP পরিচয় একটি ভিন্ন মান, যা ব্যবহারকারী প্রমাণীকরণে ব্যবহৃত হয়, এবং কেউ না চাইলে এটি কখনো পাঠানো নাও হতে পারে।

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

গেটওয়েকে EAP পরিচয় চাইতে বলুন

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

remote {
    auth = eap-radius
    eap_id = %any
}

এটি থাকলে ব্যাকএন্ড IKE ঠিকানার বদলে ক্লায়েন্ট EAP বিনিময়ে যে পরিচয় দেয় তা পায়। সংযোগে আর কিছুই বদলায় না।

অথবা RADIUS-কে EAP বিনিময় শুরু করতে দিন

অন্য ব্যবস্থাটি প্রথম পদক্ষেপ RADIUS পক্ষে রাখে। প্লাগইন প্রাথমিক পরিচয় প্রতিক্রিয়ার জন্য অপেক্ষা না করে EAP-Start সংকেত পাঠাতে পারে, যা সার্ভারকে বিনিময় চালাতে দেয়। এটি প্লাগইন-স্তরের কনফিগারেশন, তাই প্লাগইন ব্যবহার করা প্রতিটি সংযোগে প্রভাব ফেলে।

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

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

একটি প্রচেষ্টা দুই লগে অনুসরণ করুন

একটি প্রচেষ্টা দুই লগে মিলিয়ে দেখুন। IKE পরিচয় দেখুন, তারপর EAP-Identity বিনিময় ঘটছে কি না, তারপর প্রমাণীকরণ ধাপ কোন নাম পায়। যে ব্যাকএন্ড EAP বিনিময়ের আগে ঠিকানাটি প্রত্যাখ্যান করে সে আপনার ইচ্ছাকৃত পরিচয় দেখার আগেই প্রক্রিয়া থামাতে পারে।

journalctl -u strongswan -f

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

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

সম্পর্কিত নিবন্ধ