BranchCache и DirectAccess: улучшение работы систем филиалов

Покаосновные массы впервые взглянули на Windows Server 2008 R2 и Windows 7, избранные уже работали с версией-кандидатом в мае, а с основной коммерческой версией в августе. К какой бы группе вы не относились, возможно, вы уже были засыпаны различной рекламой. Возможно, вас, как и меня, приглашали на «домашнюю вечеринку» предварительного просмотра Windows 7. (Мой зять посетил одну такую, но только чтобы получить бесплатное программное обеспечение Microsoft.) Даже если вы пережили основную рекламу, вы не смогли избежать большого количества сообщений СМИ, восхвалявших и рассматривающих новые функции данных продуктов из нового кодового дерева, которые составляют новые операционные системы.

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

Как это бывает обычно с компанией Microsoft, вы получаете хорошие штучки в новых продуктах. В данном случае вы можете только внедрить клиенты BranchCache в Windows 7 и серверы 2008 R2. Давайте посмотрим эти новые функции подробнее.

BranchCache

Функция BranchCache улучшает работу систем филиалов локальным кэшированием часто используемых файлов, как на сервере Windows Server 2008 R2, так и на пользовательских рабочих станциях, вместо того, чтобы заставлять пользователей получать доступ к файлам через централизованные сетевые ресурсы. Функция BranchCache хороша, но есть ряд предостережений.

Функцию BranchCache можно развернуть в режиме распределенного кэша, либо в режиме кэширования хоста (см. рис. 1). ИТ-специалисты настраивают режим через групповую политику, поэтому использование режима кэширования хоста в одном офисе и режима распределенного кэша в другом, требует внедрение двух политик и соответствующее планирование структурных подразделений (OU). Компания Microsoft рекомендует применять режим распределенного кэша на узлах с 50 или менее клиентами, но это зависит от скорости и пропускной способности WAN, а также от других факторов. Режим распределения кэша потребует наличия жестких дисков большого размера и, возможно, больше памяти и других ресурсов, поэтому в некоторых случаях будет лучше использовать режим кэширования хоста, особенно, если на узле имеется сервер 2008 R2. Кроме того, режим распределенного кэша может использоваться только в локальной подсети. Поэтому если на узле имеется несколько подсетей, то клиент каждой подсети должен кэшировать файл для других клиентов данной подсети. Однако режим кэширования хоста может обслуживать несколько подсетей, что является еще одной причиной в пользу выбора режима кэширования хоста.

Рис. 1 Филиал может использовать функцию BranchCache как в режиме распределенного кэша, так и в режиме кэширования хоста.

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

Например, Каролина запрашивает документ, Reports.docx с файлового сервера BranchCache, расположенного в центральном офисе. Функция BranchCache отправляет метаданные с описанием содержимого файла. Хэши в метаданных используются для поиска содержимого в локальной подсети. В случае неудачного поиска, копия кэшируется на локальный диск ее компьютера. Позже Тайлеру понадобиться изменить документ Reports.docx, и он связывается с хранилищем файлового сервера в основном офисе для редактирования копии. Файловый сервер возвращает метаданные, затем клиент выполняет поиск содержимого, находит его и загружает с компьютера Каролины. Это выполняется в безопасном режиме при помощи ключа шифрования, получаемого из хэша, содержащегося в метаданных. На следующий день Абигайль необходимо изменить этот же документ. Процесс аналогичен, но она откроет копию, сохраненную на компьютере Тайлера. Опять же, информация о версии содержится на сервере. Клиенты связываются с сервером для того, чтобы определить, есть ли копия последней версии на узле.

Это один из трех сценариев BranchCache, который появится во время работы пользователей с различными документами. Два других:

• Сотрудник филиала запрашивает документ с файлового сервера в основном офисе, который не кэширован на локальный компьютер. Пользователь получает копию, которая кэширована локально.
• Сотрудник филиала запрашивает документ с файлового сервера, который кэширован на локальный узел, но компьютер отключен. Клиент получает новую копию с файлового сервера и кэширует ее на свой компьютер. Последующие запросы будут приводить к этой только что кэшированной копии.

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

В режиме кэширования хоста ИТ-специалисты настраивают файловый сервер Windows 2008 R2 в филиале, установив функцию BranchCache и настроив групповую политику, чтобы клиенты использовали режим кэширования хоста. Процедура, описанная для режима распределенного кэша, работает аналогично, но файлы кэшируются локально на настроенном сервере BranchCache, а не на компьютерах пользователей.

Примечание. метаданные содержимого, хранящиеся на файловом сервере основного офиса, посылаются каждому клиенту, если файл запрашивается с сервера BranchCache. Это используется для определения того, имеется ли последняя копия на локальном клиенте или сервере (в зависимости от используемого режима кэширования).

Сервер BranchCache узла филиала может использоваться и в других целях, например в качестве веб-сервера или сервера обновлений Windows Server Update Services (WSUS). В данном случае имеется ряд сложностей, описанных в «Руководстве Microsoft по развертыванию и в «Руководстве Microsoft для начинающих: ».

Настройка BranchCache

Для того чтобы настроить BranchCache, вам необходимо понять работу объектов групповой политики (GPO), а также порядок их настройки в вашем структурном подразделении для влияния на компьютеры каждого узла. Необходимо помнить, что все серверы, вовлеченные в сценарий BranchCache, должны быть на основе Windows Server 2008 R2, а все клиенты — Windows 7. Ниже приведен процесс:

Этап 1. Устанавливаем функцию BranchCache feature через диспетчер серверов.

Этап 2. Если вы используете BranchCache на файловом сервере, вам придется установить роль файловых служб, наряду с BranchCache для получения удаленных файлов (см. рис. 2).

Рис. 2. Установка BranchCache требует включения роли файловых служб и ее использования наряду с BranchCache для получения удаленных файлов.

Этап 3. Настройка объекта групповой политики BranchCache. Перейдите на Computer Configuration | Policies | Administrative Templates | Network | BranchCache. Вы увидите пять возможных настроек:

• Включить BranchCache. Это необходимо включить для кэширования всех филиалов (см. рис. 3). Помните, что включение функции BranchCache без активации настроек политики режимов распределенного кэша или кэшированного хоста приведет к тому, что клиент Windows 7 будет кэшировать файлы локально. Это может быть полезно, если несколько пользователей используют один компьютер.

Рис. 3 Включите BranchCache в консоли управления групповой политикой (GPMC) для кэширования файлов филиала.

• Установить режим распределенного кэша BranchCache. Применяется ко всем клиентам в объекте групповой политики.
• Установить режим кэширования хоста BranchCache. Определите сервер для хранения кэша. Эти роли являются взаимоисключающими. Только одна из них может быть установлена для одного узла.
• Настройка BranchCache для сетевых файлов. Если данная функция не настроена или отключена, то пороговое значение задержки составляет 80 мс. Если время запроса составляет более 80 мс, то файл кэшируется. Активируйте данную настройку и измените значение задержки по желанию.
• Установка процентного соотношения дискового пространства, используемого для хранения кэша клиентского компьютера. По умолчанию данная настройка установлена на 5 % от пространства диска. Вам придется поэкспериментировать, чтобы добиться оптимального соотношения. Это может стать проблемой, если ваши диски отличаются по размеру, и поэтому некоторые диски будут иметь лучшие возможности кэширования, нежели другие.

Этап 4. Установка настройки GPO «LanMan Server» в политике BranchCache. Так же как и при настройке GPO на этапе 3, перейдите к настройке LanMan Server и посмотрите свойства «Hash Publication for BranchCache». Там имеется три варианта:

• Отменить публикацию хэшей для общих папок.
• Разрешить публикацию хэшей для всех общих папок.
• Разрешить публикацию хэшей для всех общих папок с включенной функцией BranchCache.

Серверы, использующие роль сервера файловых служб на серверах 2008 R2, которые должны быть серверами содержимого BranchCache, также должны запустить BranchCache для роли служб сетевых файлов, а также должна быть активирована публикация хэшей. Функция BranchCache также отдельно активируется на файловых ресурсах. Публикация хэшей может активироваться отдельно на сервере (например, настройка сервера не входящего в домен), или для группы серверов через групповую политику. Таким образом, функцию BranchCache можно активировать для всех общих папок, только для некоторых общих папок или полностью отключить.

Этап 5. Настройка GPO в брандмауэре Windows для разрешения входящего порта TCP 80 (применяется к клиентскому компьютеру).

Этап 6. После того как вы настроили файловые ресурсы и файлы пользователей, перейдите к Server Manager | File Services | Share and Storage Management. Центральная панель содержит списки ресурсов. Щелкните по ресурсу правой кнопкой мыши и выберите вкладку Properties, затем щелкните Advanced. На вкладке Caching активируйте функцию BranchCache (см. рис. 4). Примечание. Если опция BranchCache недоступна, то функция BranchCache была установлена неправильным образом или отключена политикой, как отмечалось ранее.

Рис. 4 Включите совместное использование файлов для функции BranchCache с помощью элементов управления на вкладке Share and Storage Management.

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

По умолчанию на всех клиентах Windows 7 активирована функция BranchCache, то есть, на самом клиенте ничего активировать не надо. Однако имеются некоторые этапы работы с клиентом:

• Настройка параметров брандмауэра. Хотя это и обсуждалось ранее, существуют и другие требования к режиму кэшированного хоста. Обратитесь к документам по функции BranchCache, указанным в конце данной статьи.
• Клиенты находятся в структурном подразделении с политикой, активирующей функцию BranchCache и определяющей режим кэширования.

BranchCache — плюсы

Вот что мне нравится в BranchCache:

• Можно использовать фоновую интеллектуальную систему передачи (BITS) для активации передачи файлов в фоновом режиме при входе пользователя в систему, даже при выходе из приложения. Эта очень хорошая возможность для филиалов с медленными сетевыми каналами. При необходимости перезагрузки системы, передача файлов будет продолжена до ее завершения. Чтобы это работало, должны быть написаны приложения для использования преимуществ системы BITS.
• Функцию BranchCache можно настроить с помощью утилиты командной строки Netsh, а информация о ней хорошо представлена на сайте ».
• Вы можете проверить производительность BranchCache при помощи счетчиков для клиентов, файловых серверов и хостов кэширования. Они будут очень полезны при диагностике. Я с уверенностью могу сказать, что эти счетчики являются единственным способом проверить, получает ли клиент кэшированную копию.
• Среда BranchCache контролируется через групповую политику.

BranchCache — минусы

BranchCache, конечно же, находится на своем месте, но остерегайтесь недостатков:

• Так как в режиме распределенного кэша каждая рабочая станция превращается в файловый сервер, клиентские машины, размещающие большое количество часто используемых файлов, могут испытывать снижение производительности. Для определения действительного влияния потребуется тестирование.
• В некоторых случаях клиентам может потребоваться дополнительное пространство на диске для обеспечения достаточного размера кэширования.
• Клиенты кэширования будут конкурировать с вашими коллегами за сетевые ресурсы.
• Могут появиться задержки во время начального процесса кэширования или в случае, если файл недоступен в кэше. Только клиенты Windows 7 и серверы Windows Server 2008 R2 могут принимать участие в процессе, поэтому полное развертывание данной функции может занять много времени.

Если вы можете оправдать использование файлового сервера в филиале, почему бы тогда не использовать распределенный общий файловый ресурс (DFS)? Вместо того чтобы возиться с кэшированными файлами, вы можете использовать репликацию распределенной системы файлов (DFS-R) для репликации файлов и поддержки пространства имен с помощью DFS. Возможно, вы найдете преимущества в кэшировании сетевых файлов, и функция BranchCache будет работать с общими папками DFS. Или, возможно, вы найдете некоторые пограничные состояния производительности, при которых использование кэширования будет эффективнее, чем использование DFS-R. С другой стороны, влияние на сервер со стороны BranchCache будет меньше, нежели со стороны полнофункциональной конфигурации DFS. Таким образом, вам нужно узнать свои потребности и рассмотреть все доступные возможности BranchCache. Конечно, каждая среда отличается, и это может вызвать проблемы в некоторых филиалах, а в других — нет. Не существует универсального ответа для всех случаев.

DirectAccess

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

Фактически, с точки зрения пользователя функция DirectAccess невидима. Если пользователь с включенным клиентом щелкает ссылку интрасети, DirectAccess имеет дело с подключениями и отключениями. Пользователям не нужно открывать диспетчер подключений, вводить свои учетные данные, ждать установки подключения и т.д.

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

Рис. 5. DirectAccess позволяет настроить «разделенное туннелирования» для одновременного подключения к корпоративной сети и Интернету.

С точки зрения ИТ-специалистов, если компьютер подключен к сети Интернет (помните, что функция DirectAccess всегда включена, если она установлена), то проще применять исправления, политики и другие обновления. А также они более безопасны через подключения IPsec.

Требования к DirectAccess

В базовых настройках DirectAccess сервер DirectAccess находится в пограничной сети, обеспечивая пользователям удаленное подключение к внутренним ресурсам, включая серверы приложений, центры сертификации, DNS и контроллеры доменов. Центры сертификации и серверы приложений должны быть настроены на прием IPv6-трафика. Ниже приведены важные компоненты настроек DirectAccess:

• В домене Active Directory клиенты DirectAccess смогут получать доступ только к контроллерам домена Windows 2008 или 2008 R2.
• Определения групповой политики должны обеспечить настройки DirectAccess для:
  • определения клиентов DirectAccess;
  • настройки таблицы политики разрешения имен (NRPT);
  • удаления протокола ISATAP (Intra-Site Automatic Tunneling Address Protocol) из списка глобального ограничения DNS.

• Сервер DirectAccess должен:
  • входить в домен Active Directory;
  • работать на сервере Windows Server 2008 R2;
  • иметь два настроенных сетевых адаптера (один – для подключения к интрасети, другой – для подключения к сети Интернет);
  • иметь два внешних отображаемых последовательных статических адреса IPv4;

• иметь средство управления DirectAccess (через диспетчер серверов), а также мастера установки для работы с настройками.

• IIS/веб-сервер предоставляет функциональную возможность определения ресурсов интрасети. Серверы приложений должны быть настроены для разрешения доступа клиентам DirectAccess.
• Для использования с необходимыми центрами сертификации установите службы сертификации Active Directory и выдайте сертификаты для проверки подлинности.
• В пределах интрасети должны быть доступны как собственная сеть IPv6, так и технологии перехода.
• Использование политик IPsec для безопасной проверки подлинности и шифрования подключения DirectAccess позволяют клиенту проверять подлинность перед входом пользователя в систему.
• Необходимую информацию об исключениях брандмауэра можно найти в Руководстве Microsoft для начинающих: DirectAccess.

Как видите, утилита DirectAccess предназначена не для слабых духом. Одно лишь требование IPv6 может вызвать обеспокоенность, а также необходимость внедрения большинством организаций технологий перехода, хотя сервер 2008 R2 имеет данные компоненты. Кроме того, вы должны активировать средства безопасности с помощью инфраструктуры открытого ключа (PKI), предоставить службы проверки подлинности и настроить идентификацию IPv6 для серверов приложений. Перед запуском мастера установки DirectAccess вы также должны настроить группы безопасности, установить политики брандмауэра, установить DNS и выполнить большое количество других требований.

Сервер DirectAccess

Сервер DirectAccess выполняет ряд функций, определенные в мастере установки DirectAccess диспетчера серверов (см. рис. 6).

Рис. 6. Установка DirectAccess с помощью диспетчера серверов.

Мастер DirectAccess выполняет четыре основные задачи. С помощью мастера вы можете:

1. Определить клиентов, которые будут использовать DirectAccess. Вы можете получить список групп безопасности из других доменов или лесов, если настроены доверия домена. Вы должны определить соответствующие группы безопасности перед запуском мастера установки.
2. Определить тип подключения и обеспечение безопасности (сертификаты) для сервера DirectAccess. Вы определите тип сетевого интерфейса со стороны Интернет, а также интерфейс подключения к интрасети. Установить центр сертификации и создать сертификаты до запуска мастера установки. Кроме того, вы можете определить политику смарт-карт.
3. Определить DNS, контроллер домена; дополнительно, серверы управления и другие серверы инфраструктуры для использования в среде DirectAccess. Также вы должны определить сервер с высоким уровнем доступности в качестве сервера сетевого ресурса. Сервер DirectAccess может выполнить эту роль.
4. Определить серверы приложений, настроенные на прием подключений с клиентами DirectAccess. По умолчанию отсутствует дополнительная сквозная авторизация, но вы можете выбрать компоненты безопасности на основе политики IPsec.

DNS и NRTP

Как отмечалось выше, клиенты DirectAccess могут получать непосредственный доступ к интрасети. Для этого вы должны внедрить таблицу NRPT, которая определяет DNS-серверы на основе пространства имен DNS, а не на основе сетевого интерфейса. Я вижу это как некие условные работы по пересылке DNS на серверах Windows 2003 и 2008, на которых вы можете определить пространства имен DNS с соответствующими IP-адресами для подключения к серверу. Таблица NRPT позволяет клиенту избегать обычных итераций DNS и переходить непосредственно к серверу DirectAccess.

Ниже представлена работа таблицы NRPT (см. рис. 7):

1. Запрос об имени совпадает с настроенным пространством имен для корпоративной интрасети, указывая на сервер DirectAccess.
2. Таблица NRPT содержит IP-адреса и полное доменное имя (FQDN) сервера DirectAccess. Если используется IP-адрес, подключение к DNS-серверу шифруется для обеспечения безопасного подключения.
3. Если используется полное доменное имя FQDN, оно должно быть разрешено в сети Интернет и открывается через корпоративный DNS-сервер.
4. Если клиент посылает запрос разрешения имен для пространства имен, не определенного в таблице NRPT (такое как www.microsoft.com), то он обращается к обычному разрешению имен через сеть Интернет.

Рис. 7. Таблица NRPT позволяет определять серверы DNS по пространствам имен, а не по интерфейсу.

Таблица NRPT настраивается во время процесса установки DirectAccess на странице установки инфраструктуры сервера, а мастер установки заполняет адрес IPv6 DNS-сервера. Политика разрешения имен, новый параметр групповой политики для 2008 R2, определяет уникальные параметры политики, например, IPsec, DNS-сервер, и способ отката пространства имен, если пространство имен не входит в запрашиваемую сеть. Вы найдете это в Computer Configuration | Windows Settings | Name Resolution Policy (важно отметить, что вы должны заполнить пространства имен с предшествующей точкой «.», например, .emea.corp.net).

Вы можете открыть содержимое таблицы NRPT, используя команду Netsh: Netsh name show policy.

При выполнении данной команды я смогу увидеть все определенные пространства имен.

Исключения брандмауэра

Исключения брандмауэра будут зависеть от того, каким образом вы будете применять сеть IPv6, и будете ли вы применять технологии перехода. Кроме того, брандмауэр Windows должен быть правильно настроен для любого файла или серверов приложений, к которым должны подключиться удаленные клиенты. В табл. 8 и табл. 9 показаны исключения для брандмауэра со стороны сети Интернет и интрасети сервера DirectAccess, соответственно. Очевидно, что вам понадобится установить исключения для используемых вами исключений. (Помните, что хотя и на табл. 2 описывается IPv4+NAT-PT, это все не внедрено в Windows 2008 R2.)

Табл. 1. Параметры брандмауэра для брандмауэров Интернета

Табл. 2. Параметры брандмауэра для брандмауэров интрасети

Подключение через IPv6

В силу того, что технология IPv6 разрешает клиентам DirectAccess поддерживать непрерывное подключение к ресурсам корпоративной сети, все они должны работать с данным протоколом. Даже если у вас имеется полностью реализованная сеть IPv6, позволяющая использовать удаленное подключение, может потребоваться использование технологии перехода, которая позволила бы клиентам DirectAccess подключаться к ресурсам IPv4 при помощи инкапсуляции IPv6 внутри пакетов IPv4. Сюда входят технологии 6to4, IP-HTTPS и Teredo. ISATAP также является технологией инкапсуляции, но только для внутреннего использования. В данной статье я не буду предоставлять подробных описаний, но в табл. 10 показаны основные параметры подключения.

Табл. 10.  Предпочтительные параметры подключения для клиентов DirectAccess

 Источник: корпорация Майкрософт

Со стороны интрасети, без собственной сети IPv6, в DirectAccess разрешается использование протокола ISATAP, который генерирует адрес IPv6 из адреса IPv4 и применяет собственный поиск соседей. Протокол ISATAP использует клиентов на основе DirectAccess для получения доступа к ресурсам в сети IPv4. Например, при загрузке клиента ISATAP должен быть обнаружен маршрутизатор ISATAP. Это выполняется при помощи запроса DNS для протокола ISATAP.<domain name>, то есть для Corp.net поиск будет произведен для ISATAP.corp.net. Windows 2008 DNS внедряет GlobalQueryBlockList, дополнительную функцию обеспечения безопасности, включающую в себя протокол ISATAP по умолчанию. По этой причине запрос ISATAP.<domain name> игнорируется. Следовательно, вы должны удалить ISATAP из списка. Сделайте это с помощью команды DNSCMD или внесения записи в реестре.

В командной строке введите dnscmd /config /globalqueryblocklist wpad и нажмите «Ввод». Эта команда определит, что функция GlobalQueryBlockList имеет только WPAD (тем самым, удалив ISATAP). То же самое можно выполнить, перейдя к ключу реестра

HKLM:\System\Current Control Set\Services\DNS\Parameters. Отредактируйте GlobalQueryBlockList и удалите ISATAP.

Также можно отдельно внедрить технологию 6to4 для узлов или для всей сети и передать пакеты IPv6 через сеть IPv4. Что интересно, если применять технологию 6to4 ко всей сети, потребуется только один адрес IPv4. Трафик между узлами IPv4 и IPv6 не будет поддерживаться.

Технология Teredo также предоставляет возможность маршрутизации пакетов IPv6 в сети IPv4, но используется, только если клиент находится за сервером трансляции сетевых адресов (NAT), который не настроен на IPv6. Пакеты IPv6 сохраняются в датаграмме IPv4, позволяющей использование пересылки из NAT.

В Windows 7 и Server 2008 R2 внедрен протокол под названием IP-HTTPS, который туннелирует пакеты IPv6 в IPv4 HTTPS. Хотя протокол IP-HTTPS отличается низкой производительностью, по сравнению с другими протоколами, вы можете добавить дополнительные серверы IP-HTTPS для улучшения производительности. IP-HTTPS является достаточно простым протоколом для того, чтобы создать работоспособное сетевое подключение IPv6-over-IPv4.

При создании настроек клиента DirectAccess, вы можете использовать как DNS, так и NRPT для отделения Интернет-трафика от трафика интрасети, или вы можете использовать технологию под названием Force Tunneling (принудительное туннелирование) и пустить весь трафик через туннель. Технология принудительного туннелирования (Force Tunneling), для которого требуется протокол IP-HTTPS, включается через параметр групповой политики: Computer Configuration\Policies\Administrative Templates\Network\Network Connections\Route all traffic through the internal network. Эту политику нужно применить для клиентов DirectAccess. Я заметил, что клиенты DirectAccess могут получать доступ к локальным ресурсам, будучи подключенными к интрасети. Это остается верным и для клиентов IP-HTTPS, если пользователь пытается подключиться к узлам сети Интернет, а маршрутизация осуществляется через интрасеть.

Конечно, требования IPv6 и сложные настройки являются недостатками DirectAccess, но легко перевешиваются улучшениями в работе пользователей и упрощением удаленного управления клиентами для специалистов ИТ.

Многообещающие перспективы

Количество удаленных пользователей, которые находятся в филиале, главном офисе или в дороге, растет. Функции BranchOffice и DirectAccess выглядят многообещающими перспективами для филиалов и других удаленных сотрудников, а ИТ-менеджерам и администраторам придется поработать с ними. Они весьма непросты в установке и настройке. Кроме того, эти компоненты будут работать только с клиентами Windows 7 и серверами Windows Server 2008 R2, поэтому это повлияет на период времени, который потребуется для реализации. ИТ-менеджерам и администраторам следует изучить документацию Microsoft, произвести настройки в лаборатории тестирования для обеспечения успешной работы.