Pull to refresh
0
Microsoft
Microsoft — мировой лидер в области ПО и ИТ-услуг

DirectAccess в Windows 7. Часть 3

Reading time 4 min
Views 15K
В предыдущей части, посвященной DirectAccess, я рассмотрел транзитные технологии, обеспечивающие взаимодействие по IPv6 в среде IPv4, IPsec over IPv6 и модели доступа DA-клиентов к корпоративным ресурсам и остановился на таблице разрешения имен NRPT. Напомню, что NRPT используется только в том случае, когда DA-клиент находится в Интернете, или, иными словами, за пределами корпоративной сети. Соответственно, существует алгоритм, позволяющий DA-клиенту определить свое местоположение относительно корпоративной сети. Давайте рассмотрим этот алгоритм.

Определение местоположения

Суть довольно простая. При настройке DirectAccess в мастере DirectAccess Setup Wizard администратором задается некий URL (network location URL) (см. рис.1).image

Этот URL через групповые политики передается всем DA-клиентам и сохраняется в ключе реестра:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity\DomainLocationDeterminationUrl
Каждый раз, когда сетевое состояние DA-клиента меняется (компьютер перезагружается, в «сетевушку» вставляют кабель, WiFi-адаптер подключается к сети и пр.), клиент пытается соединиться с ресурсом, называемым Network Location Server (NLS), по заданному URL. Если это удается, DA-клиент считает, что он в корпоративной сети, если нет – в Интернете. По умолчанию DA-клиент всегда считает, что он за пределами корпоративной сети.
Более детально процедура выглядит следующим образом:
1. Разрешается полное доменной имя (FQDN), заданное в network location URL.
2. Устанавливается HTTPS соединение по 443 TCP-порту.
3. Проверяется SSL-сертификат сервера NLS.
4. Сертификат проверяется по списку отозванных сертификатов CRL, расположение которого задано в настройках DA-клиента.
После успешного соединения с сервером NLS, DA-клиент пытается обнаружить контроллер домена и выполнить аутентификацию. Если аутентификация прошла успешно, то сетка клиента переключается на доменный профиль. А поскольку все настройки DirectAccess, включая настройки IPsec, применяются только к сетевым профилям Public и Private, то эти настройки деактивируются, деактивируется NRPT, и DA-клиент работает как любые другие обычные доменные компьютеры.
Из этого алгоритма можно сделать несколько важных выводов.
1. Network location URL должен разрешаться только внутренними серверами DNS и не должен разрешаться каким-либо внешним DNS-сервером.
2. Поскольку связь с сервером NLS является критичным для определения местоположения DA-клиента, необходимо обеспечить адекватный уровень доступности и отказоустойчивости этого ресурса.
3. Также необходимо озаботиться уровнем доступности CLR.
Что произойдет, если будучи в доменной сети DA-клиент не сможет достучаться до NLS? Очевидно, DA-клиент посчитает, что находится в Интернете, и попытается установить туннель до внешнего интерфейса DA-сервера. И если ему это удастся, то будет работать с внутренними ресурсами так, как если бы находился за пределами корпоративное сети, то есть через DA-сервер. Естественно, что, во-первых, это порождает лишний трафик и снижает скорость сетевого взаимодействия, во-вторых, клиент получит доступ только к тем внутренним ресурсам, которые разрешены политикой DirectAccess. Если же до внешнего интерфейса DA-сервера достучаться не удалось, то короткие имена еще есть шанс разрешить с помощью других, кроме DNS, механизмов, например, Link-Local Multicast Name Resolution или NetBIOS.

Требования к инфраструктуре для развертывания DirectAccess

Теперь, когда основные механизмы DirectAccess рассмотрены, можно обсудить требования к инфраструктуре для развертывания технологии.
DA-клиент:
1. Windows 7 Ultimate или Enterprise или Windows Server 2008 R2
2. Член домена Active Directory
DA-сервер:
1. Windows Server 2008 R2
2. Член домена Active Directory
3. Минимум два сетевых адаптера, подключенных один в Интернет, один в интранет
4. Два последовательных публичных IPv4-адреса для корректной работы транзитных технологий. Конкретно, технология Teredo требует два айпишника. По RFC они не должны быть последовательными, но в текущей реализации DirectAccess требование именно такое.
Сеть:
1. Active Directory. Как минимум один контроллер домена под Windows Server 2008 (не обязательно R2)
2. Развернутая инфраструктура открытого ключа (Public Key Infrastructure, PKI) для выпуска компьютерных сертификатов. Последние необходимы для аутентификации при установке туннеля
3. Поддержка IPv6 и транзитных технологий на устройствах, к которым будет предоставлен доступ DA-клиентам. Напомню, в ОС Microsoft такая поддержка появилась, начиная с Windows XP

Развертывание DirectAccess

Я записал небольшой видеоролик, где показал основные шаги по настройке DirectAccess и заодно еще раз пояснил некоторые технологические моменты. При этом я оставил за кадром все, что не связано непосредственно с DirectAccess, например, развертывание PKI.
За более подробной информацией, которой теперь уже предостаточно, можно обратиться на соответствующий раздел портала TechNet.

Заключение

В заключение я хотел бы еще раз обозначить основные особенности DirectAccess. Можно, наверное, долго спорить о терминологии: является ли DirectAccess неким вариантом-расширением VPN или нет. Я сталкивался с разными точками зрения на этот вопрос. Например, DirectAccess – VPN на стероидах. Или, VPN – это временный доступ пользователя в корпоративную сеть снаружи, а DirectAccess – постоянное предоставление внутренних ресурсов наружу удаленным пользователям. Но, мне кажется, в конечном счете, это не так важно. Важно при организации удаленного доступа пользователей к внутренним ресурсам помнить про DirectAccess следующее:
1. DA обеспечивает прозрачное подключение удаленных пользователей к корпоративной сети. От самого пользователя при этом дополнительно не требуется ничего.
2. DA-соединение устанавливается и восстанавливается автоматически, как только появляется связь с Интернет (с DA-сервером).
3. При установке соединения DA аутентифицируется и компьютер, и пользователь. Подключение по DA возможно только с определенных машин, указанных администратором.
4. По умолчанию DA реализует разделение трафика: трафик к локальным ресурсам идет по туннелю через DA-сервер в корпоративную сеть, трафик к внешним ресурсам – через текущего ISP-провайдера в Интернет.
5. Поскольку при использовании DA клиенты всегда подключены к корпоративной сети (пока есть связь), DA-клиенты всегда находятся под управлением ИТ-служб.
6. Это не «очередные костыли Microsoft к VPN» :). DA основан на IPv6, который как раз лишен многих проблем и ограничений традиционных VPN по IPv4.
Пожалуй, пока все.
Tags:
Hubs:
+8
Comments 4
Comments Comments 4

Articles

Information

Website
www.microsoft.com
Registered
Founded
Employees
Unknown
Location
США