Протоколы удаленного доступа

Рисунок 2. Proxy-сервер RPC, расположенный внутри DMZ.

Лучше разместить proxy-сервер RPC во внутренней части сети и использовать универсальный ретранслятор HTTP в DMZ (рисунок 3). В данной конфигурации предусматривается лишь одно соединение от ретранслятора HTTP в DMZ (в данном случае Microsoft Internet Security и Acceleration-ISA-server) к proxy-серверу RPC во внутренней сети. Данное соединение может быть установлено через базовый протокол HTTP (порт 80) или зашифровано с использованием SSL (Secure Sockets Layer — порт 443). Можно также задействовать функции шифрования RPC over HTTP программы Outlook 2003. При использовании данного подхода можно применять несколько способов защиты соединений. Самый обычный метод — завершить SSL-соединение на proxy-сервере ретрансляции HTTP и установить простое соединение HTTP с RPC-посредником. Этот подход широко распространен, так как подобные proxy-серверы HTTP обычно оснащены аппаратными акселераторами шифрования SSL. Альтернативный подход — провести туннель для входящего SSL-соединения через proxy-сервер HTTP и возложить задачу SSL-шифрования на proxy-сервер RPC. Или же proxy-сервер HTTP может завершить исходящий сеанс SSL и установить новый сеанс SSL с proxy-сервером RPC.

Рисунок 3. Proxy-сервер RPC, расположенный во внутренней сети

 

Конфигурирование RPC over HTTP на серверах

Для реализации RPC over HTTP необходимо выполнить на серверах несколько изменений. Прежде всего нужно убедиться, что на сервере, применяемом в качестве сервера-посредника RPC, установлена служба RPC over HTTP Proxy. Для этого следует открыть утилиту Add/Remove Programs панели управления и щелкнуть на вкладке Add/Remove Windows Components. Затем нужно отметить пункт Networking Services, убедиться, что выбрана служба RPC over HTTP (экран 1) и щелкнуть на кнопке OK, чтобы развернуть службу.

Экран 1. Установка службы RPC over HTTP Proxy

После установки службы RPC over HTTP Proxy необходимо перейти к объекту Web SitesDefault Web SiteRPC Virtual Directory в оснастке IIS Manager консоли управления Microsoft Management Console (MMC) и открыть диалоговое окно Properties объекта (экран 2). Следует перейти к вкладке Directory Security, выбрать раздел Authentication and access control, а затем запретить Anonymous access и разрешить режим Integrated Windows Authentication или, если используется SSL, режим Basic authentication. Если выбран режим Basic authentication, то мандат передается открытым текстом, но соединение защищено благодаря SSL, поэтому такой подход вполне приемлем.

Далее требуется настроить конфигурацию сервера для работы в качестве посредника RPC. Для этого необходимо открыть редактор реестра, перейти в раздел реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpc RpcProxy и присвоить параметру ValidPorts значение с типом данных REG_SZ.

Устанавливая значение ValidPorts, необходимо указать каждый сервер, с которым может установить связь proxy-сервер RPC, в том числе все почтовые серверы Exchange 2003 и любые DC и GC, и назначить порт 593 для каждого сервера. Служба RPC over HTTP Endpoint Mapper использует порт 593 для организации соединения путем квитирования. В строке параметров также указывается диапазон портов для соединений. На экране 3 показан пример такой строки для сервера с именем osbex01. В зависимости от конкретной среды, расположения сервера и способа разрешения имен, иногда следует указать Fully Qualified Domain Name (FQDN) серверов в элементе реестра ValidPorts (если имена в сокращенном формате не обеспечивают корректного преобразования). На экране 6 видно, что в дополнение к параметрам для osbex01 указаны и соответствующие параметры для osbex01.osb.cantaz.net. Если роль GC-сервера выполняет тот же сервер, на котором работает Exchange 2003, то нет необходимости указывать GC отдельно от системы Exchange.

Очевидно, что при наличии десятков или сотен почтовых и GC-серверов обновление параметров ValidPorts реестра с указанием значений для каждого сервера — труднейшая задача. Поэтому мы надеемся, что Microsoft дополнит пакет Exchange 2003 утилитой, которая будет анализировать среду Exchange и автоматически обновлять данный параметр реестра.

 

Ограничение соединений RPC-посредника

Диапазон портов proxy-сервера RPC определяет область функционирования RPC over HTTP. Однако можно явно назначить порты, которые будут использоваться каждым сервером — участником соединений RPC over HTTP. Следует обратить внимание, что в бета-версиях Exchange 2003 в разделе реестра ValidPorts можно указать принимаемый по умолчанию диапазон 1024-65535, и любые внутренние серверы или GC будут динамически выбирать рабочие порты в этом диапазоне без дополнительной настройки. Из версии Release Candidate 0 эта функция удалена.

Самые существенные изменения требуется внести во внутренние почтовые серверы. Во-первых, необходимо определить порт, через который внутренний сервер устанавливает соединения RPC over HTTP с хранилищем Exchange Store. Для этого нужно присвоить параметру реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystemRPC/HTTP Port значение 6001 типа REG_DWORD.

Затем следует настроить внутренний сервер для перенаправления Directory Service (DS) Referral, присвоив параметру реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeSAParametersHTTP Port значение 6002 типа REG_DWORD. Затем внутренний сервер настраивается для доступа DS Proxy. Для этого параметру HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystemRPC/HTTP NSPI Port присваивается значение 6003 типа REG_DWORD. Эти изменения должны быть выполнены на всех внутренних серверах Exchange 2003, которые могут устанавливать соединения с proxy-сервером RPC.

Кроме того, необходимо настроить любые DC и GC, указанные в разделе реестра ValidPorts proxy-сервера RPC, для связи с proxy-сервером RPC через порты ограниченного диапазона. Следует перейти к элементу HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParametersNSPI interface protocol sequences реестра DC или GC-сервера и присвоить этому параметру значение ncacn_http:6004 типа REG_SZ.

 

Безопасные соединения

Соединения RPC over HTTP желательно устанавливать по каналам SSL, избегая незащищенных линий. В рекомендуемой конфигурации (см. рисунок 3) ретрансляционный proxy-сервер HTTP (ISA Server) завершает любые клиентские SSL-соединения и устанавливает отличные от SSL соединения с proxy-сервером RPC. Для этого необходимо установить серверный сертификат на ретрансляционном посреднике HTTP. Соответствующие сертификаты можно получить из коммерческой организации Certificate Authority (CA), такой как VeriSign или Thawte, либо использовать службу Microsoft Certificate Services для создания собственных сертификатов.

Раздел реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpc RpcProxyAllowAnonymous управляет работой proxy-сервера RPC с соединениями, отличными от SSL. Если данного раздела не существует или значение его параметра равно 0, то proxy-сервер RPC отвергает все отличные от SSL и неаутентифицированные соединения. Когда ретранслятор HTTP завершает SSL-соединение, последующее соединение с посредником RPC обычно не защищено SSL и поэтому будет отвергнуто. В данном случае можно присвоить параметру реестра значение 1-го типа REG_DWORD. Изменение вступает в силу после перезапуска службы IIS на proxy-сервере RPC.

В целях безопасности в текущей документации Microsoft такие изменения рекомендуется вносить только на непроизводственных системах. Однако во многих рабочих средах необходима следующая конфигурация: SSL-соединение завершается на proxy-серверах HTTP, а с proxy-сервером RPC устанавливаются отличные от SSL соединения. Необходимо взвесить все за и против и выбрать оптимальную конфигурацию для конкретной среды.

 

Настройка клиента

Некоторые изменения требуется внести и в профиль Messaging API (MAPI), чтобы позволить клиенту Outlook 2003 установить связь с сервером по HTTP. Если у пользователя уже имеется профиль MAPI, то доступ к его свойствам можно получить, выбрав соответствующий профиль MAPI в утилите Mail панели управления. Нужно выбрать пункты Change, More Settings, а затем перейти к вкладке Connection. Затем следует установить флажок Connect to my Exchange mailbox using HTTP и щелкнуть на кнопке Exchange Proxy Settings, чтобы завершить настройку конфигурации. В диалоговом окне (экран 4) требуется ввести URL, чтобы направить клиента на proxy-сервер RPC. Этот URL может быть значением, объявляемым ретрансляционным proxy-сервером HTTP (для последующего перенаправления пакетов в proxy-сервер RPC). В режиме Basic Authentication префикс URL автоматически изменяется с http на https, поэтому может использоваться только безопасное соединение. Если режим с подключением через протокол HTTP отключен, необходимо убедиться, что установлены XP SP1 и упомянутая выше программа коррекции. Можно установить флажок Mutually authenticate the session when connecting with SSL. В результате proxy-сервер RPC (или ретрансляционный proxy-сервер HTTP) аутентифицирует подключающегося клиента с помощью как клиентского, так и серверного сертификата. В этом режиме клиент должен передать в модуль Security Support Provider (SSP) сервера ожидаемое имя сервера Principal name. Согласно стандартным синтаксическим правилам Microsoft, за префиксом msstd: следует FQDN proxy-сервера RPC (экран 4).

Экран 4. Настройка конфигурации клиента RPC over HTTP.

И наконец, чтобы использовать для соединения протокол HTTP, необходимо установить флажок Connect using HTTP first, then connect using my Local Area Network (LAN). Как правило, Outlook 2003 сначала пытается установить связь с сервером Exchange через TCP/IP. Если попытка не удается, Outlook пробует соединиться через HTTP. После установки этого флажка Outlook делает попытку сначала соединиться через HTTP, что позволит избежать задержки, связанной с тайм-аутом протокола.

При обсуждении смены профиля MAPI предполагалось, что профиль на клиентском компьютере уже существует. Если требуется создать профиль, следует помнить, что для этого необходим прямой RCP-доступ к серверу Exchange через TCP/IP. Если нужно создать профили MAPI для удаленных пользователей (т. е. прямой TCP/IP-доступ к серверу Exchange отсутствует), следует задействовать утилиту генерации профиля MAPI, такую как profgen.exe — инструмент из набора ресурсов Microsoft Office 2003 Resource Kit. В идеале для управления системами необходимо автоматизировать все изменения в MAPI-профилях пользователей, чтобы значительно снизить вероятность возникновения пользовательских ошибок.

Применение RPC over HTTP для подключения клиентов Outlook 2003 к почтовым серверам представляет собой гибкий способ обращения к домашним почтовым ящикам пользователей без ограничений туннелирования или громоздкого клиента на базе Web. Однако в стандартной конфигурации эта функция не работает. Ее запуск требует планирования и настройки конфигурации со стороны администратора систем отправки сообщений. Прежде чем внедрять службу RPC over HTTP на всем предприятии, следует выполнить пилотный проект, чтобы исследовать влияние данной службы на инфраструктуру.

 

 

Протокол получения информации о пользователях - Finger.

Протокол Finger возвращает информацию об одном или нескольких пользователях на указанном хосте. Это приложение обычно используется, для того чтобы посмотреть, находится ли конкретный пользователь в настоящее время в системе, или чтобы получить имя какого-либо пользователя, чтобы послать ему почту. Сервер Finger использует заранее известный порт 79. Клиент осуществляет активное открытие на этот порт и отправляет запрос длиной в 1 строку. Сервер обрабатывает запрос, посылает назад вывод и закрывает соединение. Запрос и отклик в формате NVT ASCII, почти так же как мы видели в случае FTP и SMTP.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Протоколы удаленного доступа

Протокол Telnet

Протокол Telnet (TELNET) предназначен для взаимодействия устройств и процессов терминала. TELNET часто применяется программами эмуляции терминала для входа в удаленную систему. TELNET также обеспечивает взаимодействия терминал-терминал и взаимодействия между процессами. Кроме того, TELNET применяется другими протоколами (например, FTP) для создания управляющего канала протокола.

 

Протокол пересылки файлов FTP.

Протокол пересылки файлов FTP (File Transfer Protocol) реализует удаленный доступ к файлу. Он может использоваться приложениями и пользователями для передачи файлов по сети. Для того, чтобы обеспечить надежную передачу, FTP использует в качестве транспорта протокол с установлением соединений - TCP. Однако, кроме пересылки файлов, протокол FTP предлагает и другие услуги. Так, пользователю предоставляется возможность интерактивной работы с удаленной машиной, например, он может распечатать содержимое ее каталогов. Кроме того, FTP позволяет пользователю указывать тип и формат запоминаемых данных. Наконец, FTP выполняет аутентификацию пользователей.

Протокол пересылки файлов FTP (File Transfer Protocol) реализует удаленный доступ к файлу. Он может использоваться приложениями и пользователями для передачи файлов по сети. Для того, чтобы обеспечить надежную передачу, FTP использует в качестве транспорта протокол с установлением соединений - TCP. Однако, кроме пересылки файлов, протокол FTP предлагает и другие услуги. Так, пользователю предоставляется возможность интерактивной работы с удаленной машиной, например, он может распечатать содержимое ее каталогов. Кроме того, FTP позволяет пользователю указывать тип и формат запоминаемых данных. Наконец, FTP выполняет аутентификацию пользователей. FTP обеспечивает защиту данных при передаче, отправляя внешнему хосту пароль пользователя и учетного файла пользователя

 

Протокол TFTP.

Упрощенный протокол передачи файлов (TFTP) предназначен для обмена файлами с внешними хостами. Для передачи файлов TFTP применяет ненадежный Протокол пользовательских дейтаграмм, поэтому обычно он работает быстрее, чем FTP. Как и FTP, TFTP поддерживает передачу файлов в формате NETASCII и в 8-разрядном двоичном формате. В отличие от FTP, TFTP не поддерживает просмотр каталогов или переход в другой каталог внешнего хоста. В нем также не предусмотрена защита с помощью пароля. Кроме того, TFTP работает только с общими каталогами.

 

Протокол SMTP.

Для передачи электронной почты в Internet разработан специальный протокол Simple Mail Transfer Protocol (SMTP), который является протоколом прикладного уровня и использует транспортный протокол TCP. при использовании протокола SMTP sendmail пытается найти машину-получателя почты и установить с ней взаимодействие в режиме on-line для того, чтобы передать почту в ее почтовый ящик. совместно с этим протоколом используется и Unix-Unix-Copy (UUCP) протокол. UUCP почта передается по принципу "stop-go"(off-line), т. е. почтовое сообщение передается по цепочке почтовых серверов от одной машины к другой, пока не достигнет машины-получателя или не будет отвергнуто по причине отсутствия абонента-получателя.