Microsoft — мировой лидер в области ПО и ИТ-услуг
185,27
рейтинг
20 января 2011 в 11:45

Разное → DirectAccess в Windows 7. Часть 3

В предыдущей части, посвященной 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.
Пожалуй, пока все.
Автор: @ashapo
Microsoft
рейтинг 185,27
Microsoft — мировой лидер в области ПО и ИТ-услуг

Комментарии (4)

  • 0
    Хотелось бы все же знать методы контроля DA на клиенте, хотя бы как пользователю его вкл/выкл.
    А то начальник с ноутом и 3G-модемом уезжает в Магадан, включает там инет, чтобы проверить почту, а его 7ка сама начинает апдейты с WSUSa сосать в роуминге.
    Back to VPN?
  • 0
    Чтобы отключить DA, надо выключить все связанные с ним IPsec Rules в Windows Firewall with Advanced Security. В видеоролике я их показал. Понятно, что для начальника надо просто скрипт написать и, например, вывести иконку на рабочий стол. Другим скриптом включить обратно. Есть еще вот такая утилитка, которая позволяет пользователю визуально видеть, установлено DA-соединение, или нет.
    technet.microsoft.com/en-us/library/ff384241.aspx
    И для диагностики полезна.
    Для длительного отключения DA, можно удалить нужный компьютерный account из группы, к которой применяются групповые политики DA.
    Что касается конкретной ситуации с WSUS, то тут можно больше вариантов придумать. Например, настраивать WSUS-клиента так, чтобы он не скачивал обновления, а только оповещал о том, что они доступны. Если, конечно, известно, когда и куда шеф едет.
    Но поскольку DA-клиент практически всегда подключен к корпоративной сети, то он практически всегд up-to-date, и реально ситуации, когда надо кучей накатить обновления, редки
    • 0
      спасибо)
  • 0
    Спасибо за статьи, а особенно за разъяснение работы DirectAccess в ipv4 сетях провайдеров.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное