RADIUS-এর Framed-IP-Address দিয়ে স্থিতিশীল VPN ক্লায়েন্ট ঠিকানা

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

ঠিকানাটি কোন স্তরের, তা নির্ধারণ করুন

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

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

একটি পরীক্ষামূলক অনুরোধ পাঠান এবং উত্তর পড়ুন

প্রথমে সার্ভারটিকে আলাদাভাবে পরীক্ষা করুন, যাতে অনুপস্থিত অ্যাট্রিবিউটকে গেটওয়ের সমস্যা ভুল না করা হয়। radtest একটি Access-Request পাঠায় এবং ফিরে আসা অ্যাট্রিবিউটগুলো ছাপে।

radtest alice 'S3cret' 127.0.0.1 0 testing123

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

গেটওয়ে মানটি মেনেছে কি না নিশ্চিত করুন

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

ip -4 addr show tun0

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

সমবর্তিতা ও প্রত্যাহারের পরিকল্পনা করুন

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

স্থিতিশীল ঠিকানা-বিন্যাস নিয়ম ও লগ সহজ করে, কিন্তু প্যাকেট কে তৈরি করেছে তা কখনও প্রমাণ করে না। ওই ঠিকানাটি পরে অন্য সেশনে গেলে প্রমাণীকরণ ও গন্তব্য-অনুমোদন তবুও গুরুত্বপূর্ণ।