নির্দিষ্ট VPN IP: RADIUS Framed-IP-Address নাকি পুল রিজার্ভেশন

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

একটি নির্দিষ্ট ঠিকানা যেখানে থাকতে পারে এমন তিন জায়গা

RADIUS ঠিকানার মালিক হয় যখন উত্তরে Framed-IP-Address থাকে এবং গেটওয়ে সেই মানটি সেশনে প্রয়োগ করে। গেটওয়ে এর মালিক হয় যখন একজন প্রশাসক অ্যাকাউন্টটিকে পুলের ভিতরের একটি স্ট্যাটিক ঠিকানায় ম্যাপ করেন। ক্লায়েন্টের কিছুই নেই, এমনকি যখন তার অ্যাডাপ্টার একটি ম্যানুয়াল ঠিকানা দেখায়, কারণ সার্ভার দর-কষাকষির সময় অভ্যন্তরীণ ঠিকানাটি বরাদ্দ করে এবং স্থানীয় সেটিং কেবল তখনই গুরুত্বপূর্ণ যখন সার্ভার কিছু পাঠায় না। কার্যকর সংযোগে তিনটিই একই রকম দেখায়, তাই দ্বন্দ্ব দেরিতে প্রকাশ পায়। পার্থক্য দেখা যায় পুনঃসংযোগে, দ্বিতীয় ডিভাইসে এবং নীতি পরিবর্তনের পরে।

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

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

RADIUS উত্তর কী প্রতিশ্রুতি দিতে পারে এবং পারে না

RFC 2865Framed-IP-Address-কে ব্যবহারকারীর জন্য কনফিগার করার IPv4 ঠিকানা হিসেবে সংজ্ঞায়িত করে, এবং এটি Access-Accept-এ থাকে। Access-Request-এ একই অ্যাট্রিবিউট কেবল একটি ইঙ্গিত যা সার্ভার উপেক্ষা করতে পারে, এবং এটি গুরুত্বপূর্ণ যখন কোনো ক্লায়েন্ট বা গেটওয়ে পছন্দের ঠিকানা প্রস্তাব করে। প্রোটোকলে কিছুই গেটওয়েকে উত্তরটি মানতে বাধ্য করে না, কারণ নেটওয়ার্ক অ্যাক্সেস সার্ভারই সেই উপাদান যা এটি সেশনে প্রয়োগ করে।

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

গেটওয়ে যে উত্তর উপেক্ষা করে তা হুবহু এমন উত্তরের মতো দেখায় যা কখনো পাঠানো হয়নি। Access-Accept এবং সেশন ঠিকানা পাশাপাশি পড়াই দুই ক্ষেত্রে আলাদা করার একমাত্র উপায়।

আপনি ইতিমধ্যে যে পুল রাউট করেন তার ভিতরেই ঠিকানাটি সংরক্ষণ করুন

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

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

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

লিজে ভরসা করার আগে উত্তরটি পরীক্ষা করুন

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

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

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

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

একজন মালিক বেছে নিন এবং তা লিখে রাখুন

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

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