امنیت
دسته بندی:
آموزش اتصال چند کاربر همزمان به سرور
برای اتصال همزمان چند کاربر به یک سرور ویندوزی، باید نقش Remote Desktop Services روی سرور نصب و لایسنس RDS CAL تهیه شود؛ تغییر پالیسی Remote Desktop Session Host بهتنهایی محدودیت پیشفرض دو نشست مدیریتی را برنمیدارد. در لینوکس این موضوع اصلاً مسئله نیست، چون SSH از ابتدا چندنشستی است و به لایسنس اضافهای نیاز ندارد.
پیشفرض ویندوز سرور: دو نشست مدیریتی
ویندوز سرور بهصورت پیشفرض در حالتی به نام Remote Desktop for Administration کار میکند. در این حالت حداکثر دو نشست ریموت همزمان بهعلاوه نشست کنسول در دسترس است. این قابلیت برای مدیریت سرور طراحی شده، نه برای اینکه چند کاربر بهطور روزمره روی سرور کار کنند؛ به همین دلیل هم رایگان است و لایسنس جداگانه نمیخواهد.
وقتی نفر سوم تلاش کند وصل شود، پیام محدودیت تعداد اتصال را میبیند. این یک باگ نیست، محدودیت عمدی محصول است. همین محدودیت روی سرور مجازی هم دیده میشود؛ اتصال چند کاربر همزمان در سرور مجازی آن را جداگانه بررسی کرده است.
افزایش sessionهای Remote Desktop با gpedit: چه چیزی کار میکند و چه چیزی نه
رایجترین راهنمایی که درباره افزایش تعداد sessionهای ریموت دسکتاپ پیدا میکنید این است: gpedit.msc را باز کن، به شاخه Remote Desktop Session Host برو و تعداد connectionها را زیاد کن. مسیر این راهنما واقعی است و آن پالیسیها هم واقعاً وجود دارند، اما نتیجهای که وعده میدهد درست نیست: تا وقتی نقش RDS نصب نشده باشد، هیچ عددی در این پالیسیها سقف دو نشست مدیریتی را بالا نمیبرد.
مسیر پالیسی در ویرایشگر پالیسی محلی (اجرای gpedit.msc از پنجره Run یا کلید ویندوز بهعلاوه R) در نسخههای امروزی ویندوز سرور این است:
Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostConnections
دو تنظیم در این مسیر معمولاً با هم اشتباه گرفته میشوند:
- Restrict Remote Desktop Services users to a single Remote Desktop Services session: این پالیسی مثل هر پالیسی Administrative Templates سه حالت Not Configured و Enabled و Disabled دارد و هیچ فیلد عددی برای «تعداد» در آن نیست. اگر روی Disabled قرار بگیرد، یک کاربر میتواند بیش از یک نشست همزمان داشته باشد. این تنظیم تعداد کاربران مجاز را زیاد نمیکند، فقط اجازه میدهد یک حساب چند نشست جدا باز کند.
- Limit number of connections: این یکی فیلد عددی دارد؛ با فعال کردن آن و مقداردهی RD Maximum Connections allowed، سقف اتصالهای همزمان به RD Session Host تعیین میشود. اما این عدد فقط یک سقف است، نه یک مجوز: روی سروری که نقش RDS نصب نشده، وارد کردن عدد بزرگ در این فیلد سقف دو نشست مدیریتی را بالا نمیبرد.
به بیان ساده، این دو پالیسی تنظیمکننده رفتار سرویس هستند، نه مجوز آن. مجوز از جای دیگری میآید.
اگر با راهنمای قدیمی کار میکنید: شاخه Terminal Services
قبل از ویندوز سرور ۲۰۰۸ R2 نام این سرویس Terminal Services بود و مسیر پالیسی هم فرق داشت. اگر به آموزشی برخوردید که مسیر زیر را میگوید، آموزش برای نسخههای قدیمی نوشته شده است:
- ویندوز سرور ۲۰۰۳:
Computer ConfigurationAdministrative TemplatesWindows ComponentsTerminal Servicesو نام تنظیم مربوطه Restrict Terminal Services users to a single remote session است. این تنظیم هم فیلد عددی ندارد؛ اگر آموزشی گفته «عدد دلخواه را در آن وارد کنید»، آن آموزش اشتباه است و فیلد عدد فقط در Limit number of connections وجود دارد. - ویندوز سرور ۲۰۰۸:
Computer ConfigurationAdministrative TemplatesWindows ComponentsTerminal ServicesTerminal ServerConnectionsو در همین نسخه، همان پالیسی با نام کوتاهتر Restrict each user to a single session هم دیده میشود که معادل نسخه امروزی آن است. - ویندوز سرور ۲۰۰۸ R2 و بالاتر: همان مسیر Remote Desktop Services که بالاتر آمد.
نکته مهم این است که تغییر نام، رفتار را عوض نکرده؛ در نسخههای قدیمی هم این پالیسیها بهتنهایی محدودیت دو نشست را برنمیداشتند و نقش Terminal Server بهعلاوه لایسنس TS CAL لازم بود. ضمناً ویندوز سرور ۲۰۰۳ از جولای ۲۰۱۵ و ویندوز سرور ۲۰۰۸ و ۲۰۰۸ R2 از ژانویه ۲۰۲۰ دیگر بهروزرسانی امنیتی عمومی دریافت نمیکنند. اگر هنوز روی این نسخهها سرویس میدهید، مسئله فوریتر شما تعداد نشستها نیست، مهاجرت به نسخه پشتیبانیشده است.
اعمال تغییرات: gpupdate بهجای ریاستارت سرور
راهنماهای قدیمی معمولاً میگویند بعد از تغییر پالیسی، سرور را restart کنید. معمولاً لازم نیست. کافی است در Command Prompt یا PowerShell با دسترسی Administrator این دستور را اجرا کنید:
gpupdate /force
تغییر روی اتصالهای جدید اعمال میشود و نشستهای باز فعلی دستنخورده میمانند. اگر بعد از این دستور تغییری ندیدید، یک بار خروج و ورود دوباره را امتحان کنید و تنها در آخرین مرحله سراغ ریاستارت بروید؛ روی سروری که کاربران روی آن کار میکنند، ریاستارت بیدلیل هزینه دارد.
اگر سرور عضو دامنه است، این تنظیمات را بهجای gpedit.msc محلی از طریق Group Policy Management روی OU سرورهای RDS اعمال کنید. اگر پالیسی دامنه همین تنظیمها را مقداردهی کرده باشد، در اولین اعمال پالیسی، تنظیم محلی شما بازنویسی میشود و بدون هیچ خطای واضحی همه چیز به حالت قبل برمیگردد. برای دیدن اینکه در عمل کدام پالیسی برنده شده، gpresult /r یا rsop.msc را اجرا کنید.
راه درست و قانونی: نصب نقش RDS و تهیه CAL
برای پشتیبانی واقعی از چند کاربر همزمان، این مسیر را طی کنید:
- از Server Manager نقش Remote Desktop Services را نصب کنید. دو سرویس کلیدی آن RD Session Host (میزبانی نشستهای کاربران) و RD Licensing (سرور لایسنس) هستند.
- سرور لایسنس را Activate کنید و لایسنسهای RDS CAL را روی آن نصب کنید.
- در پالیسی، حالت لایسنس (Per User یا Per Device) و آدرس سرور لایسنس را مشخص کنید. Per Device به دستگاه و Per User به حساب کاربری تخصیص مییابد؛ انتخاب بین این دو به الگوی کار تیم شما بستگی دارد.
بعد از این مرحله است که پالیسی Limit number of connections معنا پیدا میکند و عددی که در آن میگذارید واقعاً سقف نشستهای همزمان را تعیین میکند.
پس از نصب نقش RD Session Host، یک دوره مهلت ۱۲۰ روزه وجود دارد که سرور بدون CAL کار میکند. بعد از پایان این مهلت، اتصالهای جدید رد میشوند. قیمت و شرایط تهیه CAL به کانال فروش و نوع لایسنس بستگی دارد و ثابت نیست.
راهاندازی نقش RDS، پیکربندی سرور لایسنس و نگهداری بعدی آن کار سبکی نیست و به وقت و دانش ویندوز سرور نیاز دارد. اگر ترجیح میدهید مدیریت فنی سرور را خودتان بر عهده نگیرید، سرور مدیریتشده سرویسی است که نصب نرمافزارها، نگهداری و رفع مشکلات فنی سرور توسط تیم فنی آنلاین سرور انجام میشود. تهیه لایسنس RDS CAL موضوعی جداست و به قوانین لایسنس مایکروسافت مربوط میشود؛ پیش از خرید، دامنه دقیق خدمات مدیریتشده را از پشتیبانی بپرسید.
یک هشدار صریح: روشهایی مثل دستکاری فایل termsrv.dll یا ابزارهای شبیهساز نشست، محدودیت را دور میزنند اما سه مشکل جدی دارند: نقض شرایط لایسنس مایکروسافت، شکستن بعد از هر آپدیت امنیتی ویندوز، و باز کردن سطح حمله روی یک کامپوننت حساس. روی سروری که چند کاربر روی آن کار میکنند، هیچکدام قابل پذیرش نیست. اگر بودجه لایسنس RDS ندارید، گزینه واقعبینانهتر انتقال بار کاری به لینوکس است، نه دور زدن لایسنس.
حساب کاربری جدا برای هر نفر
برای هر کاربر یک حساب مجزا بسازید و آن را عضو گروه Remote Desktop Users کنید. استفاده مشترک از یک حساب توسط چند نفر سه مشکل ایجاد میکند: تداخل روی پروفایل و فایلهای باز، غیرقابل ردیابی شدن لاگها، و ناممکن شدن اعمال دسترسی متفاوت برای افراد مختلف.
منابع سرور را متناسب با تعداد نشستها انتخاب کنید
هر نشست ریموت رم، پردازنده و I/O دیسک مصرف میکند. سروری که برای یک ادمین کافی بود، با پنج کاربر همزمان رفتار کاملاً متفاوتی دارد. پیش از افزودن کاربر، مصرف فعلی را در Task Manager و Performance Monitor بسنجید و بر همان اساس منابع را افزایش دهید.
برای تیمهای کوچک، یک سرور ابری با رم و پردازنده متناسب معمولاً پاسخگو است؛ پیش از خرید، میزان رم و پردازنده را بر اساس تعداد کاربران همزمان و سنگینی نرمافزارهایی که اجرا میکنند انتخاب کنید.
وقتی تعداد کاربران همزمان بالا میرود یا نرمافزارها سنگین هستند، رقابت بر سر پردازنده و I/O دیسک محسوس میشود. در این نقطه سرور فیزیکی اختصاصی انتخاب منطقیتری است، چون منابع بدون اشتراک با دیگران در اختیار شماست و رفتار عملکرد قابل پیشبینیتر میماند.
پایش و مدیریت نشستها
برای دیدن نشستهای فعال از دستور query user یا qwinsta استفاده کنید و با logoff <SessionID> نشست رهاشده را ببندید. نشستهای Disconnected بزرگترین عامل هدر رفتن منابع هستند؛ کاربر پنجره ریموت را میبندد اما نشست همچنان رم اشغال میکند. در همان شاخه Remote Desktop Session Host و این بار در زیرشاخه Session Time Limits (کنار Connections، نه داخل آن) میتوانید برای نشستهای بیکار و قطعشده مهلت مشخص تعیین کنید تا خودکار بسته شوند.
اگر با پیام محدودیت تعداد اتصال روبهرو شدید، پیش از هر تغییری اول qwinsta را اجرا کنید؛ در بسیاری از موارد یکی از دو نشست مجاز، نشست Disconnected یک نفر است که فقط پنجره را بسته و مشکل با یک logoff حل میشود، نه با تغییر پالیسی.
معادل لینوکسی: SSH از ابتدا چندکاربره است
در لینوکس نیازی به هیچ پالیسی یا لایسنسی برای اتصال همزمان نیست. برای هر نفر یک حساب بسازید (در Ubuntu و Debian با adduser که تعاملی است و خودش خانه کاربر و رمز را میسازد؛ در AlmaLinux و Rocky با useradd -m و سپس passwd)، دسترسی لازم را با sudo تنظیم کنید و همه میتوانند همزمان SSH بزنند. دو تنظیم مرتبط در /etc/ssh/sshd_config وجود دارد: MaxSessions که تعداد نشستهای چندگانه روی یک اتصال شبکه را محدود میکند و MaxStartups که سقف اتصالهای احرازهویتنشده همزمان را تعیین میکند. هیچکدام سقف تعداد کاربران نیستند.
اگر این دو مقدار را تغییر دادید، سرویس را با systemd بارگذاری مجدد کنید. نام سرویس بین توزیعها فرق میکند:
# AlmaLinux / Rocky / CentOS systemctl reload sshd # Ubuntu / Debian systemctl reload ssh
شکل قدیمی این کار یعنی service ssh restart یا /etc/init.d/ssh restart در بیشتر توزیعها هنوز به systemd هدایت میشود، اما شکل استاندارد امروز همان systemctl است؛ در هر دو حالت باید نام سرویس توزیع خودتان (ssh یا sshd) را بگذارید.
یک احتیاط ساده که جلوی قفل شدن بیرون سرور را میگیرد: پیش از هر کاری صحت فایل پیکربندی را با sshd -t (بهعنوان root) بررسی کنید و تا وقتی خطایی برنگشته سراغ اعمال تغییر نروید. بعد هم بهجای restart از reload استفاده کنید، چون اتصالهای فعال را قطع نمیکند. نشست SSH فعلی خود را باز نگه دارید و درستی تغییر را با یک اتصال جدید در پنجره دیگر امتحان کنید؛ اگر چیزی خراب شده باشد، هنوز یک نشست باز برای برگرداندن آن دارید.
برای دیدن کاربران متصل از w یا who استفاده کنید. اگر محیط گرافیکی لازم دارید، xrdp یا VNC نشست دسکتاپ جدا برای هر کاربر میسازند، هرچند مصرف منابع آن با نشست متنی قابل مقایسه نیست. برای کارهای طولانی هم tmux یا screen اجازه میدهند نشست بعد از قطع اتصال زنده بماند؛ کار با دومی در راهنمای دستور screen در لینوکس توضیح داده شده است.
مقایسه کوتاه
| موضوع | ویندوز سرور | لینوکس |
|---|---|---|
| حالت پیشفرض | ۲ نشست مدیریتی | چندنشستی بدون محدودیت تعریفشده |
| نیاز به لایسنس اضافه | بله، RDS CAL | خیر |
| پیشنیاز فنی | نصب نقش RDS | نصب و پیکربندی sshd |
| محیط گرافیکی همزمان | بومی از طریق RDP | با xrdp یا VNC |
نکات امنیتی که نباید نادیده گرفت
با افزایش تعداد کاربران، سطح حمله هم بزرگتر میشود. حداقلها: فعال نگه داشتن Network Level Authentication روی RDP، محدود کردن پورت ریموت به IPهای مشخص یا پشت VPN بهجای باز گذاشتن روی اینترنت (پیش از بستن پورت مطمئن شوید IP خودتان در فهرست مجاز است و یک راه دسترسی جایگزین مثل کنسول یا KVM دارید)، سیاست قفل حساب پس از چند تلاش ناموفق، و نصب بهموقع بهروزرسانیها. در لینوکس هم ورود با کلید بهجای رمز و غیرفعال کردن ورود مستقیم root دو گام ساده و مؤثر هستند. ترتیب این دو گام مهم است: اول یک کاربر غیر root با دسترسی sudo بسازید، کلید را روی آن نصب کنید و ورود با کلید را در یک نشست جدید تست کنید؛ فقط بعد از آنکه مطمئن شدید کار میکند، PermitRootLogin و PasswordAuthentication را ببندید. برعکس کردن این ترتیب رایجترین دلیل قفل شدن بیرون سرور است.
جمعبندی
تنظیم پالیسی Remote Desktop Session Host بخشی از کار است، اما نه همه آن؛ بزرگ کردن عدد در gpedit.msc روی سروری که نقش RDS ندارد، یک تغییر بیاثر است. اگر بیش از دو کاربر همزمان لازم دارید، مسیر درست نصب نقش RDS و تهیه CAL است. اگر بار کاری شما به ویندوز وابسته نیست، لینوکس همان نیاز را بدون لایسنس اضافه پوشش میدهد. در هر دو حالت، منابع سرور و تنظیمات امنیتی را متناسب با تعداد واقعی کاربران انتخاب کنید، نه با تعداد کاربرانی که امروز فعال هستند.
ارسال نظر