Изграждане на сървър за отдалечен работен плот: Настройка, Сигурност и Масштабиране

Въведение

Разгръщането на услуги за отдалечен работен плот може да реши проблемите с отдалечената работа, централизацията на приложенията и достъпа на трети страни в една платформа. Въпреки това, RDS може да се провали бързо, когато лицензите, сертификатите или контролите за сигурност са неправилно конфигурирани. Тази статия се фокусира върху ясни решения и безопасни настройки по подразбиране, които можете да приложите незабавно. Ще завършите с план за изграждане, който можете да документирате и поддържате.

Какво е сървър за отдалечен работен плот в термини на Windows?

RDS срещу стандартен Remote Desktop

Windows Pro Remote Desktop е функция за един на един за една машина. Сървърът за отдалечен работен плот обикновено е Windows Server Remote Desktop Services (RDS), който поддържа много едновременни потребители. RDS също добавя централни политики, контрол на сесиите и лицензиране. Тази разлика е важна за поддръжката и съответствието.

RDS ролите, които имат значение

Повечето реални внедрения използват малък набор от услуги за роли:

• RD Session Host: управлява потребителски сесии и RemoteApps (публикувани приложения).
• RD Connection Broker: проследява сесиите и надеждно свързва отново потребителите.
• RD Web Access: предоставя портал за приложения и настолни компютри.
• RD Gateway: обвивки RDP вътре в HTTPS за по-безопасен достъп до интернет.
• RD лицензиране: управлява клиентските лицензи за достъп до RDS (CALs).

Можете да комбинирате роли в малки среди, но производствените проекти обикновено разделят поне хостовете на сесии и шлюза. Разделянето на роли не е само въпрос на производителност.

Стъпка 1: Планирайте дизайна на вашия RDS

Топология: един сървър срещу много сървъри

Едносерверната конфигурация може да работи за лаборатория или малък офис с ниска едновременност. За продукция, отделете ролите, за да намалите прекъсванията и да опростите отстраняването на проблеми. Често срещаното разделение е един сървър за Broker, Web и Лицензиране, и един или повече сървъри за Session Host. Ако външни потребители се свързват, поставете RD Gateway на собствен сървър, когато е възможно.

Размери: CPU, RAM, съхранение, мрежа

Планирането на капацитета е мястото, където потребителското изживяване се печели или губи. Интерактивните приложения нарастват по време на влизане и стартиране на приложения, така че размерът трябва да има практични приоритети:

• CPU: предпочитайте по-висока тактова честота за отзивчивост на сесията
• RAM: планирайте за пикова едновременност, за да избегнете страничене
• Съхранение: SSD за намаляване на латентността на профила и приложението I/O
• Мрежа: приоритизирайте ниската латентност пред суровата честотна лента

Натиск върху паметта причинява бавни сесии и случайни неуспехи, затова планирайте за пикова конкуренция. SSD съхранението намалява времето за зареждане на профила и подобрява последователността на влизането. Пътищата с ниска латентност обикновено са по-важни от чистата пропускателна способност.

Модел на достъп: вътрешен, VPN или интернет

Решете как потребителите ще достигат до услугата, преди да инсталирате роли. Достъпът само за вътрешни потребители е най-прост и намалява излагането. Достъпът чрез VPN добавя контролен слой, но изисква управление на клиентите. Достъпът до интернет трябва да използва RD Gateway през HTTPS, за да избегнете излагането. порт 3389 Това едно решение предотвратява много инциденти със сигурността.

Ако трябва да поддържате неуправляеми устройства, планирайте по-строги контроли и по-ясни граници. Отнасяйте се към интернет достъпа като към продукт, а не като към отметка, с отговорност за идентичността, сертификатите и мониторинга.

Стъпка 2: Подгответе Windows Server за RDS

Патч, основна линия и администраторски достъп

Патчвайте Windows Server напълно, преди да добавите RDS роли, и поддържайте предсказуем цикъл на актуализации. Прилагайте стандарт за базово укрепване, който съответства на вашата среда. Използвайте ясни административни граници:

• Разделете привилегированите администраторски акаунти от ежедневните потребителски акаунти
• Администратор само от управляван хост за скок (не от крайни точки)
• Ограничете членството на местни администратори и редовно проверявайте промените.

DNS имена и позиция на защитната стена

Изберете името на DNS, което е видимо за потребителите, рано и го поддържайте последователно в инструментите и сертификатите. Планирайте правилата за защитната стена с мислене за "най-малко излагане". За внедрявания, насочени към интернет, целете да изложите само TCP 443 към портала. Дръжте TCP 3389 затворен за публичния интернет.

Изисквания за изграждане: присъединяване към домейн и служебни акаунти (когато е необходимо)

Повечето внедрения на RDS в производствени среди са присъединени към домейн, тъй като контролът на достъпа на базата на групи и GPO са централни за управлението. Присъединете сървърите към правилния AD домейн рано, след това валидирайте синхронизацията на времето и разрешаването на DNS. Ако използвате служебни акаунти за агенти за мониторинг или инструменти за управление, създайте ги с минимални права и документирайте собствеността.

Стъпка 3: Инсталирайте роли на Remote Desktop Services

Стандартно разгръщане с Server Manager

Използвайте пътя за инсталиране на Remote Desktop Services в Server Manager за чиста настройка. Изберете внедряване на работен плот на базата на сесии за много потребителски работни плотове и RemoteApps. Назначете услуги на роля въз основа на плана за топология, а не на удобство. Документирайте къде е инсталирана всяка роля, за да опростите бъдещите ъпгрейди.

Правила за разпределение на роли и разделяне

Разпределението на ролите оформя производителността и скоростта на отстраняване на проблеми. Съвместното разполагане на всичко може да работи, но също така скрива тесните места, докато натоварването на потребителите се увеличава. Разделянето на ролевите функции от изчислителните роли улеснява изолирането на прекъсванията и намалява риска за сигурността.

• Съвместно разположение на роли само за лабораторни или много малки внедрения
• Дръжте RD Gateway изключен от хост сесия за достъп, насочен към интернет.
• Добавете хостове на сесии хоризонтално вместо да увеличавате размера на един хост
• Използвайте последователно именуване на сървъри, за да бъдат логовете лесни за проследяване.

Проверки след инсталация

Проверете платформата, преди да добавите потребители. Потвърдете, че услугите работят и са настроени да стартират автоматично. Тествайте RD Web Access вътрешно, ако сте го внедрили. Направете тестово свързване с хоста на сесията и потвърдете, че създаването на сесия работи. Поправете всички грешки сега, преди да добавите сертификати и политики.

Добавете кратък списък за проверка на валидността, който можете да повтаряте след всяка промяна. Той трябва да включва тест за свързаност, тест за стартиране на приложението и проверка на логовете за нови предупреждения. Повторението е това, което превръща RDS от "крив" в "предсказуем".

Стъпка 4: Конфигуриране на RD лицензиране

Активирайте, добавете CALs, задайте режим

Инсталирайте ролята RD Licensing, след това активирайте лицензионния сървър. Добавете вашите RDS CALs и изберете правилния лицензионен режим: на потребител или на устройство. Приложете лицензионния сървър и режима към средата на Session Host. Отнасяйте се към това като към необходима стъпка, а не като към по-късна задача.

Проверете дали лицензът е приложен

Проблемите с лицензиране често се появяват след гратисен период, което ги прави трудни за проследяване. Проверете Преглед на събитията на хост сесия за предупреждения за лицензиране. Потвърдете, че хостът на сесията може да достигне лицензирания сървър през мрежата. Проверете дали режимът съвпада с типа CAL, който всъщност притежавате. Заснемете екранни снимки за документацията на вашата версия.

• Потвърдете, че лицензиращият сървър е достъпен от всеки хост на сесия.
• Потвърдете, че режимът на лицензиране е приложен, където се изпълняват сесиите.
• Прегледайте логовете, свързани с RDS, за предупреждения преди включване на потребителя.
• Пре-тест след промени в GPO, които могат да заменят настройките на RDS

Модели на неуспех при лицензиране за ранно откриване

Повечето лицензионни "изненади" могат да бъдат предотвратени. Проблемите често произтичат от несъответстващ тип CAL и лицензионен режим, лицензионен сървър, който е инсталиран, но никога не е активиран, или хост на сесия, който не може да открие лицензионния сървър поради промени в DNS или защитната стена.

Създайте едно просто правило в процеса си: не преминавайте от пилотен до производствен етап, докато лицензионните журнали не са чисти под натоварване. Ако вашата версия премине тестовете за максимален брой входове и все още не показва предупреждения за лицензиране, вие сте елиминирали основен клас бъдещи прекъсвания.

Стъпка 5: Публикувайте работни станции и RemoteApps

Сесийни колекции и потребителски групи

Сесийната колекция е именувана група от хостове на сесии и правила за достъп на потребители. Използвайте групи за сигурност, а не индивидуални назначения на потребители за чиста администрация. Създавайте отделни колекции, когато натоварванията се различават, като "Офис потребители" и "ERP потребители". Това прави настройването на производителността и отстраняването на проблеми по-предсказуеми.

Добавете ясна връзка между колекциите и бизнес резултатите. Когато потребителите знаят коя колекция поддържа кои приложения, екипите за помощ могат по-бързо да насочват проблемите. Дизайнът на колекцията е също така мястото, където задавате последователни ограничения на сесиите и правила за пренасочване.

Основи на публикуването на RemoteApp

RemoteApps намаляват триенето между потребителите, като предоставят само това, от което се нуждаят, а платформите като TSplus Remote Access може да опрости публикуването и уеб достъпа за екипи, които искат по-малко подвижни части. Те също така ограничават повърхността на атака на „пълния работен плот“, когато потребителите изискват само едно или две приложения. Публикуването обикновено е просто, но надеждността зависи от тестването на пътищата за стартиране на приложения и зависимостите.

• Тествайте всяко RemoteApp с обикновен потребител, а не с администраторски акаунт.
• Проверете асоциациите на файловете и необходимите помощни компоненти
• Потвърдете изискванията за принтер и клипборд, преди да наложите ограничения.
• Документирайте поддържаните типове и версии на клиенти

Профили и основи на скоростта на влизане

Бавните влизания често произтичат от размера на профила и стъпките за обработка на профила. Започнете с ясна стратегия за профила и я поддържайте проста. Тествайте времето за влизане с реални данни на потребители, а не с празни акаунти. Следете продължителността на влизането рано, за да можете да забележите регресии след промени.

Поставете ограничения преди да мащабирате. Определете лимити за размера на профила, процеси за почистване на временни данни и как обработвате кеширани удостоверения и състояние на потребителя. Много инциденти с "производителност" всъщност са инциденти с "разширяване на профила".

Стъпка 6: Осигурете външен достъп с RD Gateway

Защо HTTPS превъзхожда открития RDP

RD Gateway тунелира трафика на Remote Desktop през HTTPS на порт 443. Това намалява директната експозиция на RDP и ви дава по-добра точка за контрол. Също така подобрява съвместимостта с ограничени мрежи, където е разрешен само HTTPS. За повечето екипи това е най-безопасният по подразбиране вариант за външен достъп.

Политики, сертификати и опции за MFA

Използвайте политики на шлюза, за да контролирате кой може да се свързва и до какво може да получи достъп. Свържете сертификат, който съвпада с вашето външно DNS име и е доверен от потребителските устройства. Ако е необходима многофакторна автентикация, наложете я на шлюза или чрез пътя на вашия доставчик на идентичност. Дръжте правилата на групова основа, за да останат прегледите на достъпа управляеми.

• Използвайте CAP/RAP политики, свързани с групи за сигурност на AD
• Ограничете достъпа до специфични вътрешни ресурси, а не до цели подсистеми.
• Налагайте MFA за външен достъп, когато бизнес рискът го оправдава.
• Регистрирайте събития за удостоверяване и авторизация за одити

Укрепване на шлюза и ръбовия слой

Третирайте RD Gateway като приложение сървър, достъпно от интернет. Поддържайте го актуализиран, минимизирайте инсталираните компоненти и ограничете пътищата за достъп на администратори. Деактивирайте слаби наследствени настройки, от които нямате нужда, и наблюдавайте за поведение на брутфорс. Ако вашата организация разполага с реверсивен прокси на ръба или WAF стратегия, синхронизирайте разгръщането на портала с нея.

Накрая, репетирайте действията за реагиране при инциденти. Знайте как да блокирате потребител, да сменяте сертификати и да ограничавате достъпа по време на предполагаема атака. Тези действия са много по-лесни, когато сте ги планирали.

Стъпка 7: Настройка на производителността и надеждността

Настройки на GPO, които намаляват натоварването на сесията

Използвайте Групова политика, за да намалите ненужното натоварване, без да нарушавате работните потоци. Ограничете неактивните сесии и задайте тайм-аут за прекъсване, за да освободите ресурсите безопасно. Контролирайте пренасочването на клипборда и дисковете в зависимост от чувствителността на данните. Прилагайте промените на малки стъпки, за да можете да измервате въздействието.

Сигнали за наблюдение за проследяване на ранни

Наблюдавайте CPU, паметта и латентността на диска на хостовете на сесии от първия ден. Следете времето за влизане и тенденциите в броя на сесиите през седмицата. Наблюдавайте неуспехите на удостоверяването на шлюза за модели на брутфорс. Настройте известия за насищане на ресурсите, а не само за събития на падане на сървъра. Добро наблюдение предотвратява "изненадващи понеделници." Започнете с малък базов набор.

• Тенденции на продължителността на влизане (медиана + най-лошите 10%)
• Налягане на паметта на хоста на сесията по време на пикови часове
• Дискова латентност на профили и пътища на приложения
• Неуспешни влизания в RD Gateway и необичайни върхове

Оперативна стабилност: прозорци за корекции и промяна на темпото

Производителността зависи от оперативната дисциплина. Определете времеви прозорци за поддръжка на хостове на сесии и сървъри на шлюза, след което ги комуникирайте на потребителите. Използвайте етапни разпространения, при които първо се актуализира един хост на сесия, а след това останалите. Този подход намалява риска от широко разпространено прекъсване поради лоша актуализация или актуализация на драйвери.

Също така определете какво означава "възстановяване" във вашата среда. За виртуални машини, моментните снимки могат да помогнат, но само когато се използват внимателно и за кратко. За физически системи, възстановяването може да означава възстановяване на златен образ или премахване на наскоро направена промяна чрез автоматизация.

Стъпка 8: Чести проблеми при изграждането и пътища за корекция

Сертификати, DNS, защитна стена и NLA

Сертификатните грешки обикновено произтичат от несъответствия в имената или липсващи вериги на доверие. Проблемите с DNS се проявяват като "не може да се намери сървър" или неуспешно зареждане на портала. Грешките в защитната стена често блокират вътрешния трафик между роли, а не само трафика на потребителите. Активирайте удостоверяване на ниво мрежа (NLA), за да изисквате удостоверяване преди създаването на сесия. Тествайте всеки слой по ред, за да остане отстраняването на проблеми бързо.

• DNS разрешаване за точното име на хоста, с което се сблъсква потребителят
• TLS съвпадение на сертификата + валидиране на веригата на доверие
• Достъпност на защитната стена (443 до Gateway, разрешен вътрешен трафик)
• NLA активиран и удостоверяването успешно преди създаването на сесия

Добавете навик да валидирате от гледна точка на клиента. Проверете доверието в сертификата на типично потребителско устройство, а не само на сървъри. Уверете се, че точното име на хоста, което потребителите използват, съвпада с сертификата. Много "случайни" неуспехи са предсказуеми, след като ги възпроизведете от реален клиент.

Бавни сесии и прекъсвания

Неочаквани прекъсвания често са свързани с лицензиране, неуспехи на профили или изчерпване на ресурси. Бавните сесии обикновено се дължат на натиск върху паметта, латентност на диска или тежки скриптове за влизане. Проверете Event Viewer на Session Host и Gateway и свържете времевите марки. Потвърдете дали проблемът е общ за потребителите или специфичен за колекцията, преди да променяте настройки. Използвайте малки корекции и повторно тестване, вместо големи "преизграждания".

Принтер, периферни устройства и проблеми с пренасочването

Печатането и пренасочването на периферни устройства създават голям дял от RDS тикетите. Причината често е несъответствие на драйверите, поведение при откриване на стари принтери или прекомерни политики за пренасочване. Стандартизирайте драйверите на принтерите, където е възможно, и тествайте с най-често срещаните устройства рано. Ограничете функциите за пренасочване, от които потребителите нямат нужда, но избягвайте общи блокировки без участие на заинтересованите страни.

Когато проблемите продължават, изолирайте, като деактивирате една функция за пренасочване наведнъж. Този подход предотвратява "поправки", които случайно нарушават сканирането, печатането на етикети или подписните панели. Документирайте поддържаните устройства, за да може помощният център да зададе очакванията на потребителите.

Как TSplus опростява доставката на Remote Desktop?

TSplus Remote Access осигурява опростен начин за публикуване на Windows десктопи и приложения без изграждане на пълен многофункционален RDS стек. Администраторите могат да публикуват приложения, да ги назначават на потребители или групи и да предоставят достъп чрез персонализируем уеб портал. Потребителите могат да се свързват от браузър, използвайки HTML5, или от всякакъв клиент, съвместим с RDP, в зависимост от нуждите на устройството. Този подход намалява трудностите при настройката, като същевременно запазва централизирания контрол върху приложенията и сесиите за ефективни операции.

Заключение

Надеждният сървър за отдалечен работен плот започва с ясни дизайнерски избори и безопасни настройки по подразбиране. Настройте хостовете на сесиите за реални натоварвания, конфигурирайте лицензите правилно и избягвайте публичното излагане на RDP. Използвайте RD Gateway и чисти сертификати за сигурен външен достъп. С мониторинг и последователни политики, среда на RDS може да остане стабилна, докато използването нараства.