একটি VPN লগইন কীভাবে RADIUS ও আপনার পরিচয় প্রদানকারীর কাছে পৌঁছায়
ক্লায়েন্ট থেকে গেটওয়ের RADIUS অনুরোধ, তার পেছনের পরিচয় প্রদানকারী এবং গ্রহণের পরে প্রয়োগ করা নীতিমালা পর্যন্ত একটি VPN সাইন-ইন অনুসরণ করুন।
গত সপ্তাহে একজন ব্যবহারকারী VPN-এ সাইন ইন করতে পারলেন, তবুও এমন নেটওয়ার্কে গিয়ে পড়লেন যেখানে কিছুই রিজলভ হচ্ছিল না। ক্লায়েন্ট বলল সংযুক্ত, গেটওয়ে লগ বলল Access-Accept, আর পরিচয় দল বলল অ্যাকাউন্ট ঠিক আছে। লগইন কাজ করেছিল; তার পেছনের অনুমোদন করেনি। যখন একটি VPN সাইন-ইন ব্যর্থ হয়, আমি অনুরোধটি যে পথে আসলে যায় সেটি হাঁটি — ক্লায়েন্ট, গেটওয়ে, RADIUS সার্ভার, পরিচয় প্রদানকারী — এবং যে প্রথম ধাপের উত্তর পরেরটির সঙ্গে মেলে না সেখানে থামি।
ক্লায়েন্ট কখনো RADIUS বলে না
ল্যাপটপের অ্যাপ যা-ই দেখাক, তার প্রথম ধাপ হল VPN প্রোটোকল: IKEv2, OpenVPN, WireGuard বা TLS-ভিত্তিক ক্লায়েন্ট। RADIUS সেই বিনিময়ে উপস্থিত হয় না। ক্লায়েন্ট গেটওয়ের কাছে প্রমাণপত্র, ব্যবহারকারীর নাম ও পাসওয়ার্ড, বা টানেল সেটআপের ভেতরে বহন করা EAP পদ্ধতি দিয়ে প্রমাণিত হয়।
লগ পড়ার সময় এটি গুরুত্বপূর্ণ, কারণ ব্যবহারকারী যে সাধারণ প্রমাণীকরণ ত্রুটি দেখেন তা গেটওয়ে তৈরি করে, অন্য কিছুর সঙ্গে কথা বলার পরে। ক্লায়েন্ট যদি কখনোই গেটওয়ে পর্যন্ত না পৌঁছায়, তাহলে ডিবাগ করার মতো কোনো RADIUS অনুরোধ নেই, আর RADIUS সার্ভারে ব্যয় করা এক ঘণ্টা বৃথা যায়। ব্যাকএন্ড স্পর্শ করার আগে টানেল আদৌ উঠেছে কি না নিশ্চিত করুন।
গেটওয়েই RADIUS ক্লায়েন্ট
টানেল সেটআপ যখন সেই বিন্দুতে পৌঁছায় যেখানে প্রমাণপত্র যাচাই করতে হবে, গেটওয়ে একটি নেটওয়ার্ক অ্যাক্সেস সার্ভারে পরিণত হয়। এটি একটি Access-Request তৈরি করে: User-Name, একটি পাসওয়ার্ড বা EAP পেলোড, NAS-IP-Address বা NAS-Identifier, এবং পদ্ধতি চাইলে একটি Message-Authenticator। অনুরোধটি ডিফল্টভাবে UDP 1812-তে যায়, আর অ্যাকাউন্টিং 1813-তে। পুরোনো স্থাপনা এখনো 1645 ও 1646 ব্যবহার করে, তাই এক জোড়ার জন্য লেখা ফায়ারওয়াল নিয়ম অনেক নীরব ব্যর্থতার ব্যাখ্যা দেয়।
দুই পক্ষ একটি গোপন তথ্য ভাগ করে, এবং তা কোনো ব্যবহারকারীর প্রমাণপত্র নয়। এটি বিনিময়টি স্বাক্ষর করে, এবং প্রতিটি উত্তর তার বিরুদ্ধে যাচাই হয়। দুই পক্ষে গোপন তথ্য ভিন্নভাবে কনফিগার করুন আর সার্ভার ভুল গোপন তথ্য বলে উত্তর দেয় না — এটি অনুরোধটি ফেলে দেয় বা উত্তরের যাচাই ব্যর্থ হয়, ফলে গেটওয়ে টাইমআউট জানায়। ভুল গোপন তথ্য আর মৃত সার্ভার গেটওয়ে থেকে একই রকম দেখায়, তাই ডিরেক্টরিকে দোষ দেওয়ার আগে আমি ক্লায়েন্ট টুল দিয়ে ধাপটি পরীক্ষা করি।
প্রোটোকলটি ছোট ও পুরোনো — RFC 2865 প্রমাণীকরণ বিনিময় সংজ্ঞায়িত করে — কিন্তু এটি যে বৈশিষ্ট্যগুলো বহন করে সেগুলোই বেশিরভাগ VPN নীতিমালার ভিত্তি।
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS সার্ভার শুধু পরিচয় প্রদানকারীর সামনের অংশ হতে পারে
লোকে RADIUS আর পরিচয় প্রদানকারীকে একই বাক্স বলে ধরে নেয়। প্রায়ই তা নয়। RADIUS সার্ভার Access-Request পায়, তারপর উত্তর দেওয়ার আগে অন্য কিছুকে জিজ্ঞাসা করে — LDAP বা Kerberos-এর মাধ্যমে Active Directory, একটি স্থানীয় ব্যবহারকারী ফাইল, বা একটি বহিরাগত সেবা। LDAP বা krb5 মডিউলসহ FreeRADIUS, Windows NPS এবং Cisco ISE সবাই এই অবস্থানে বসে।
এই পার্থক্যই ঠিক করে আপনি কোথায় দেখবেন। প্রত্যাখ্যাত পাসওয়ার্ড হলো RADIUS-এর মাধ্যমে পৌঁছে দেওয়া পরিচয় প্রদানকারীর উত্তর। টাইমআউট সাধারণত RADIUS থেকে ডিরেক্টরি পর্যন্ত অংশ: মেয়াদোত্তীর্ণ বাইন্ড অ্যাকাউন্ট, অপ্রাপ্য ডিরেক্টরি, বা ভুল ব্যাকএন্ডে পাঠানো অনুরোধ। ব্যবহারকারীর নামে ডোমেইন প্রত্যয় থাকলে সার্ভার তার ভিত্তিতে রুট করতে পারে, আর CORP\alice ও [email protected] হিসেবে পাঠানো একই অ্যাকাউন্ট ভিন্ন জায়গায় পৌঁছাতে পারে। Windows NPS-এ Security লগ অনুমোদনের জন্য 6272 এবং প্রত্যাখ্যানের জন্য 6273 লেখে, যা বলে দেয় সিদ্ধান্ত আদৌ NPS থেকে এসেছিল কি না।
যে ধাপে ব্যর্থতা তৈরি হয়েছে সেখানেই তা পড়ুন
একটি সংযোগ-করা-যায়-না বার্তা চারটি ভিন্ন ব্যর্থতা ঢেকে রাখে। কিছু বদলানোর আগে উপসর্গটিকে যে ধাপে তা তৈরি হয়েছে তার সঙ্গে মেলান।
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
শেষ সারিটিই মানুষকে ভুল দলের কাছে পাঠায়। Access-Accept মানে প্রমাণপত্র গৃহীত হয়েছে; এর মানে নয় যে গেটওয়ে ব্যবহারকারীকে সঠিক পুলে বসিয়েছে বা রুট ঠেলে দিয়েছে। গ্রুপ বৈশিষ্ট্য কেবল তখনই গুরুত্বপূর্ণ যখন গেটওয়ে নীতিমালা সেগুলো পড়ে। আমি দেখেছি সঠিক লগইন গেস্ট পুলে পড়ছে, কারণ RADIUS-এর দিকে গ্রুপ ম্যাপিং গেটওয়ে যে বৈশিষ্ট্য দেখে তার চেয়ে ভিন্ন বৈশিষ্ট্যের জন্য কনফিগার করা ছিল।
একটি লগইন শুরু থেকে শেষ পর্যন্ত অনুসরণ করুন
একটি পরীক্ষামূলক অ্যাকাউন্ট আর একটি গেটওয়ে বেছে নিন, তারপর একই প্রচেষ্টা চারটি বিন্দুতে দেখুন। RADIUS-এর দিকে একটি ডিবাগ রান শুরু করুন — freeradius -X অনুরোধটি এবং এটি যে প্রতিটি মডিউলে হাত দেয় তা ছাপে — গেটওয়ের প্রমাণীকরণ লগ অনুসরণ করুন, আর UDP বিনিময়ের জন্য tcpdump চালান। একবার সংযুক্ত হয়ে চারটি ট্রেস ক্রমানুসারে পড়ুন।
আপনি যা দেখতে চান তা হলো মিল: গেটওয়ে আপনার প্রত্যাশিত ব্যবহারকারীর কথা জিজ্ঞেস করেছে, RADIUS সার্ভার আপনার প্রত্যাশিত ব্যাকএন্ড বেছে নিয়েছে, সেই ব্যাকএন্ড একটি সিদ্ধান্ত ফিরিয়েছে, আর উত্তরের বৈশিষ্ট্যগুলো গেটওয়ে যে নীতিমালা প্রয়োগ করে তার সঙ্গে মেলে। ট্রেসগুলো প্রথম যেখানে অমিল হয় সেটিই আপনার ত্রুটিরেখা। উত্তরে কোনো গ্রুপ বৈশিষ্ট্য না থাকলে সমস্যা VPN প্রোফাইলে নয়, RADIUS-এর দিকে; বৈশিষ্ট্য থাকলে এবং গেটওয়ে তা উপেক্ষা করলে সমস্যা গেটওয়ে নীতিমালায়।
সেখানে থাকতে একটি নিরাপত্তা নোট। ভাগ করা গোপন তথ্য বিনিময় রক্ষা করে, কিন্তু এটি বেশিরভাগ বৈশিষ্ট্য এনক্রিপ্ট করে না। গেটওয়ে ও RADIUS সার্ভার ভিন্ন সেগমেন্টে থাকলে সেই ধাপটি TLS-এর উপর RADIUS বা একটি ব্যক্তিগত পথে রাখুন। এনক্রিপ্টেড ব্যবহারকারী টানেল ব্যাকএন্ড লিঙ্ক সম্পর্কে কিছুই বলে না।
টিকিট বন্ধ করার আগে চারটি বিষয় নিশ্চিত করুন। গেটওয়ে যে পোর্টের জন্য আসলে কনফিগার করা, সেই পোর্টে RADIUS সার্ভারে পৌঁছাতে পারে। ভাগ করা গোপন তথ্য দুই পক্ষে মেলে। RADIUS সার্ভার গেটওয়ে যে সঠিক ব্যবহারকারীর নামের রূপ পাঠায় তা রিজলভ করে। গ্রহণে গেটওয়ে নীতিমালার প্রয়োজনীয় বৈশিষ্ট্যগুলো থাকে। চারটিই ঠিক থাকলে, তবুও ব্যর্থ একটি লগইন প্রমাণীকরণের নয়, গেটওয়ে নীতিমালার সমস্যা।