Wednesday, October 17th, 2018

Публикация сайтов Remote Desktop Web Connection с брандмауэром ISA Часть 1 – Концепция Remote Desktop Web Services

Published on Февраль 16, 2009 by   ·   Комментариев нет

Возможность Remote Desktop Web Connection в Windows XP и Windows Server 2003 позволяет вам соединиться с серверами RDP с помощью легкого в использовании интерфейса Web браузера. Средства Remote Desktop Web Connection обеспечивают:

  • Легкий способ установки RDP клиентского программного обеспечения не требующий поддержки специальных приложений для Remote Desktop Client. Пользователи соединяются с Web сайтом, затем загружают элемент ActiveX, который позволяет появиться интерфейсу remote desktop в окне браузера
  • Быстрый и «грязный» способ для обеспечения удаленного доступа с помощью протокола RDP к компьютерам пользователей и серверам RDP
  • Упрощенный подход к установке RDP клиентов на различные платформы Windows. Вам не надо беспокоиться о версии RDP программного обеспечения, установленного на клиенте, и вообще об установке клиента на операционной системе.
  • Альтернативу для соединения VPN для поставщиков, которым необходим доступ к ресурсам DMZ. Вам не надо помогать поставщикам настраивать их клиентское приложение для VPN и даже создавать профиль CMAK. Все что им необходимо, это подсоединиться к Remote Desktop Web Connection Site и ввести правильное название сервера и данные для авторизации.

Должно быть понятно, что основная причина для использования remote desktop Web connection заключается в простоте обслуживания RDP клиентов. Статья посвящена обсуждению следующих тем:

  • Как в действительности работает и как не работает Remote Desktop Web Connection
  • Проблемы с DNS при соединении к Remote Desktop Web

Как в действительности работает и как не работает Remote Desktop Web Connection

На рисунке 1 ниже показано, как большинство людей представляют себе процесс Remote Web Connection. Это описание неправильное. Когда вы смотрите на это описание, помните, что оно неверное, и что оно представлено лишь для того, чтобы указать на неверные предположения большинства сетевых администраторов.

Этот рисунок показывает соединение клиента remote desktop Web connection, производимое по HTTP (которое может быть зашифровано с помощью SSL), к внешнему интерфейсу брандмауэра ISA. Брандмауэр ISA производит проверку соединения на прикладном уровне, а затем перенаправляет запрос на соединение серверу Remote Desktop Web Services. Соединение остается RDP соединением, содержащемся в заголовке HTTP, до тех пор, пока не достигнет сервера Remote Desktop Web Service.

По этой причине, “что-то случается”, в результате чего RDP протокол вскрывается. После вскрытия, незащищенные соединения RDP перенаправляются на терминальный сервер. Я предполагаю, что когда это происходит, эти соединения возвращаются от терминального сервера серверу Remote Desktop Web Services, который снова встраивает соединения RDP в заголовок HTTP, а затем перенаправляет их клиенту службы remote desktop Web в Internet.

Это было бы достаточно неплохо, так как в этом случае сервер Remote Desktop Web Services должен работать как прокси RDP/HTTP. К несчастью, все работает не так. Повторю еще раз, это работает не так. Обратите внимание на метку WRONG на рисунке 1.

Клиент для соединения через интернет

Рисунок 1: Как не работает Remote Desktop Web Services

На рисунке 2 показано, что в действительности происходит в процессе Remote Desktop Web Connection. Клиент remote desktop Web connection в Internet устанавливает HTTP соединение (которое может быть защищено с помощью SSL) с Web listener во внешнем интерфейсе брандмауэра ISA. Брандмауэр ISA производит проверку соединения на прикладном уровне, а затем перенаправляет соединение серверу Remote Desktop Web Services Server в корпоративной сети.

В этот момент, Web сервер передает удаленному клиенту параметры для установки элемента RDP ActiveX. После установки элемента ActiveX, пользователь может затем ввести название сервера RDP и название домена. Он также может ввести имя пользователя и название домена, которые будут переданы на страницу для входа на сервере RDP.

После того, как пользователь вводит эту информацию, устанавливается второе соединение от клиента remote desktop Web к брандмауэру ISA. Но это уже не HTTP соединение – это уже соединение RDP. В отличие от первого соединения, которое происходило с сервером Remote Desktop Web Service по протоколу TCP порту 80 (или TCP 443, если используется шифрование для HTTP соединения), второе соединение по умолчанию устанавливается по порту протокола RDP, а это TCP порт 3389. RDP Server Publishing Rule listener брандмауэра ISA перехватывает второе соединение и передает его на тот сервер RDP, с которым хочет соединиться пользователь.

Remote desktop web connection 2008

Рисунок 2

RDP соединение совершается внутри туннеля HTTP. Это означает, что если клиент remote desktop Web в Internet находится за устройством NAT или брандмауэром, которые не позволяют исходящее соединение с TCP портом 3389, то подсоединение RDP к терминальному серверу не состоится. Но это не произойдет, если разрешить исходящее соединение HTTP. Единственную вещь, которую вы получите при разрешении исходящего HTTP из сети, в которой располагается клиент remote desktop Web service – это соединение с сервером Remote Desktop Web Service и вход на Web страницу.

Вы не сможете соединиться после ввода требуемой информации на Web странице, т.к. требуется исходящее RDP (в действительности, необходим исходящий TCP порт 3389, сам протокол не требуется пока брандмауэр производит проверку прикладного уровня самого протокола RDP).

Проблемы DNS с Remote Desktop Web Connections

Теперь, когда мы на правильном пути, давайте обсудим проблемы DNS, возникающие при соединении с клиентом Remote Desktop Web. Проблемы с DNS связаны с основным заблуждением по отношению к тому, как клиент remote desktop Web соединяется с сервером RDP в корпоративной сети.

На рисунке 3 показано как не работает соединение с сервером RDP. Снова, я углублюсь в детали по поводу того, как это не работает, потому что многие администраторы уверены, что это работает именно таким образом, как я сейчас опишу. Прочтите это, но помните, что это описание неверное.

В этом фантастическом сценарии, пользователь вводит название сервера RDP, который располагается во внутренней сети в текстовом поле server на странице доступа к remote desktop Web. В этом примере давайте предположим, что пользователь вводит в это поле SERVER1.

Запрос на соединение посылается на Web listener брандмауэра ISA, который проверяет входящие соединения. Затем брандмауэр ISA выполняет роль прокси и передает соединение серверу Remote Desktop Web Services. Затем сервер Remote Desktop Web Services запрашивает внутренний сервер DNS, чтобы получить IP адрес сервера по его названию SERVER1.

После того как имя сервера распознано, сервер Remote Desktop Web Services передает RDP запрос на IP адрес терминального сервера. Терминальный сервер устанавливает сессию с клиентом remote desktop Web service в Internet, и таким образом клиент remote desktop Web services и терминальный сервер общаются напрямую друг с другом.

Было бы не плохо, если бы все работало таким образом, но это работает не так. Снова, объяснение, приведенное выше, а также рисунок 3 показывают, как многие администраторы представляют себе процесс соединения, но это работает не так.

Rdp

Рисунок 3: Как не работает соединение с сервером RDP

На рисунке 4 в действительности показано, что происходит, когда клиент remote desktop Web services соединяется с сервером RDP во внутренней сети. Здесь, черными линиями показано соединение, которое инициирует клиент remote desktop Web services с сервером Remote Desktop Web Services. Затем клиент получает Web страницу, где пользователь вводит название сервера RDP, с которым он хочет соединиться.

В этом примете, пользователь вводит на странице remote desktop Web в текстовом поле Server название SERVER1.msfirewall.org. Затем клиент запрашивает общий сервер DNS для распознания названия SERVER1.msfirewall.org, IP адрес которого должен входить в список для доступа listener, описанного в RDP Server Publishing Rule. Удаленный клиент соединяется с RDP Server Publishing Rule listener, а затем соединение передается серверу RDP в корпоративной сети.

Remote desktop manager

Рисунок 4: Как в действительности работают соединения с сервером RDP

Как вы можете увидеть, название, которое вводит пользователь в текстовое поле Server name – это не NetBIOS название сервера в корпоративной сети. Это даже не название FQDN, используемое терминальным сервером в корпоративной сети. Имя может быть любым, как вы захотите, но оно должно соответствовать IP адресу, используемому в RDP Server Publishing Rule для публикации определенного терминального сервера.

Что если вы захотите опубликовать несколько терминальных серверов, к которым необходимо получить доступ с помощью Web страницы remote desktop Web services? В этом случае вы должны создать несколько правил RDP Server Publishing Rules, одно правило для каждого сервера RDP, который вы хотите опубликовать. Вам также необходимо создать публичную DNS запись для каждого из этих серверов.

Например, посмотрите на установку на рисунке 5. В этом сценарии есть три терминальных сервера в корпоративной сети. Вы хотите предоставить удаленным пользователям доступ к этим серверам с помощью соединения к Remote Desktop Web Services. Сервера во внутренней сети называются SERVER1, SERVER2 и SERVER3. Для того, чтобы сделать это, вы должны:

  • Создать правило Web Publishing Rule для публикации сервера Remote Desktop Web Services
  • Создать три правила RDP Server Publishing Rules, одно для каждого сервера RDP. Для этого вам необходимо иметь как минимум три IP адреса связанные с внешним интерфейсом брандмауэра ISA
  • Настроить публичный DNS сервер с записями о компьютере (A), которые соответствуют названиям Web сервера и серверов RDP корректным IP адресам во внешнем интерфейсе брандмауэра ISA, соответствие IP адресов, используемы в каждом правиле

    TCP listener nat

    Рисунок 5: Публикация нескольких серверов

Примечание:
Эта дискуссия сосредоточена на параметрах по умолчанию на сервере Remote Desktop Web Server, на клиенте remote desktop Web client, и описаниях протокола RDP и параметров listener на брандмауэре ISA. Также есть возможность управлять конфигурацией каждого из этих устройств таким образом, что вы можете использовать один IP адрес на внешнем интерфейсе брандмауэра ISA для публикации этих служб с помощью управления портом RDP listener на каждом терминальном сервере, изменение описания протокола (Protocol Definition), используемого в правиле Server Publishing Rule, а также изменение настроек на странице .asp на сервере Remote Desktop Web Services. Вы можете написать мне по адресу tshinder@isaserver.org, если вы заинтересованы в такой статье. Если будет проявлен достаточный интерес, то я напишу другую статью о том, как выполнить эту дополнительную конфигурацию.

Резюме

В этой статье мы обсудили некоторые проблемы, связанные с обеспечением удаленного доступа к сайту remote desktop Web. Основная задача была рассеять общее заблуждение по отношению работы remote desktop Web service и привести детальное объяснение этой технологии. Я также обсудил некоторые проблемы, связанные с правилами Web и Server Publishing Rules, о которых вы должны знать перед установкой remote desktop Web при работе с брандмауэрами ISA. Во второй части этой статьи я расскажу о пошаговых процедурах для публикации remote desktop Web services Web site и необходимых для этого правилах RDP Server Publishing Rule.

www.isaserver.org



Смотрите также:

Tags: , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]