Выполняется оценка качества подключения

Miller777

Внезапно перестали подключаться юзеры. При попытке подключения выдает ошибку: "удалённый сеанс отключён поскольку отсутствуют доступные серверы лицензирования". Не могут подключиться ни обычные пользователи, ни администраторы.

Проблема и решение:

Помог запуск mstsc с параметром:

По-моему, раньше это называлось "нулевая сессия".

В таком варианте подключиться смог. Юзеров с правами пользователей по-прежнему не пускает. Ошибка: "Доступ к требуемому сеансу отклонен".

В диспетчере сервера – ошибки службы лицензирования рабочих столов. Отсутствует сервер лицензирования.

Настройки удаленных рабочих столов и их службы лицензирования – правильные. Поиграл настройками, удалил и заново прописал сервер лицензирования, изменил режим лицензирования с "на пользователя" на "на устройство" и обратно "на пользоателя".

После этого ошибка у юзеров при подключении сменилась на другую:

"Удаленный компьютер отключил сеанс, из-за ошибки в протоколе лицензирования".

Прочитал, что надо удалить ключ в реестре:

HKLMSYSTEMCurrentControlSetControlTe rminal ServerRCMGrace Period

Проблема в том, что просто так его не удалить даже с правами администратора. Редактор реестра нужно запускать с правами системы. Для этого служит PCTools от Марка Руссиновича, инструкция здесь:

После этого перезагрузился и сеансы у пользователей заработали.

Были бы лицензии – их, вероятно, можно было бы просто переактивировать.

Подключение к облаку можно рассматривать с двух сторон:

• технология подключение конечных пользователей к облаку,
• подключение локальной инфраструктуры корпоративного клиента к IaaS-инфраструктуре в облаке.

В этом посте мы рассмотрим реализацию подключения к облачному сервису со стороны конечного пользователя: возможные способы, варианты и инструменты.

Зачастую многие мелкие и даже средние компании не имеют своей локальной ИТ-инфраструктуры, предпочитая при этом развертывание всех необходимых для бизнеса решений и сервисов в облаке IaaS-провайдера (например, такого как ИТ-ГРАД). Этот подход экономически оправдан, выгоден и удобен. Единственное, что порой вызывает вопросы и споры, так это выбор соответствующего метода подключения. Что лучше, удобнее, безопаснее в той или иной ситуации? Будем разбираться.

Для подключения к облачным сервисам конечными пользователями, как правило, применяются комбинации различных решений. Рассмотрим их по отдельности, выбор у нас на сегодня следующий:

• RDP-клиент,
• RemoteApp,
• Веб-доступ,
• Remote access VPN,
• VPN site-to-site,
• DirectAccess,
• VDI.

Как показывает практика, выбор того или иного инструмента удаленного подключения зависит непосредственно от потребностей конкретного клиента / сотрудника / отдела. Бухгалтеру, аналитику, маркетологу, быть может, удобнее использовать веб-интерфейс, тогда как разработчику, тестировщику приложений, ERP-консультанту вполне подойдет вариант RDP-подключения или что-то другое. Рассмотрим каждую технологию в отдельности.

RDP-клиент (подключение посредством удаленного рабочего стола)

Удаленный рабочий стол — это один из наиболее распространенных, удобных, универсальных и часто используемых инструментов, дающих возможность удаленного доступа к рабочему месту, которое развернуто в том числе и в облаке.

В основе такого типа доступа лежит RDP (Remote Desktop Protocol) — проприетарный протокол прикладного уровня. Именно он обеспечивает удаленную работу пользователя с компьютером, на котором запущен сервис терминального доступа. На сегодняшний день существуют клиенты практически для всех операционных систем семейства Windows, Linux, FreeBSD, Mac OS X, iOS, Android, Symbian.

Клиента удаленного рабочего стола можно дополнительно конфигурировать. Пользователь может сохранить свой логин/пароль, чтобы при подключении не вводить их каждый раз заново. Однако с точки зрения безопасности лучше этого не делать. Также можно настроить параметры экрана, раскладки клавиатуры, звуков проигрывания и прочее. Если есть необходимость в использовании локальных ресурсов компьютера, с которого выполняется подключение к удаленному рабочему столу, и буфер обмена — так и это «пожалуйста». Помимо описанных выше опций, пользователь может менять параметры графики, что в случае низкой скорости Интернета сделает работу более комфортной.

Как выглядит со стороны пользователя: с помощью клиента RDP пользователь подключается к серверу терминалов и видит рабочий стол удаленной системы. В рамках установленной сессии он может запускать развернутые на сервере терминалов приложения.

Но как обстоит дело с безопасностью и насколько такое подключение может считаться надежным?

Если при подключении по RDP выбрать настройки по умолчанию, при реализации удаленного доступа будет использоваться слабое шифрование и трафик может быть расшифрован по пути. Однако существует ряд дополнительных методов, которые помогут защитить и оптимизировать RDP.

Примером является технология Remote Desktop Gateway (шлюза удаленных рабочих столов), ранее известная как шлюз служб терминалов (Terminal Services Gateway, TSG).

Remote Desktop Gateway (шлюз удаленных рабочих столов) представляет собой инструмент, посредством которого удаленные авторизованные пользователи смогут подключаться как к ресурсам физической сети предприятия, так и к сети в облаке IaaS-провайдера.

Шлюз удаленных рабочих столов использует протокол удаленного рабочего стола (RDP) поверх протокола HTTPS, гарантируя при этом безопасное соединение с обеспечением надежного метода шифрования между удаленными пользователями Интернета и ресурсами в облаке, необходимыми для работы пользовательских приложений.

RemoteApp (удаленные приложения служб терминалов)

Дело в том, что RemoteApp — это инструмент, который позволяет организовать удаленный доступ к установленным приложениям на сервере в облаке.

Клиент по-прежнему может использовать приложения, как если бы они были установлены локально. Если на данном этапе повествования разница не совсем очевидна, двигаемся дальше.

Рассматривая вариант с RDP, мы говорили о непосредственном подключении к удаленному рабочему столу, дающему возможность работы с экземпляром операционной системы. Пользователь видит рабочий стол, программы, иконки, панель управления и прочее. С вариантом RemoteApp дело обстоит иначе: пользователь видит только запущенное удаленное приложение в рамках своего физического устройства.

Клиент, к примеру, запускает ярлык Microsoft Word, расположенный на рабочем столе своего локального компьютера, после чего инициируется процесс проверки подлинности. При этом Word не установлен на локальной станции пользователя. После успешной аутентификации/авторизации приложение запускается и готово к работе. Как это реализовано?

На удаленном сервере «публикуется» приложение. А при запуске ярлыка средствами RemoteApp происходит подключение к удаленному серверу. В рамках запуска ярлыка приложения формируется RDP-сессия, после чего стартует и запускается само приложение без возможности отображения удаленного рабочего стола. Этот процесс для пользователя создает эффект локальной установки приложения.

Данный вариант будет полезен, к примеру, в следующих случаях:

• Когда необходимо ограничить доступ к конкретным приложениям.
• Когда пользователю необходимо совмещать работу на локальной машине с использованием какого-то приложения, вынесенного в облако.
• Когда приложение должно быть доступно в специфических условиях и при низкой скорости Интернета.

Как выглядит со стороны пользователя: для пользователя запускаемые удаленные приложения служб терминалов выглядят так, как если бы они исполнялись непосредственно в системе пользователя. Отображается НЕ рабочий стол удаленной системы с запущенными на ней приложениями, а приложения интегрируются в рабочий стол системы пользователя с масштабированием окна и собственным значком приложения в панели задач.

Веб-доступ к службам терминалов

Доступ к определенным приложениям и рабочим столам в облаке (оба рассмотренных ранее варианта) можно организовать с помощью браузера, который сегодня установлен на подавляющем большинстве устройств. Для пользователя такой вариант выглядит следующим образом: запускает браузер, вводит необходимый адрес, проходит проверку подлинности, а далее работает с опубликованным приложением / приложениями или удаленным рабочим столом / столами. При этом ярлыки приложений размещаются на предварительно настроенной веб-странице.

Как выглядит со стороны пользователя: используя веб-браузер, пользователь вводит соответствующий URL для доступа к ресурсу, проходит проверку подлинности и авторизацию, после чего получает доступ к приложениям или удаленному рабочему столу средствами web.

Еще одним вариантом подключения к облачным сервисам является подключение VPN.

Напомним, что VPN (Virtual Private Network) представляет собой виртуальную частную сеть, являясь обобщенным названием технологии, позволяющей обеспечить одно или несколько надежных сетевых соединений поверх такой небезопасной сети, как Интернет, используя при этом различные средства криптографии.

Существует два типа VPN-туннелей: Remote access VPN и Site-to-site VPN. Рассмотрим каждый из них более подробно.

Remote access VPN

Еще одним удобным, безопасным и достаточно часто используемым инструментом подключения к ресурсам облака является Remote access VPN.

Как выглядит со стороны пользователя: на стороне клиента устанавливается исходящее VPN-подключение, которое пользователь использует по необходимости. Для реализации доступа к удаленному ресурсу пользователь запускает ярлык VPN, вводит свои верительные данные и, при успешной проверке подлинности, получает доступ к необходимым ресурсам. Иными словами, компьютер пользователя, за счет выданных при VPN-подключении параметров IP-конфигурации, попадает в сеть виртуального удаленного офиса в облаке и может использовать ресурсы так, как если бы он находился непосредственно в офисе (в локальной сети) компании.

Для доступа к ресурсам файлового сервера в облаке каждому пользователю необходимо использовать VPN-подключение. После успешной аутентификации и авторизации пользователь получает доступ к File_server1.

Site-to-site VPN

Однако возможен и такой сценарий: сотрудникам компании из своей не виртуализированной, не облачной инфраструктуры необходимо подключение к ресурсу в облаке.

Как бы это выглядело при уже знакомой реализации Remote access VPN?

Каждый пользователь, прежде чем получить доступ к ресурсам в облаке, устанавливает отдельное VPN-подключение к VPN-серверу, а затем обращается к ресурсам файлового сервера \File_server1. А как это же самое выглядит при Site-to-site VPN? Начнем, пожалуй, с определения.

Site-to-site VPN — подразумевает наличие двух устройств (например, VPN Server 1 и VPN Server 2 рисунка 4), между которыми устанавливается туннель. В этом случае пользователи находятся за устройствами, в локальных сетях, и на их компьютерах не требуется установка какого-либо специального программного обеспечения.

Например, если количество пользователей в компании, которым необходим доступ к ресурсам файлового сервера, достаточно велико, проще реализовать подключение Site-to-Site VPN на уровне VPN-сервера в облаке и VPN-сервера в офисе компании. Для этого в офисе компании необходимо дополнительно развернуть VPN-сервер, а выглядеть процесс доступа к ресурсам файлового сервера будет так:

В таком сценарии пользователь обращается к ресурсу в облаке напрямую. В нашем примере к ресурсу \File_server1 в подсети облака при таком обращении VPN Server 1 устанавливает VPN-соединение с сервером VPN Server 2 в облаке, после чего пользователь видит содержимое запрашиваемого ресурса. На стороне клиента при этом отпадает необходимость создания исходящего VPN-подключения. Такая конфигурация носит название Site-to-Site VPN.

DirectAccess

DirectAccess позволяет реализовать возможность удаленного доступа к ресурсам корпоративной сети следующим образом: как только компьютер пользователя подключается к сети Интернет, он сразу получает доступ и к ресурсам Интернета, и ко всей корпоративной сети.

Т. е. пользовательский компьютер, сконфигурированный в качестве клиента DirectAccess, автоматически устанавливает туннель до сервера DirectAccess и через него получает доступ ко всей корпоративной сети. При этом от пользователя не требуется никаких дополнительных действий. Туннель между клиентом и сервером DirectAccess устанавливается автоматически, и этот процесс для пользователя абсолютно прозрачен. Не нужно запускать какие-либо VPN-соединения, не нужно вводить учетные данные — логин и пароль, пин-код для смарт-карты и пр. Более того, если связь с Интернетом на какое-то время теряется (и при этом, естественно, разрывается туннель), а затем восстанавливается, то опять же автоматически, без участия пользователя восстанавливается и туннель в корпоративную сеть.

VDI (виртуализация рабочих столов)

Поскольку высокая мобильность бизнеса сегодня требует постоянной доступности приложений для сотрудников, подход к реализации и решению таких задач постоянно меняется. На сегодняшний день виртуальная инфраструктура рабочих столов (VDI, Virtual Desktop Infrastructure) реализована на многих облачных площадках корпоративных IaaS-провайдеров. Данная технология позволяет централизовать рабочие станции пользователей на серверах виртуализации, создав при этом единую точку управления, развертывания и обслуживания.

Со стороны клиента все так же просто: необходимо наличие интернет-соединения и настольного ПК / ноутбука / мобильного телефона / планшета. При соблюдении этих условий пользователь имеет доступ к своему виртуальному рабочему месту из любой точки мира, и это заслуга VDI.

Виртуализация рабочих столов на практике может выглядеть следующим образом.

Выделяется сервер в облаке IaaS-провайдера, на который устанавливается гипервизор. На нем, в свою очередь, разворачиваются отдельные виртуальные машины — как правило, с клиентской ОС. На конечном устройстве пользователя запускается программа-клиент и происходит подключение к инфраструктуре. Такой тип подключения, на первый взгляд, мало чем отличается от RDP-подключения. Но в чем же разница?

В случае RDP-подключения к терминальному серверу — это отдельная сессия на общем сервере Windows. В случае VDI (виртуализации рабочих столов) — это отдельный изолированный контейнер с клиентской ОС. Таким образом, можно выделить два ключевых отличия: серверная ОС против клиентской и отдельная сессия (которая разделяет ресурсы одной ОС) против изолированной виртуальной машины.

Возможные причины ограничения доступа:

Доступ ограничен по решению суда или по иным основаниям, установленным законодательством Российской Федерации.

Сетевой адрес, позволяющий идентифицировать сайт в сети «Интернет», включен в Единый Реестр доменных имен, указателей страниц сайтов сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено.

Сетевой адрес, позволяющий идентифицировать сайт в сети «Интернет», включен в Реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространяемую с нарушением исключительных прав.