Wednesday, October 17th, 2018
Возможность Remote Desktop Web Connection в Windows XP и Windows Server 2003 позволяет вам соединиться с серверами RDP с помощью легкого в использовании интерфейса Web браузера. Средства Remote Desktop Web Connection обеспечивают:
Должно быть понятно, что основная причина для использования remote desktop Web connection заключается в простоте обслуживания RDP клиентов. Статья посвящена обсуждению следующих тем:
На рисунке 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, с которым хочет соединиться пользователь.
Рисунок 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. Проблемы с 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 показывают, как многие администраторы представляют себе процесс соединения, но это работает не так.
На рисунке 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 в корпоративной сети.
Рисунок 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. Для того, чтобы сделать это, вы должны:
Рисунок 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: dns, nat, vpn, Windows XP