VPN গ্রুপে ব্যবহারকারী যোগ করলে নিজে থেকেই অ্যাক্সেস মেলে না
গ্রুপ সদস্যতা একটি শর্ত, অনুমতি নয়। গেটওয়ে আসলে কী মিলিয়েছে দেখুন, গ্রহণ বা প্রত্যাখ্যানের রেকর্ড পড়ুন, এবং দুই ফলাফলই পরীক্ষা করুন।
অ্যাকাউন্ট সঠিক গ্রুপে রেখেছেন, লগইন সফল হয়েছে, তবুও সংযোগ প্রত্যাখ্যাত হয় বা সংযোগ হয়ে কাজের কিছুতে পৌঁছায় না। স্বাভাবিক প্রতিক্রিয়া হলো কিছু নরম না হওয়া পর্যন্ত ব্যবহারকারীকে আরও গ্রুপে যোগ করা, আর এভাবেই প্রতিষ্ঠান টিকিটে চাওয়ার চেয়ে অনেক বেশি অনুমতি দিয়ে ফেলে। গ্রুপ সদস্যতা অনুমোদনের সিদ্ধান্তে একটি ইনপুট, কখনও সিদ্ধান্ত নিজে নয়: গেটওয়ে সেশন সম্পর্কে কয়েকটি তথ্য সংগ্রহ করে সাজানো নীতির সঙ্গে মিলিয়ে নেয়, তারপরেই ঠিক করে সেশনটি কী ছুঁতে পারবে। অন্য কোনো শর্ত ব্যর্থ হলে গ্রুপ বদলালে আপনার এক্সপোজার ছাড়া কিছুই বদলায় না।
গ্রুপ সদস্যতা একটি শর্ত, অনুমতি নয়
RADIUS-এ গ্রুপটি অনুমোদনের একটি অ্যাট্রিবিউট হিসেবে আসে, আর অ্যাট্রিবিউট সেশনকে বর্ণনা করে, অনুমতি দেয় না। সার্ভার Access-Accept বা Access-Reject দিয়ে উত্তর দেয়; গ্রহণ করলে এটি Filter-Id, Class বা RFC 2868-এর টানেল অ্যাট্রিবিউট যোগ করতে পারে, আর ওপাশের নেটওয়ার্ক সরঞ্জাম প্রস্তুতকারকের সিদ্ধান্ত অনুযায়ী সেগুলো ব্যাখ্যা করে। প্রোটোকলে গ্রুপকে পূর্ণ অ্যাক্সেসে বদলানোর কিছু নেই; সেই মিলন লেখেন গেটওয়ে বা নেটওয়ার্ক অ্যাক্সেস সার্ভারে নীতি সাজানো ব্যক্তি, আর তা একটি হোস্টের মতো সংকীর্ণ হতে পারে।
তাই একই গ্রুপের নাম দুই সিস্টেমে ভিন্নভাবে আচরণ করে। Microsoft NPS শর্ত, সীমাবদ্ধতা ও সেটিং থেকে নেটওয়ার্ক নীতি সাজিয়ে নির্দিষ্ট ক্রমে মূল্যায়ন করে। OpenVPN Access Server-এর নিজস্ব গ্রুপ ও অ্যাক্সেস নিয়মের মডেল আছে, আর কমিউনিটি OpenVPN সার্ভার প্রায়ই পুরো প্রশ্নটি client-connect স্ক্রিপ্ট বা client-config-dir ফাইলে ছেড়ে দেয়। প্রত্যেকে গ্রুপ ব্যবহার করে; কেউ অন্যের অগ্রাধিকার যুক্তি ভাগ করে না।
যে নিয়ম মিলেছে সেটিই ঠিক করে, আপনি যে গ্রুপ আশা করেছিলেন তা নয়
বেশিরভাগ ইঞ্জিন প্রথম মিলে যাওয়া নীতিতে বা সবচেয়ে নির্দিষ্টটিতে থেমে যায়। যদি নীতি 3 প্রত্যাখ্যান করে আর নীতি 7 অনুমতি দেয়, সেশনটি তাকে পার করতে পারত এমন নিয়মে না পৌঁছেই ব্যর্থ হতে পারে। ক্রম NPS এবং বেশিরভাগ নেটওয়ার্ক অ্যাক্সেস নিয়ন্ত্রণ পণ্যে বাস্তব সেটিং, আর বছরের পর বছর তা সরে যায়।
গ্রুপের সঙ্গে চলা শর্তগুলোই বাকি অর্ধেক। ডিভাইসের অবস্থা, প্রমাণীকরণ পদ্ধতি, MFA সম্পন্ন হওয়া, উৎস নেটওয়ার্ক, সার্টিফিকেটের বিষয় বা সময়ের জানালা একই নীতিতে থাকতে পারে। এর একটি অপূর্ণ থাকলে নীতি মেলে না, ইঞ্জিন নিচে নেমে যায়, আর ডিফল্ট প্রত্যাখ্যান কার্যকর হয়। ব্যবহারকারীর দিক থেকে গ্রুপ উপেক্ষিত মনে হয়; ইঞ্জিনের দিক থেকে গ্রুপকে জিজ্ঞাসাই করা হয়নি।
ডিরেক্টরির খুঁটিনাটি একই ভ্রম তৈরি করে। Windows গ্রুপ সদস্যতায় মেলা নীতি ব্যবহারকারীর টোকেনে থাকা SID পড়ে, আর সেখানে কেবল নিরাপত্তা গ্রুপ তালিকাভুক্ত হয়, বিতরণ গ্রুপ কখনও আসে না। ব্যবহারকারীর প্রাথমিক গ্রুপ আলাদা ক্ষেত্রে থাকে, তালিকায় নয়, তাই সেই গ্রুপে আটকানো নীতি নিঃশব্দে ব্যর্থ হতে পারে।
গ্রুপে হাত দেওয়ার আগে গ্রহণ বা প্রত্যাখ্যানের রেকর্ড পড়ুন
আগে একটি প্রশ্ন করুন: অনুরোধটি কি অনুমোদন পর্যায়ে পৌঁছেছিল? NPS-এ উত্তর ইভেন্ট লগে আছে, যেখানে 6272 অ্যাক্সেস দেওয়া, 6273 প্রত্যাখ্যান, আর 6274 নীতি মূল্যায়নের আগে সার্ভারের ফেলে দেওয়া অনুরোধ লিপিবদ্ধ করে। ওই তিন সংখ্যা সমস্যাটিকে তিনটি আলাদা তদন্তে ভাগ করে, আর তার একটিই গ্রুপ নিয়ে।
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
লগ নাগালে না থাকলে সার্ভারকে সরাসরি জিজ্ঞাসা করুন আর এটি যা ফেরত দেয় তা পড়ুন। Filter-Id ও টানেল অ্যাট্রিবিউট ছাড়া উত্তর বলে সার্ভার সেশনটিকে সাধারণ ভাবে আর গেটওয়ে নিজের নিয়ম খাটায়। প্রয়োগ বিন্দু যে অ্যাট্রিবিউট বাস্তবায়ন করে না তা-সহ উত্তর আলাদা ত্রুটি: অনুমোদন পেরিয়েছে, কিন্তু যে ডিভাইসের কাজ ছিল তা ফলাফল উপেক্ষা করেছে।
radtest alice 'password' 10.0.0.5 0 testing123ফেরত পাওয়া অ্যাট্রিবিউট গেটওয়ে যা নথিভুক্ত করে তার সঙ্গে মেলান, গ্রুপের নাম যা ইঙ্গিত দেয় তার সঙ্গে নয়। এই তুলনা সাধারণত নীতির সমস্যাকে প্রয়োগের সমস্যা থেকে আলাদা করে।
গ্রুপ বদল পিছনে কাজ করে না
অনুমোদনের অ্যাট্রিবিউট সেশন প্রমাণিত হওয়ার সময় একবারই ফেরত আসে। গেটওয়ে সেগুলো সেশনে রাখে আর প্রতিটি প্যাকেটে ডিরেক্টরি আবার পড়ে না, তাই কাউকে গ্রুপ থেকে সরানোর পরেও প্রতিষ্ঠিত সেশন চলতে থাকে, আর নতুন সেশন ব্যর্থ হতে পারে।
পরিবর্তন কার্যকর করতে নতুন অনুমোদন সিদ্ধান্ত দরকার, শুধু নতুন কী নয়। সার্ভার RFC 5176 গতিশীল অনুমোদন সমর্থন করলে UDP 3799-এ Disconnect-Request বা CoA-Request সেশনটিকে পুনর্মূল্যায়নে বাধ্য করে; নাহলে ক্লায়েন্ট বিচ্ছিন্ন করে আবার সংযোগ করতে দিন। পুনর্বিবাদ টানেল কী নবায়ন করে আর সাধারণত অনুমোদনের ফলাফল অক্ষত রাখে।
শর্ত ঠিক করুন, গ্রুপ নয়
কোন নীতি কাজ করেছে জানলে মেরামত সাধারণত ছোট: প্রত্যাশিত অনুমোদন ঢেকে রাখা প্রত্যাখ্যানের ক্রম বদলান, যে নীতিতে মেলাতে চেয়েছিলেন সেখানে অনুপস্থিত ডিভাইস বা MFA শর্ত যোগ করুন, অথবা ব্যবহারকারীকে আরও দশটি বহন করা গ্রুপে তোলার বদলে একটি সম্পদের জন্য সংকীর্ণ নিয়ম লিখুন।
ছোট লুপ পরিবর্তনটিকে সৎ রাখে:
- মূল অ্যাকাউন্টে প্রত্যাখ্যানটি পুনরুৎপাদন করুন আর কিছু বদলানোর আগে ইভেন্ট ID লিখে রাখুন।
- একটি বস্তু বদলান, নীতির ক্রম, একটি শর্ত বা একটি গ্রুপ, আর কোনটি বদলালেন তা লিখুন।
- নতুন সেশন খুলুন, লগে অনুমোদন দেখা যাচ্ছে এবং সম্পদটি সত্যিই খুলছে তা নিশ্চিত করুন।
- এমন ব্যবহারকারী পরীক্ষা করুন যাকে এখনও প্রত্যাখ্যান করা উচিত, যাতে মেরামত নীতিটি ভুলে প্রশস্ত না করে।
অনুমোদন ঠিক থাকলেও সম্পদ না খুললে, অনুমোদন সফল হওয়ার মুহূর্তেই সমস্যাটি রাউটিং বা নাম সমাধানে সরে গেছে। এই দুই ব্যর্থতা আলাদা রাখুন, পরের টিকিটে আধা দিনের বদলে মিনিট লাগবে।