রিমোট ডেস্কটপ অধিকার ছাড়া VPN অ্যাক্সেস: চারটি আলাদা দরজা

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

চারটি দরজা নির্দিষ্ট ক্রমে থাকে

গেটওয়ে প্রথমে সিদ্ধান্ত নেয় পরিচয়টি আদৌ একটি টানেল স্থাপন করতে পারবে কি না: RADIUS নীতি, গ্রুপ শর্ত, সার্টিফিকেট পরীক্ষা, Access Server অনুমতি। তারপর রাউটিং ও ফায়ারওয়াল সিদ্ধান্ত নেয় টানেল পুল থেকে আসা প্যাকেট গন্তব্যের TCP 3389 শ্রোতায় পৌঁছায় কি না। তারপর ক্লায়েন্টের NLA হ্যান্ডশেক গন্তব্যের কাছে অ্যাকাউন্টটি প্রমাণ করে। এই তিনটির পরেই স্থানীয় নিরাপত্তা কর্তৃপক্ষ দেখে অ্যাকাউন্টটির কাছে ইন্টারঅ্যাকটিভ দূরবর্তী সেশনের প্রয়োজনীয় লগন অধিকার আছে কি না।

ক্রমটি নির্দিষ্ট হওয়ায় প্রতিটি দরজা তার পেছনের দরজাগুলো লুকায়। ব্যর্থ টানেল রাউটিং সম্পর্কে কিছু বলে না; বন্ধ পোর্ট লগন অধিকার সম্পর্কে কিছু বলে না; সফল পোর্ট পরীক্ষা প্রবেশাধিকার সম্পর্কে কিছু বলে না। তাই “VPN কাজ করে কিন্তু RDP করে না” একক সমস্যা নয়, এই দরজাগুলোর দুটির মধ্যে একটি সীমা, এবং তাই ত্রুটি বার্তাটি কোনটিতে আপনি ধাক্কা খেয়েছেন তা জানার দ্রুততম উপায়।

যে অধিকারটি আসলে সেশন প্রত্যাখ্যান করে

রিমোট ডেস্কটপে সাইন-ইন করতে ব্যবহারকারী অধিকার রিমোট ডেস্কটপ পরিষেবার মাধ্যমে লগ অনের অনুমতি দিন, অর্থাৎ SeRemoteInteractiveLogonRight প্রয়োজন। এটি লগনের সময় যাচাই হয়, টানেল স্থাপনের সময় নয়, তাই একটি অ্যাকাউন্ট ঘণ্টার পর ঘণ্টা নেটওয়ার্ক ঘুরে বেড়িয়েও ডেস্কটপ থেকে বঞ্চিত হতে পারে। এটি দেখানো ডায়ালগটি «স্থানীয় নীতি», «ব্যবহারকারী অধিকার নির্ধারণ»-এ থাকে, আর ডোমেইন সমতুল্যটি থাকে GPO-তে।

ডিফল্ট সদস্যপদ মেশিনের ভূমিকার উপর নির্ভর করে: ওয়ার্কস্টেশন ও সদস্য সার্ভার এটি Administrators ও Remote Desktop Users-কে দেয়, আর ডোমেইন কন্ট্রোলার কেবল Administrators-কে। এই একটি তথ্যই বেশিরভাগ বিভ্রান্তির ব্যাখ্যা, কারণ একই অ্যাকাউন্ট ফাইল সার্ভারে সফল হয় আর DC-তে ব্যর্থ হয়। গ্রুপ সদস্যপদ নির্বিশেষে প্রত্যাখ্যান অধিকার সংশ্লিষ্ট অনুমতি অধিকারকে হারিয়ে দেয়, তাই যে অ্যাকাউন্টকে একসাথে অনুমতি ও প্রত্যাখ্যান দেওয়া হয় তাকে প্রত্যাখ্যান করা হয়। একটি বিস্তৃত প্রত্যাখ্যান গ্রুপ উপকারের জন্য যোগ করা প্রশাসককেও ধরতে পারে।

কার্যকর নীতি পড়ুন, স্থানীয় ডায়ালগ নয়

স্থানীয় নীতি একই অধিকার নির্ধারণকারী যেকোনো ডোমেইন GPO দ্বারা প্রতিস্থাপিত হয়, তাই স্থানীয় স্ন্যাপ-ইন সঠিক দেখতে একটি তালিকা দেখাতে পারে অথচ কার্যকর অবস্থা ভিন্ন। মেশিনটি আসলে যা প্রয়োগ করে তা এক্সপোর্ট করুন, তারপর অধিকারটি খুঁজুন এবং প্রদর্শিত নামের বদলে SID পড়ুন:

secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v

সেই আউটপুটে *S-1-5-32-544 হলো Administrators এবং *S-1-5-32-555 হলো Remote Desktop Users।

যদি কোনোটিই না দেখায়, স্থানীয় ব্যবহারকারী ও গ্রুপ ডায়ালগ যা-ই প্রস্তাব করুক, নীতি ধারক ছাড়া কেউ ডেস্কটপ খুলতে পারবে না। তখন gpresult কোন GPO জিতেছে তা নাম দেয়, এবং সেটিই আপনার সম্পাদনা করা উচিত বস্তু; ডোমেইন-সংযুক্ত মেশিনে স্থানীয় নীতি বদলানো একটি পরীক্ষা, সমাধান নয়।

যে সংকীর্ণতম অধিকার যথেষ্ট সেটি দিন

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

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"

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

নেটওয়ার্ক পথকে আলাদা সিদ্ধান্ত রাখুন

VPN গ্রুপকে প্রতিটি পোর্টে পৌঁছাতে হয় না। যখন একটি গ্রুপের ডেস্কটপ নয়, একটি অ্যাপ্লিকেশন দরকার, টানেল পুল ও অ্যাপ্লিকেশন পোর্টে সীমাবদ্ধ একটি ফায়ারওয়াল নিয়ম সেই নীতিকে কার্যকর করে, আর লগন অধিকার অপরিবর্তিত থাকে।

Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389

OpenVPN-এর নিজস্ব প্রতি-ক্লায়েন্ট কনফিগারেশন ও Access Server গ্রুপ অনুমতি একই চেতনায় গন্তব্য প্রিফিক্স সীমিত করতে পারে; এর কোনোটিই Windows লগন অধিকার দেয় না, আর লগন অধিকার পোর্ট খুলতে পারে না। এগুলো পৃথক পরিবর্তন উইন্ডোতে রাখুন, কারণ পোর্ট নিয়ম ও অধিকার ভিন্ন মানুষ অনুমোদন করেন।

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