Branchcache в windows 8.1 и windows server 2012 r2

Введение

Для обеспечения высокого уровня безопасности и фильтрации нежелательного трафика клиентские рабочие станции рекомендуются защищать при помощи сетевых экранов (брандмауэров). По умолчанию, в Windows 7 и Windows 2008 R2 используется встроенный сетевой экран. Более подробную информацию о нем можно получить из статьи » Что нового в брандмауэре Windows 7?»

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

В этой статье будут описаны:

• сетевые протоколы, используемые при передаче данных по технологии BranchCache,

• порты, соответствующие указанным протоколам,

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

В процессах запроса информации у сервера данных, поиска компьютеров, хранящих кэш, а также передаче кэша клиентом используются следующие протоколы передачи данных:

• : Peer Content Caching and Retrieval Discovery Protocol,

• : Peer Content Caching and Retrieval: Retrieval Protocol,

• : Peer Content Caching and Retrieval: Hosted Cache Protocol.

Рассмотрим их более подробно.

Установка компонента BranchCache

Для включения на сервере поддержки BranchCache необходима установка одноименного компонента (см. рис. 1) и настройка автоматического запуска службы «BranchCache».

Рис. 1. Установка компонента BranchCache

Для этого следует выполнить следующие действия.

1. Открыть оснастку «Диспетчер сервера».
2. Выбрать из списка пункт «Компоненты».
3. Нажать кнопку «Добавить компонентыs».
4. Поставить флажок напротив «BranchCache».
5. Нажать кнопку «Далее».
6. Нажать кнопку «Установить».
7. Закрыть окно установки и оснастку «Server Manager».
8. Открыть оснастку «Службы».
9. Зайти в свойства службы «BranchCache».
10. Убедиться, что установлен автоматический тип запуска.
11. Запустить службу.

Помимо этого, на сервере, планируемом для хранения файлов, необходима установка роли «Файловый сервер» и публикация данных для использования BranchCache. Рассмотрим это более подробно.

В локальной или доменной групповых политиках в разделе

Конфигурация компьютера\Административные шаблоны\Сеть\Сервер Lanman

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

Допустимы следующие значения этого параметра.

• Разрешить публикацию хэша для всех общих папок. Разрешает публикацию для всех сетевых папок.

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

• Запретить публикацию хэша на всех общих папках. Запрещает публикацию для всех сетевых папок (даже на тех, где разрешен BranchCache).

Для включения BranchCache на каждой сетевой папке следует выполнить следующие действия.

1. Зайти в свойства папки.
2. Перейти на закладку «Доступ».
3. Нажать кнопку «Расширенная настройка».
4. Перейти на вкладку «Кэширование».
5. Убедиться, что стоит флажок «Вне сети доступны только указанные пользователем файлы и программы» и щелкнуть по кнопке «Включить BranchCache».
6. Дважды нажать кнопку «Ок».

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

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

Возможные сценарии применения

Если суммировать всё то, что теперь сделано в сервисе BranchCache, то можно сказать следующее.

1. Сервис ощутимо улучшился, имеет смысл включать его через Group Policy на всех клиентских рабочих станциях – даже без выделенного сервера это крайне поможет в разгрузке сети. Один сотрудник открыл редко меняющийся документ с файл-сервера (“наш типовой договор”, “наш прайс-лист”), остальные, при запросе, заберут его у него локально.
2. Выделенный сервер BranchCache имеет смысл делать в любом регионе – его настройка упростилась, клиенты найдут его сами, в случае роуминга доп.настроек не надо – клиент видит Active Directory, знает свой сайт, видит SCP и подключается к ближайшему серверу.
3. Скорость первого подключения к серверу с кэшированным контентом ощутимо выросла – с хэшами новой версии тратится меньше трафика, плюс BranchCache “быстрее” предоставит клиенту список хэшей файла, к которому обращаются первый раз – хэши-то готовые уже лежат, дедупликатор их сгенерил, плюс отдавать будет хранилище на базе ESE, а не “просто папка на сервере”.
4. 4. Всё это встроено в ОС и не нуждается в доп.лицензировании.

Сплошные плюсы – ну, а как Вы будете использовать эту технологию, думается, Вы придумаете сами.

Удач!

Подготовка к установке и настройки Directaccess сервера

И так, пожалуй, начнем настройку сервера, отведенного под Directaccess, с конфигурирования сетевых интерфейсов.

Сетевые интерфейсы на Directaccess сервере

На скриншоте видно, что сервер обладает 2-я сетевыми интерфейсами. Для удобства я их переименовал в LAN и WAN.

Настройка внутренего сетевого интерфейса

В настройках LAN интерфейса, смотрящего в сеть периметра необходимо настроить IPv4 адрес, маску подсети, а также DNS сервера. Так как это пограничный сервер на нем должен быть только один шлюз по умолчанию и прописан на внешнем интерфейсе. Если же сеть периметра многосегментная и скажем, что каждый сегмент обладает маской подсети /24, необходимо будет создать новые статические маршруты в таблице маршрутизации сервера. Для этого стоит воспользоваться следующим выражением:

где 172.16.20.0 — удаленная подсеть, 255.255.255.0 — ее маска и 172.16.20.1 маршрутизатор на который будут адресованы пакеты в удаленную подсеть. Ключ –p создаст постоянный маршрут в таблице маршрутизации и конфигурация сохранится после перезагрузки сервера. Для того чтобы посмотреть текущею таблицу маршрутизации сервера необходимо использовать следующее выражение:

Настройка внешнего сетевого интерфейса

В настройках внешнего сетевого интерфейса были отключены все ненужные службы. Этот шаг поможет минимизировать возможную площадь атаки.

Дополнительная настройка внешнего сетевого интерфейса

На внешнем интерфейсе необходимо настроить IPv4 адрес, маску подсети, а также шлюз по умолчанию. DNS сервера настраивать не нужно.

Добавление дополнительного сетевого адреса и маски подсети

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

Настройка дополнительной конфигурации DNS сетевого интерфейса

Во вкладке DNS снимаем чек-бокс, а также задаем DNS суффикс.

Настройка дополнительной конфигурации WINS сетевого интерфейса

Далее в настройках WINS необходимо отключить LMHOST, а также NetBIOS.

Дополнительные настройки сети

Далее, в окне сетевых настроек необходимо зажать «Alt» и появится меню. В нем, во вкладке дополнительно, необходимо выбрать дополнительные настройки.

Настройка приоритетов сетевых интерфейсов

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

Требования к программному обеспечению

Рабочие папки предъявляют следующие требования к программному обеспечению файловых серверов и сетевой инфраструктуры:

• сервер с Windows server 2019, Windows Server 2016 или Windows Server 2012 R2 для размещения общих папок синхронизации с файлами пользователей

• Том, отформатированный в файловой системе NTFS, для хранения пользовательских файлов.

• Для принудительного применения политики паролей на ПК под управлением Windows 7 необходимо использовать групповые политики паролей. Также следует исключить компьютеры под управлением Windows 7 из политик пароля рабочих папок (если они используются).

• Сертификат сервера для каждого файлового сервера, на котором будут размещаться рабочие папки. Эти сертификаты должны быть выданы центром сертификации (ЦС), которому доверяют пользователи — в идеале общедоступным ЦС;

• Используемых лес служб домен Active Directory с расширениями схемы в Windows Server 2012 R2 для поддержки автоматического обращения компьютеров и устройств к правильному файловому серверу при использовании нескольких файловых серверов.

Чтобы обеспечить пользователям возможность синхронизации через Интернет, необходимо выполнить дополнительные требования:

• возможность предоставить доступ к серверу через Интернет путем создания правил публикации на обратном прокси-сервере организации или сетевом шлюзе;

• (необязательно) открыто зарегистрированное доменное имя и возможность создать дополнительные общедоступные записи DNS для домена;

• (Необязательно) Инфраструктура служб федерации Active Directory (AD FS) при использовании проверки подлинности AD FS.

Рабочие папки предъявляют следующие требования к программному обеспечению клиентских компьютеров:

• Компьютеры и устройства должны работать под управлением одной из следующих ОС:

  • Windows 10

  • Windows 8.1

  • Windows RT 8.1

  • Windows 7

  • Android 4.4 KitKat и более поздние версии;

  • iOS 10.2 и более поздних версий.

Примечание

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

• На ПК под управлением Windows 7 должна быть установлена одна из следующих версий Windows:

  • Windows 7 Профессиональная

  • Windows 7 Максимальная

  • Windows 7 Корпоративная

• Компьютеры с Windows 7 должны быть присоединены к домену организации (их нельзя присоединить к рабочей группе).

• Достаточное свободное пространство на локальном диске, отформатированном в NTFS, для хранения всех пользовательских файлов в рабочих папках, а также 6 ГБ дополнительного свободного пространства, если рабочие папки размещаются на системном диске (по умолчанию). По умолчанию расположение рабочих папок следующее: %USERPROFILE%\Work Folders

  Однако пользователи могут изменить это расположение во время установки (поддерживается размещение на картах microSD и USB-накопителях, отформатированных в файловой системе NTFS, хотя в случае удаления накопителей синхронизация будет прекращена).

  Максимальный размер отдельного файла по умолчанию составляет 10 ГБ. Размер хранилища на пользователя не ограничен, но администраторы могут установить квоты при помощи функции диспетчера ресурсов файлового сервера.

  

  

  

  

  

  

  

  

  

  

• Рабочие папки не поддерживают откат состояния клиентских виртуальных машин. Вместо этого операции архивации и восстановления выполняются на клиентских виртуальных машинах с помощью компонента «Резервная копия образа системы» или другого приложения для архивации.

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

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

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

Если клиент назначен на:	Предпочтительный метод подключения:
Глобально маршрутизируемый адрес IPv6	Глобально маршрутизируемый адрес IPv6
Общий адрес IPv4	6to4
Частный адрес (NAT) IPv4	Teredo
Если клиент не может подключиться с помощью всех способов, перечисленных выше.	IP-HTTPS

Со стороны интрасети, без собственной сети 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, но легко перевешиваются улучшениями в работе пользователей и упрощением удаленного управления клиентами для специалистов ИТ.

BranchCache deployment requirements

Following are the requirements for deploying BranchCache by using this guide.

• File and Web content servers must be running either Windows Server 2008 R2 or Windows Server 2012 to provide BranchCache functionality. Windows 8 clients continue to see benefits from BranchCache when accessing content servers that are running Windows Server 2008 R2, however they are unable to make use of the new chunking and hashing technologies in Windows Server 2012.

• Client computers must be running Windows 8 to make use of the new deployment model and the chunking and hashing improvements.

• Hosted cache servers must be running Windows Server 2012 to make use of the deployment improvements and scale features described in this document. A computer that is running Windows Server 2012 that is configured as a hosted cache server can continue to serve client computers that are running Windows 7, but to do so, it must be equipped with a certificate that is suitable for Transport Layer Security (TLS), as described in the BranchCache Deployment Guide for Windows Server 2008 R2 and Windows 7.

• An Active Directory domain is required to take advantage of Group Policy and hosted cache automatic discovery, but a domain is not required to use BranchCache. You can configure individual computers by using Windows PowerShell. In addition, it is not required that your domain controllers are running Windows Server 2012 to utilize new BranchCache Group Policy settings; you can import the BranchCache administrative templates onto domain controllers that are running other operating systems, or you can author the group policy objects remotely on other computers that are running Windows 8 or Windows Server 2012.

• Active Directory sites are used to limit the scope of hosted cache servers that are automatically discovered. To automatically discover a hosted cache server, both the client and server computers must belong to the same site. BranchCache is designed to have a minimal impact on clients and servers and does not impose additional hardware requirements beyond those needed to run their respective operating systems.

BranchCache history and documentation

BranchCache was first introduced in Windows 7 and Windows Server 2008 R2, and is improved in Windows Server 2012 and Windows 8. For more information about BranchCache in Windows Server 2012 and Windows 8, including security information and a comprehensive list of new features, see BranchCache overview.

For more information about new BranchCache features, see What’s New in BranchCache.

Note

For information about BranchCache in Windows 7 and Windows Server 2008 R2, see http://branchcache.com and BranchCache for Windows Server 2008 R2.

BranchCache 프로세스: 콘텐츠 요청

첫 번째 단계에서는 지점의 클라이언트 컴퓨터가 본사와 같이 원격 위치에 있는 콘텐츠 서버에서 파일 또는 웹 페이지 등의 콘텐츠를 요청합니다. 그러면 콘텐츠 서버에서 클라이언트 컴퓨터가 요청한 콘텐츠를 받을 권한이 있는지 확인합니다. 클라이언트 컴퓨터에 권한이 있고 콘텐츠 서버와 클라이언트는 BranchCache 경우-콘텐츠 서버는 콘텐츠 정보 생성을 사용 합니다.

그런 다음 콘텐츠 서버는 실제 콘텐츠에 사용되는 것과 같은 프로토콜을 사용하여 콘텐츠 정보를 클라이언트 컴퓨터로 보냅니다.

예를 들어 클라이언트 컴퓨터가 HTTP를 통해 웹 페이지를 요청한 경우 콘텐츠 서버는 HTTP를 사용하여 콘텐츠 정보를 보냅니다. 따라서 콘텐츠와 콘텐츠 정보의 유선 수준 보안은 동일하게 보장됩니다.

클라이언트 컴퓨터는 초기 콘텐츠 정보 부분(데이터 해시 + 세그먼트 암호)를 받으면 다음 작업을 수행합니다.

• 세그먼트 암호(Kp)를 암호화 키(Ke)로 사용합니다.

• Hod 및 Kp에서 세그먼트 ID(HoHoDk)를 생성합니다.

이 계정에서 가장 큰 위협은 세그먼트 암호 관련 위험이지만, BranchCache는 콘텐츠 데이터 블록을 암호화함으로써 세그먼트 암호를 보호합니다. 이를 위해 BranchCache는 콘텐츠 블록이 있는 콘텐츠 세그먼트의 세그먼트 암호에서 파생되는 암호화 키를 사용합니다.

이러한 방식이 사용되므로 서버 암호를 소유하고 있지 않은 엔터티는 데이터 블록의 실제 콘텐츠를 검색할 수 없습니다. 지정된 세그먼트의 세그먼트 암호를 알고 있으면 엔터티가 피어로부터 세그먼트를 가져와서 암호를 해독할 수 있으므로, 세그먼트 암호는 일반 텍스트 세그먼트와 동일한 수준의 보안으로 처리됩니다. 서버 암호를 확인한다고 해서 특정 일반 텍스트를 즉시 알아낼 수 있는 것은 아니지만, 서버 암호를 사용해 암호화 텍스트에서 특정 유형의 데이터를 파생시킨 다음 부분적으로 알려진 일부 데이터를 무차별 암호 대입 공격(brute force attack)에 노출시킬 수는 있습니다. 따라서 서버 암호는 기밀로 유지해야 합니다.

Рабочие папки по сравнению с другими технологиями синхронизации

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

	рабочие папки	Автономные файлы	OneDrive для бизнеса	OneDrive
Сводная информация о технологии	Синхронизирует файлы, которые хранятся на файловом сервере, с компьютерами и устройствами	Синхронизирует файлы, которые хранятся на файловом сервере, с компьютерами с доступом к корпоративной сети (можно заменить на рабочие папки)	синхронизирует файлы, хранящиеся в Microsoft 365 или в SharePoint с компьютерами и устройствами внутри или за пределами корпоративной сети, а также предоставляет функции совместной работы с документами.	Синхронизирует личные файлы, сохраненные в OneDrive, с ПК, Mac и другими устройствами
Предназначено для предоставления пользователям доступа к рабочим файлам	Да	Да	Да	Нет
облачная служба	Нет	Нет	Microsoft 365	Microsoft OneDrive
Внутренние сетевые серверы	файловые серверы, работающие Windows Server 2012 R2, Windows Server 2016 и Windows Server 2019	Файловые серверы	Сервер SharePoint (необязательно)	Нет
Поддерживаемые клиенты	ПК, iOS, Android	ПК в корпоративной сети или ПК, подключенные через DirectAccess, VPN и другие технологии удаленного доступа	ПК, iOS, Android, Windows Phone	ПК, Mac, Windows Phone, iOS, Android

Примечание

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

Настройка BranchCache на клиентском компьютере с помощью утилиты Netsh

Я уже отвечал на вопросы «Что такое BranchCache», описывал принцип работы BranchCache в режиме хост-кэша и в режиме распределенного кэша. Так же мы рассматривали настройку клиентского компьютера для работы с технологией BranchCache. Тогда мы использовали локальные политики и правила Брандмауэра. В данной статье мы настроим клиентские компьютеры BranchCache с помощью утилиты командной строки Netsh.

Netsh для настройки BranchCache

Главное преимущество утилиты Netsh в том, что для настройки BranchCache на компьютере клиента необходимо всего лишь пару команд, в то время как предыдущий способ требовал несколько телодвижений сначала с локальными политиками, а потом с правилами Брандмауэра.

Далее я приведу список необходимых команд, которые необходимо выполнить в области netsh/branchcache. Чтобы вывалиться в эту область необходимо открыть окно командной строки и последовательно выполнить две команды:

1. netsh

2. branchcache

Ну, а далее я предоставлю Вам список команд, которые можно вводит в данной области, а так же кратко опишу что вытворяют данные команды:

• reset

  Данная команда полностью стирает любые следы работы BranchCache. Так, будут закрыты все открытые правила Брандмауэра Windows, отключены все включенные политики, будет стерт кэш и выключена служба BranchCache. Данную команду необходимо использовать тогда, когда Вы собираетесь отключить BranchCache.

  

  

  

  

  

  

  

  

  

  

• show status

  Отображает текущее состоянии технологии BranchCache. Тут представлена самая полная информация по работе данной технологии.

• set service mode=hostedclient location=server

  Данная команда настраивает клиентский компьютер для работы BranchCache в режиме хост-кэша. Тут вместо server должно быть указано полное имя сервера хост-кэша.

• set service mode=distributed

  Данная команда настраивает клиентский компьютер для работы в режиме распределенного кэша.

• set service mode=local

  Данная команда запускает технологию BranchCache на клиентском компьютере в локальном режиме. Данный режим используется очень редко. Его смысл состоит в том, что компьютер клиента может получать кэш как от хост-кэша, так и от компьютеров соседей, но при этом он не делится своим кэшом ни с первым, ни со вторым. Такой режим необходимо использовать на тех компьютерах, вопрос о производительности которых стоит на первом месте. Такой компьютер не будет терять свои силы для отдачи кэша тем, кто в нём нуждается.

• set cachesize 500000

  или

  set cachesize=7 percent=true

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

• set localcache directory=c:\cache

  Такой командой можно указать месторасположение кэша BranchCache.

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

Hosted Cache Server deployment components

You can use this guide to deploy a BranchCache hosted cache server in a branch office where computers are joined to a domain. In this deployment, the hosted cache server is deployed by using service connection points in Active Directory Domain Services (AD DS), and you have the option with BranchCache in Windows Server 2012 to prehash the shared content on Web and file based content servers, then preload the content on the hosted cache server.

The following illustration shows the components that are required to deploy a BranchCache hosted cache server.

Important

Although this deployment depicts content servers in a cloud data center, you can use this guide to deploy a BranchCache hosted cache server regardless of where you deploy your content servers – in your main office or in a cloud location.

Управление

Ранее фактически приходилось для каждого филиала создавать свой GPO для настройки BranchCache на клиентах филиала. Это особенно верно, если в филиале применялся выделенный кэш-сервер (hosted cache), поскольку именно в GPO указывалось имя этого сервера, и клиенты, таким образом, понимали, где располагается выделенный кэш.

Hosted cache сервер под управлением Windows Server 2012 может регистрировать Service Connection Point (SCP) в Active Directory. Клиенты с Windows 8 Enterprise, обращаясь к AD, используют SCP для обнаружения кэш-сервера, причем сервера ближайшего к ним, то есть расположенного в том же сайте AD. Это, в свою очередь, позволяет потенциально иметь всего один GPO для настройки всех BranchCache-клиентов организации.

Традиционно для Windows Server 2012 и Windows 8 весь спектр задач администрирования BranchCache – установка, настройка, проверка статуса – можно реализовать с помощью PowerShell, что я тоже отношу к плюсам. В Windows 7, например, для проверки статуса или сброса кэша необходимо было использовать менее дружелюбный Netsh. Возвращаясь к hosted cache, установка необходимых компонентов BranchCache, конфигурация сервера в качестве кэш-сервера и регистрация SCP осуществляется двумя командлетами:

После чего, запустив , необходимо убедиться в том, что два параметра в секции HostedCacheServerConfiguration имеют значение True.

Чтобы клиенты с Windows 8 использовали SCP для поиска кэш-сервера, в GPO необходимо включить новый параметр Enable Automatic Hosted Cache Discovery by Service Connection Point.

Замечу, что если вместе с этим параметром включен параметр Set BranchCache Distributed Cache mode, то клиент сначала пытается через SCP обнаружить и использовать hosted cache, а если это не удается, то переключается в режим distributed cache.

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

Первая строчка генерирует метаданные для файлов в указанной папке и добавляет блоки данных этих файлов в так называемый пакет данных (data package) для последующего экспорта. Аналогичный командлет для веб-сайта называется . Вторая строчка собственно экспортирует набор хэшей и блоки данных в архивный файл со стандартным именем в указанную директорию. Структура архива выглядит следующим образом:

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

Таким образом, мы получаем «разогретый» кэш.

Последнее нововведение, которое я хотел бы отметить в контексте управления, заключается в том, что кэшированные данные по умолчанию хранятся в зашифрованном виде. От администратора более не требуются никакие дополнительные телодвижения, как то: включение BitLocker, настройка EFS и пр., для обеспечения безопасности кэша. Также не требуется настройка сертификата на hosted cache сервере, что еще более разгрузит и без того занятого сисадмина. Правда сертификат все-таки понадобится, если к кэш-серверу будут обращаться клиенты с Windows 7.

Мониторинг BranchCache

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

BranchCache 프로세스: 콘텐츠 검색

클라이언트 컴퓨터는 콘텐츠 호스트(호스트된 캐시 서버 또는 분산 캐시 모드 클라이언트 컴퓨터)에서 원하는 콘텐츠를 찾으면 콘텐츠 검색 프로세스를 시작합니다.

먼저 클라이언트 컴퓨터는 필요한 첫 번째 블록에 대한 요청을 콘텐츠 호스트로 보냅니다. 이 요청에는 원하는 콘텐츠를 식별하는 세그먼트 ID와 블록 범위가 포함됩니다. 블록은 하나만 반환되므로 블록 범위에도 블록이 하나만 포함됩니다. (여러 블록에 대한 요청은 현재 지원되지 않습니다.) 또한 클라이언트는 로컬 미해결 요청 목록에 요청을 저장합니다.

클라이언트에서 유효한 요청 메시지를 받을 때 콘텐츠 호스트는 요청에 지정 된 블록이 콘텐츠 호스트의 콘텐츠 캐시에 있는지 여부를 확인 합니다.

콘텐츠 호스트는 콘텐츠 블록을 소유하고 있는 경우 세그먼트 ID, 블록 ID, 암호화된 데이터 블록 및 초기화 벡터(블록을 암호화하는 데 사용됨)가 포함된 응답을 보냅니다.

콘텐츠 호스트는 콘텐츠 블록을 소유하고 있지 않은 경우 빈 응답 메시지를 보냅니다. 그러면 콘텐츠 호스트가 요청된 블록을 소유하고 있지 않음을 클라이언트 컴퓨터에 알리게 됩니다. 빈 응답 메시지에는 요청된 블록의 세그먼트 ID와 블록 ID, 크기가 0인 데이터 블록이 포함됩니다.

클라이언트 컴퓨터는 콘텐츠 호스트에서 응답을 받으면 메시지가 해결되지 않은 요청 목록의 요청 메시지에 해당하는지 확인합니다. 세그먼트 ID 및 블록 인덱스가 해결되지 않은 요청의 세그먼트 ID 및 블록 인덱스와 일치해야 합니다.

이 확인 프로세스에 실패하는 경우 클라이언트 컴퓨터의 해결되지 않은 요청 목록에 해당하는 요청 메시지가 없으면 클라이언트 컴퓨터가 메시지를 삭제합니다.

이 확인 프로세스에 성공하는 경우 클라이언트 컴퓨터의 해결되지 않은 요청 목록에 해당하는 요청 메시지가 있으면 클라이언트 컴퓨터가 블록을 암호화합니다. 그런 다음 클라이언트는 원본 콘텐츠 서버에서 처음 가져온 콘텐츠 정보의 적절한 블록 해시에 대해 암호 해독한 블록의 유효성을 검사합니다.

블록 유효성 검사에 성공하면 암호가 해독된 블록이 캐시에 저장됩니다.

클라이언트가 필요한 모든 블록을 얻을 때까지 이 프로세스가 반복됩니다.

참고

한 컴퓨터에 콘텐츠 전체 세그먼트가 존재하지 않는 경우 검색 프로토콜은 일련의 분산 캐시 모드 클라이언트 컴퓨터, 호스트 캐시 서버, 본사의 원본 콘텐츠 서버(지점 캐시에 전체 콘텐츠가 포함되지 않은 경우) 등으로 구성된 원본 조합에서 콘텐츠를 검색하고 어셈블합니다.

BranchCache가 콘텐츠 정보 또는 콘텐츠를 보내기 전에 데이터가 암호화됩니다. BranchCache는 응답 메시지의 블록을 암호화합니다. Windows 7에서 BranchCache를 사용 하는 기본 암호화 알고리즘은 S-128 암호화 키는 Ke이 고 키 크기는 128 비트 암호화 알고리즘에 따라.

BranchCache는 암호화 알고리즘에 적합한 초기화 벡터를 생성하고 암호화 키를 사용하여 블록을 암호화합니다. 그러면 BranchCache가 암호화 알고리즘 및 초기화 벡터를 메시지에 기록합니다.

서버와 클라이언트는 암호화 키를 교환 또는 공유하거나 보내지 않습니다. 클라이언트는 원본 콘텐츠를 호스팅하는 콘텐츠 서버에서 암호화 키를 받습니다. 즉, 서버에서 받은 초기화 벡터 및 암호화 알고리즘을 사용하여 블록 암호를 해독합니다. 다운로드 프로토콜에서 기본적으로 제공되는 기타 명시적 인증 또는 권한 부여 기능은 없습니다.

보안 위협

이 계층의 주요 보안 위협은 다음과 같습니다.

• 데이터 변조:

  요청자에게 데이터를 제공하는 클라이언트가 데이터를 변조할 수 있습니다. BranchCache 보안 모델은 해시를 사용하여 클라이언트와 서버가 모두 데이터를 변경하지 않았는지 확인합니다.

• 정보 노출:

  BranchCache는 적절한 세그먼트 ID를 지정하는 모든 클라이언트에 암호화된 콘텐츠를 보냅니다. 세그먼트 ID는 공용이므로 모든 클라이언트가 암호화된 콘텐츠를 받을 수 있습니다. 그러나 악의적인 사용자가 암호화된 콘텐츠를 입수하는 경우 암호화 키를 알아야 콘텐츠 암호를 해독할 수 있습니다. 상위 계층 프로토콜에서는 인증을 수행한 다음 권한이 부여되었고 인증된 클라이언트에 콘텐츠 정보를 제공합니다. 콘텐츠 정보의 보안은 콘텐츠 자체에 대해 제공되는 보안과 동일하며, BranchCache는 콘텐츠 정보를 노출하지 않습니다.

  공격자가 콘텐츠를 얻기 위해 전송 회선을 스니핑할 수 있습니다. BranchCache는 AES128(암호 키: Ke)을 사용하여 클라이언트 간의 모든 전송을 암호화함으로써 유선상에서 데이터 스니핑을 방지합니다. 콘텐츠 서버에서 다운로드되는 콘텐츠 정보는 데이터 자체가 보호되는 것과 정확히 같은 방식으로 보호되므로, BranchCache를 사용하지 않는 경우 정보 노출로부터 보호되는 수준과 동일하게 보호됩니다.

• 서비스 거부:

  클라이언트의 데이터 요청이 비정상적으로 많은 경우에 해당합니다. BranchCache 프로토콜은 큐 관리 카운터와 타이머를 통합하여 클라이언트의 오버로드를 방지합니다.

Подготовка служб DNS и ADDS

Добавление записи isatap

Следующим шагом будет подготовка служб DNS, а также ADDS, в частности создание дополнительных групповых политик, а также группы безопасности в доменных службах.

В консоли DNS сервера необходимо добавить запись типа А со значением isatap которая указывает на IPv4 адрес Directaccess сервера.

Global query blocklist блокирует запись isatap

Однако, при проверке результатов, добавленная запись DNS сервером не найдена. Причиной этому служит присутствие ее в global query blocklist.

Вызов global query blocklist

Выполнив запрос в командной строке

можно наблюдать ее присутствие.

Изменение конфигурации в global query blocklist

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

Проверка изменений

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

Создание новой груповой политики

В консоли управления групповыми политиками создадим новую политику, например, Directaccess ICMP и откроем ее на редактирование.

Создание правил брандмауэра в груповой политике

Далее необходимо будет создать два правила в настройках брандмауэра, как показано на скриншоте.

Новое кастомное правило

Создаем новое кастомное правило.

Правило для протокола ICMPv4

Выбираем протокол ICMPv4 и вызываем дополнительные настройки.

Кастимизирование правила Echo Request

В дополнительных настройках  необходимо выбрать Echo Request.

Именование правила

Так же нужно дать название данному правилу, к примеру, Allow ICMPv4 In.

Правило для ICMPv6

Все те же действия необходимо сделать и для протокола ICMPv6 создав дополнительное правило.

Дополнительные изменения в правила

Также в настройках обоих правил необходимо внести дополнительные изменения, как показано на скриншоте.

Назначение групповой политики

В конце необходимо назначить созданную групповую политику на домен.

Создание группы безопасности в Active Directory

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

Обзор процесса развертывания сервера размещенного кэша

Примечание

Сведения о том, как выполнить эти действия, приведены в разделе развертывание в режиме кэширования BranchCache.

Процесс развертывания сервера кэша, размещенного в BranchCache, выполняется на следующих этапах:

Примечание

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

1. в HCS1 используйте команды Windows PowerShell, чтобы настроить компьютер в качестве сервера размещенного кэша и зарегистрировать точку подключения службы в Active Directory.

2. Используемых В HCS1, если значения BranchCache по умолчанию не соответствуют целям развертывания для сервера и размещенного кэша, настройте объем дискового пространства, который требуется выделить для размещенного кэша. Также настройте расположение диска, предпочитаемое для размещенного кэша.

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

   Примечание

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

   1. В WEB1 — это веб-серверное содержимое, а затем создается пакет данных.

   2. В файле FILE1, файловое содержимое файлового сервера и создать пакет данных.

   3. Из WEB1 и FILE1 Скопируйте пакеты данных на сервер размещенного кэша HCS1.

   4. В HCS1 импортируйте пакеты данных для предварительной загрузки кэша данных.

4. На компьютере DC1 настройте присоединенные к домену клиентские компьютеры филиала для режима размещенного кэша, настроив групповая политика с параметрами политики BranchCache.

5. На клиентских компьютерах обновите групповая политика.

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