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

Неявное удаленное управление. Ещё один, довольно нестандартный способ удаленного управления — неявное удаленное управление (Implicit remoting). Используя его можно, не создавая удаленной сессии, локально выполнять командлеты, находящиеся на удаленном компьютере.

Для примера берем обычную рабочую станцию, без установленных средств удаленного администрирования. Создаем удаленную сессию с контроллером домена SRV4 и импортируем в эту сессию модуль Active Directory:

$session = New-PSSession -ComputerName SRV4 Invoke-Command {Import-Module Active Directory} -Session $session

Затем экспортируем из удаленной сессии командлеты Active Directory и помещаем их в локальный модуль RemoteAD:

Export-PSSession -Session $session -CommandName *-AD* -OutputModule RemoteAD`-AllowClobber

Эта команда создаст в папке WindowsPowerShell\Modules\RemoteAD новый модуль PowerShell.

Загружены будут только командлеты с именами, соответствующими шаблону *-AD*. При этом сами командлеты не копируются на локальный компьютер. Локальный модуль служит своего рода ярлыком, а сами команды будут выполняться на удаленном контроллере домена.

После создания модуля удаленную сессию можно закрыть, она больше не понадобится.

 

Импортируем новый модуль в текущий сеанс (в PS 3.0 можно этот шаг пропустить):

Import-Module RemoteAD

А теперь внимание — мы не открываем удаленную сессию с контроллером домена, где расположены командлеты. Не нужно явно запускать этот сеанс — это можно сделать неявно, попытавшись выполнить удаленные командлеты:

New-ADUser -Name BillGates -Company Microsoft Get-ADUser BillGates

При этом будет восстановлено удаленное подключение к контроллеру домена, после чего команда будет передана на контроллер домена и там выполнена. Результат выполнения будет сериализован в XML и передан по сети на локальный компьютер, где будет выполнена десериализация в объекты, с которыми может работать PowerShell.

Удаленный сеанс будет активным до тех пор, пока вы не закроете консоль или не удалите модуль RemoteAD.

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

В заключение скажу, что на данный момент PowerShell Remoting является основным инструментом для удаленного управления операционными системами Windows. Поэтому знать о его возможностях и уметь ими пользоваться просто необходимо любому Windows-администратору.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.5 Виртуальные частные сети.

Виртуальная частная сеть (VPN) представляет собой подключение типа «точка-точка» в частной или общедоступной сети, например, в Интернете. VPN-клиенты используют специальные TCP/IP-протоколы, называемые туннельными протоколами, обеспечивающие установление защищенного канала обмена данными между двумя компьютерами. С точки зрения взаимодействующих компьютеров между ними организуется выделенный канал типа «точка-точка», хотя в действительности, соответствующие данные передаются через Интернет, как и любые другие пакеты. При обычной реализации VPN клиент инициирует виртуальное подключение типа «точка-точка» к серверу удаленного доступа через Интернет. Сервер удаленного доступа отвечает на вызов, выполняет проверку подлинности вызывающей стороны и передает данные между VPN-клиентом и частной сетью организации.

Для эмуляции канала типа «точка-точка» к данным добавляется заголовок (выполняется инкапсуляция). Этот заголовок содержит сведения о маршрутизации, которые обеспечивают прохождение данных по общей или публичной сети до конечной точки. Для эмуляции частного канала и сохранения конфиденциальности передаваемые данные шифруются. Дополнительные сведения о туннельных протоколах, поддерживаемых в этой версии Windows, см. на странице Туннельные протоколы VPN (страница может быть на английском языке).

Требования к установке см. в разделе Требования для установки RRAS в качестве VPN-сервера.

 

 

 

 

 

 

VPN-подключение

Существует два типа VPN-подключений.

VPN-подключение удаленного доступа

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

 

VPN-подключение типа «сеть-сеть»

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

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

VPN-подключение между двумя удаленными  сайтами через Интернет

Свойства VPN-подключений

Инкапсуляция. Обеспечивается инкапсуляция частных данных с использованием заголовка, содержащего сведения о маршрутизации для передачи этих данных по транзитной сети. Примеры инкапсуляции см. на странице Туннельные протоколы VPN (страница может быть на английском языке) (http://go.microsoft.com/fwlink/?linkid=140602).

Проверка подлинности. Существует три различные формы проверки подлинности для VPN-подключений:

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

Проверка подлинности на уровне компьютера по протоколу IKE. Чтобы установить сопоставление безопасности IPSec, VPN-клиент и VPN-сервер используют протокол IKE для обмена сертификатами компьютеров или предварительным ключом. В обоих случая VPN-клиент и VPN-сервер выполняют взаимную проверку подлинности на уровне компьютера. Проверка подлинности на основе сертификата компьютера является одним из самых надежных способов и рекомендуется к применению. При проверке подлинности на уровне компьютера используются подключения по протоколам L2TP/IPSec или IKE версии 2.

Проверка подлинности источника данных и обеспечение целостности данных. Чтобы убедиться в том, что источником отправленных по VPN-подключению данных является другая сторона VPN-подключения и что они переданы в неизмененном виде, в данные включается контрольная сумма шифрования, основанная на ключе шифрования, который известен только отправителю и получателю. Функции проверки подлинности источника данных и обеспечения целостности данных доступны для подключений по протоколам L2TP/IPSec и IKE версии 2.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.6 Удаленный доступ к Exchange 2003 по каналам HTTP.

Использование Outlook 2003 для доступа к почтовому ящику Exchange.

Новая возможность Outlook 2003 для доступа к почтовому ящику Exchange. Благодаря сочетанию Microsoft Outlook 2003, Windows Server 2003 и Microsoft Exchange Server 2003 открываются новые возможности для подключения клиента Outlook 2003 к Exchange 2003 по каналам HTTP. Соединение не просто использует HTTP: Outlook заключает вызов удаленных процедур (RPC) к Exchange 2003 в оболочку HTTP, обеспечивая соединение локального клиента Outlook 2003 с удаленным сервером Exchange 2003 с любой машины, располагающей Web-браузером. Это полезный метод, особенно если учесть недостатки других способов: Outlook Web Access (OWA), который совершенствуется, но по-прежнему уступает полноценному клиенту Outlook, или доступ к Outlook через соединение VPN, которое часто блокируется сетевыми провайдерами. Чтобы использовать RPC over HTTP, необходимо понимать механизм и требования к конфигурациям как клиента, так и сервера.

 

Взаимодействие Outlook и Exchange

Во всех версиях Outlook для взаимодействия с любой версией Exchange Server применяется интерфейс Messaging API (MAPI) и вызовы удаленных процедур (RPC) для обработки вызовов MAPI. Протокол RPC не располагает встроенными функциями повышения надежности, это свойство определяется базовым транспортным протоколом, таким как TCP/IP. При использовании менее надежного транспортного средства, например, UDP, приложение на базе RPC должно обеспечить функции тайм-аута и повторной пересылки.

RPC-соединения Outlook-Exchange начинаются  с процедуры квитирования между  клиентом Outlook и сервером Exchange через  хорошо известный порт (например, UDP-порт 135 — порт подключения  конечных точек RPC) с последующей  организацией канала связи через  динамически назначаемый порт (обычно  в диапазоне от 1024 до 1100). Назначать  порты можно с помощью параметров реестра, но обычно администраторы сетей и брандмауэров не разрешают организовывать соединения RPC через общедоступные сети TCP/IP. Кроме того, из-за серьезных проблем с безопасностью RPC-службы Windows NT в прошлом большинство сетевых администраторов блокируют порты 135, 137, 139 и 445, чтобы помешать проходу внешних тестовых сообщений RPC через брандмауэр. Эти ограничения приводят к тому, что нельзя использовать Outlook в сети одной компании, чтобы установить соединение через Internet с сервером Exchange в сети другой компании. Вместо того чтобы возложить согласование RPC по каналам TCP/IP на администраторов сетей и брандмауэров, разработчики Microsoft модернизировали механизм RPC в Outlook и Exchange, обеспечив связь поверх протокола HTTP.

Благодаря новым функциям можно установить возвратный proxy-сервер (reverse proxy server) HTTP и использовать протокол HTTP для внешних соединений. Как правило, для связи применяется стандартный порт 80 или какая-нибудь его разновидность (например, 8080 или 8088). После настройки браузера Microsoft Internet Explorer (IE) на клиентском компьютере для работы с proxy-сервером любое приложение может задействовать протокол HTTP для соединений клиент/сервер. Протокол Secure HTTP (HTTPS) также обычно доступен через порт 443.

 

Требования RPC over HTTP

Для соединения RPC over HTTP между Outlook и Exchange необходимо, чтобы на клиентском компьютере были установлены Windows XP Service Pack 1 (SP1) и исправление, описанное в статье Microsoft «Outlook 11 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through HTTP» На клиенте должен работать Outlook 2003 (при подготовке данной статьи использовалась вторая бета-версия, сборка 4920).

На сервере должна быть установлена Windows 2003, чтобы использовать службу Microsoft Internet Information Services (IIS) 6.0 в режиме Worker Process Isolation Mode. Windows 2003 должна работать на всех системах, устанавливающих связь с клиентом Outlook 2003, в том числе серверах Exchange, серверах глобального каталога (Global Catalog, GC) и контроллерах домена (DC).

 

Архитектура RPC over HTTP

Архитектура RPC over HTTP напоминает модель внешний/внутренний сервер (front end/back end server), впервые примененную Microsoft в Exchange 2000 Server и используемую в OWA, IMAP и POP3. Outlook 2003 связывается через протокол 2003 с proxy-сервером RPC, также известным как внешний proxy-сервер RPC. Proxy-сервер RPC действует от имени клиента, устанавливая RPC-соединения с внутренним сервером, на котором размещается почтовый ящик клиента. Соединения показаны на рисунке 1.

Рисунок 1. Архитектура RPC over HTTP для Outlook и Exchange

Следует отметить важные особенности архитектуры. Во-первых, RPC-посредник не обязательно должен быть системой Exchange 2003, так как proxy-сервер не использует в своей работе компонентов Exchange. Функции посредника возлагаются на фильтр Internet Server API (ISAPI) в IIS 6.0, поэтому единственное требование к системе — наличие Windows 2003. Во-вторых, proxy-сервер RPC — простая функция IIS 6.0, поэтому его можно разместить на системе Exchange 2003. И в-третьих, на системе Exchange 2003 можно разместить и GC-сервер, хотя делать этого не рекомендуется, чтобы не снижалась производительность и сохранялась корректность технических решений. Поэтому все серверные компоненты, показанные на рисунке 1, могут сосуществовать на одной серверной машине.

Следует также рассмотреть возможность размещения сервера относительно внутренних и внешних брандмауэров и образуемой в результате демилитаризованной зоны (DMZ). Proxy-сервер RPC можно разместить в DMZ, а серверы Exchange и другие серверы Active Directory (AD) — во внутренней части сети (рисунок 2). Но поскольку во внутреннем брандмауэре требуется открыть больше портов, данная конфигурация связана с излишним риском и использовать ее обычно не рекомендуется. Риск особенно высок при динамическом назначении портов, которые открываются для RPC-соединений между proxy-сервером RPC и почтовым сервером Exchange 2003. Теоретически эти порты лежат в диапазоне от 1024 до 65535, но в процессе реализации RPC over HTTP требуется определить более узкий диапазон (от порта 6001 до порта 6004). Диапазон задается с помощью параметров реестра, которые будут рассмотрены в следующем разделе. В дополнение к портам, показанным на рисунке 2, proxy-сервер RPC может затребовать порт 88 (UDP/TCP) для служб Kerberos, порт 53 (UDP/TCP) для запросов DNS, порт 445 для Server Message Block (SMB) службы NetLogon и порты для любых других протоколов, необходимых для управления и мониторинга служб.