Рекомендации по настройке сети для службы "Синхронизация файлов Azure"

Статья
06/01/2023

Подключиться к общей папке Azure можно двумя способами:

Осуществление доступа к общей папке напрямую по протоколу SMB или FileREST. Этот шаблон доступа в основном используется, чтобы исключить максимально возможное количество локальных серверов.
Создание кэша общей папки Azure на локальном сервере (или в виртуальной машине Azure) со службой "Синхронизация файлов Azure" и осуществление доступа к данным общей папки с локального сервера по выбранному вами протоколу (SMB, NFS, FTPS и т. д.) для вашего варианта использования. Этот шаблон доступа удобен, так как представляет собой лучшее сочетание производительности, характерной для локальных сред, масштабируемости облачных служб и бессерверных присоединяемых служб, например Azure Backup.

В этой статье рассказывается, как настроить сеть в сценариях, когда используется Синхронизация файлов Azure для локального кэширования файлов вместо прямого подключения общей папки Azure через SMB. Дополнительные сведения о настройке сети для развертывания службы "Файлы Azure" см. в статье Рекомендации по настройке сети для службы "Файлы Azure".

Конфигурация сети для службы "Синхронизация файлов Azure" охватывает два разных объекта Azure: службу синхронизации хранилища и учетную запись хранения Azure. Учетная запись хранения — это конструкция управления, представляющая собой общий пул носителей, который можно использовать для развертывания нескольких общих папок и других ресурсов хранения, например контейнеров больших двоичных объектов или очередей. Служба синхронизации хранилища — это управляющая конструкция, представляющая зарегистрированные серверы, которые являются файловыми серверами Windows с установленными отношениями доверия с Синхронизацией файлов Azure и группами синхронизации, определяющими топологию отношения синхронизации.

Важно!

Синхронизация файлов Azure не поддерживает маршрутизацию через Интернет. Параметр сетевой маршрутизации по умолчанию (маршрутизация Майкрософт) поддерживается службой "Синхронизация файлов Azure".

Подключение файлового сервера Windows к Azure с помощью Синхронизации файлов Azure

Для настройки и использования служб "Файлы Azure" и "Синхронизация файлов Azure" с локальным файловым сервером Windows не требуются никакие специальные сетевые подключения к Azure, достаточно обычного подключения к Интернету. Чтобы развернуть Синхронизацию файлов Azure, установите агент Синхронизации файлов Azure на файловом сервере Windows, который вы хотите синхронизировать с Azure. Агент Синхронизации файлов Azure обеспечивает синхронизацию с общей папкой Azure, используя следующие два канала.

Протокол FileREST, представляющий собой протокол на основе HTTPS для доступа к общей папке Azure. Так как протокол FileREST использует для передачи данных стандартный протокол HTTPS, для исходящего трафика должен быть доступен только порт 443. Синхронизация файлов Azure не использует протокол SMB для передачи данных с локальных серверов Windows в общую папку Azure и обратно.
Протокол синхронизации службы "Синхронизация файлов Azure", представляющий собой протокол на основе HTTPS для обмена данными синхронизации, такими как версии файлов и папок, между конечными точками. Этот протокол также используется для обмена метаданными файлов и папок в вашей среде, такими как метки времени и списки управления доступом (ACL).

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

Хотя для службы "Синхронизация файлов Azure" не требуется какая-либо специальная настройки сети, некоторые клиенты могут захотеть настроить дополнительные параметры сети, чтобы включить следующие сценарии.

Взаимодействие с конфигурацией прокси-сервера организации.
Открытие локального брандмауэра вашей организации для служб "Файлы Azure" и "Синхронизация файлов Azure".
Туннелирование трафика служб "Файлы Azure" и "Синхронизация файлов Azure" через подключение ExpressRoute или VPN.

настройка прокси-серверов;

Многие организации используют прокси-сервер в качестве посредника между ресурсами в своей локальной сети и ресурсами вне своей сети, например в Azure. Прокси-серверы полезны во многих случаях, например для изоляции и обеспечения и безопасности сети, а также для мониторинга и ведения журнала. Синхронизация файлов Azure может полностью взаимодействовать с прокси-сервером, однако вы должны вручную настроить параметры конечной точки прокси-сервера для своей среды в Синхронизации файлов Azure. Это делается в PowerShell с помощью командлета Set-StorageSyncProxyConfiguration сервера синхронизации файлов Azure.

Дополнительные сведения о настройке использования Синхронизации файлов Azure с прокси-сервером см. в разделе Настройка использования Синхронизации файлов Azure с прокси-сервером.

Настройка брандмауэров и тегов служб

В целях безопасности многие организации изолируют свои файловые серверы от большинства расположений в Интернете. Для использования Синхронизации файлов Azure в такой среде вам нужно настроить брандмауэр, чтобы разрешить исходящий доступ к службам Azure. Это можно сделать, разрешив исходящий доступ через порт 443 к необходимым облачным конечным точкам, на которых размещены эти службы Azure, если брандмауэр поддерживает URL-адреса или домены. В противном случае можно получить диапазоны IP-адресов для этих служб Azure с помощью тегов служб.

Синхронизации файлов Azure требуются диапазоны IP-адресов для следующих служб, определяемых их тегами.

Служба	Description	Тег службы
Служба синхронизации файлов Azure	Служба "Синхронизация файлов Azure", представленная объектом "Служба синхронизации хранилища", отвечает за базовые операции синхронизации данных между общей папкой Azure и файловым сервером Windows.	`StorageSyncService`
Файлы Azure	Все данные, синхронизированные с помощью Синхронизации файлов Azure, хранятся в общей папке Azure. Файлы, измененные на файловых серверах Windows, реплицируются в общую папку Azure, и многоуровневые файлы на локальном файловом сервере легко загружаются при запросе пользователя.	`Storage`
Azure Resource Manager	Azure Resource Manager представляет собой интерфейс управления для Azure. Все вызовы управления, в том числе регистрация сервера Синхронизации файлов Azure и текущие задачи сервера синхронизации, выполняются через Azure Resource Manager.	`AzureResourceManager`
ИД Microsoft Entra	Идентификатор Microsoft Entra (ранее Azure AD) содержит субъекты-пользователи, необходимые для авторизации регистрации сервера в службе синхронизации служба хранилища, и субъекты-службы, необходимые для Синхронизация файлов Azure для доступа к облачным ресурсам.	`AzureActiveDirectory`

Если вы используете Синхронизацию файлов Azure в Azure, даже если это другой регион, для разрешения трафика в эту службу можно использовать имя тега службы непосредственно в вашей группе безопасности сети. Дополнительные сведения см. в разделе Группы безопасности сети.

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

Текущий список диапазонов IP-адресов для всех служб Azure, поддерживающих теги служб, публикуется еженедельно в Центре загрузки Майкрософт в виде документа JSON. В каждом облаке Azure есть собственный документ JSON с диапазонами IP-адресов, соответствующими этому облаку:
API обнаружения тегов служб (предварительная версия) позволяет получать текущий список тегов служб программными средствами. В предварительной версии API обнаружения тегов служб может возвращать менее актуальную информацию по сравнению с документами JSON, публикуемыми в Центре загрузки Майкрософт. Вы можете использовать область API на основе предпочтений службы автоматизации:

Дополнительные сведения об использовании API тегов служб для получения адресов служб см. в разделе Список разрешений для IP-адресов Синхронизации файлов Azure.

Туннелирование трафика через виртуальную частную сеть или ExpressRoute

Некоторым организациям требуется взаимодействие с Azure через сетевой туннель, такой как виртуальная частная сеть (VPN) или ExpressRoute, в целях дополнительной защиты или для обеспечения взаимодействия с Azure по детерминированному маршруту.

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

Службы "Файлы Azure" и "Синхронизация файлов Azure" поддерживают следующие механизмы для туннелирования трафика между локальными серверами и Azure:

VPN-шлюз Azure — это особый тип шлюза виртуальной сети, используемый для отправки зашифрованного трафика между виртуальной сетью Azure и альтернативным расположением (например, в локальной среде) через Интернет. VPN-шлюз Azure — это ресурс Azure, который можно развернуть в группе ресурсов вместе с учетной записью хранения или другими ресурсами Azure. Так как Синхронизация файлов Azure предназначена для использования с локальным файловым сервером Windows, обычно используется VPN типа "сеть-сеть" (S2S), хотя технически возможно использовать VPN типа "точка-сеть" (P2S).

VPN-подключения типа "сеть-сеть" (S2S) соединяют виртуальную сеть Azure и локальную сеть вашей организации. VPN-подключение S2S позволяет настроить VPN-подключение один раз для VPN-сервера или устройства, размещенного в сети организации, а не настраивать каждое клиентское устройство, которому требуется доступ к общей папке Azure. Чтобы упростить развертывание подключения S2S VPN, воспользуйтесь статьей Настройка VPN-подключения "сеть — сеть" для использования с Файлами Azure.
ExpressRoute, который позволяет создать определенный маршрут (частное подключение) между Azure и локальной сетью, которая не проходит через Интернет. Так как ExpressRoute предоставляет выделенный путь между локальным центром обработки данных и Azure, ExpressRoute может быть полезен там, где производительность сети имеет ключевое значение. ExpressRoute также является хорошим вариантом, если политика или нормативные требования вашей организации предполагают детерминированный путь к ресурсам в облаке.

Частные конечные точки

Наряду с общедоступными конечными точками по умолчанию, которые Файлы Azure и Синхронизация файлов Azure предоставляют через учетную запись хранения и службу синхронизации хранилища, вы также можете использовать одну или несколько частных конечных точек на ресурс для частного и безопасного подключения к общим папкам Azure из локальной среды с использованием VPN или ExpressRoute и из виртуальной сети Azure. Когда вы создаете частную конечную точку для ресурса Azure, она получает частный IP-адрес из адресного пространства вашей виртуальной сети, аналогично тому, как локальный файловый сервер Windows получает IP-адрес из адресного пространства, выделенного для вашей локальной сети.

Важно!

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

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

Использование частных конечных точек предоставляет следующие возможности.

Безопасное подключение к ресурсам Azure из локальных сетей через подключение VPN или ExpressRoute с частным пирингом.
Защитите свои ресурсы Azure путем отключения общедоступных конечных точек для служб "Файлы Azure" и "Синхронизация файлов Azure". По умолчанию при создании частной конечной точки подключение к общедоступной конечной точке не блокируется.
Повышение уровня безопасности виртуальной сети благодаря предотвращению утечки данных через границы виртуальной сети (и пиринга).

Сведения о создании частной конечной точки см. в разделе Настройка частных конечных точек для службы "Синхронизация файлов Azure".

Частные конечные точки и DNS

При создании частной конечной точки по умолчанию также создается (или обновляется, если она уже существует) частная зона DNS, соответствующая поддомену privatelink. Для регионов общедоступного облака это зоны DNS privatelink.file.core.windows.net для Файлов Azure и privatelink.afs.azure.net для Синхронизации файлов Azure.

Примечание.

В этой статье используется DNS-суффикс учетной записи хранения core.windows.net, выделенный для общедоступных регионов Azure. Этот комментарий также относится к облакам Azure Sovereign, таким как облако Azure для государственных организаций США и Microsoft Azure, управляемый облаком 21Vianet, просто замените соответствующие суффиксы для вашей среды.

При создании частных конечных точек для учетной записи хранения и службы синхронизации хранилища мы создаем для них записи A в соответствующих частных зонах DNS. Мы также обновляем общедоступную запись DNS, так что обычные полные доменные имена являются именами CNAME для соответствующего имени privatelink. Благодаря этому полные доменные имена могут указывать на IP-адреса частных конечных точек, если инициатор запроса находится в виртуальной сети, и на IP-адреса общедоступных конечных точек, если инициатор запроса находится за пределами виртуальной сети.

В Файлах Azure каждая частная конечная точка имеет одно полное доменное имя, соответствующее шаблону storageaccount.privatelink.file.core.windows.net, сопоставленное с одним частным IP-адресом для частной конечной точки. В Синхронизации файлов Azure каждая частная конечная точка имеет четыре полных доменных имени для четырех различных конечных точек, которые предоставляет Синхронизация файлов Azure: управления, синхронизации (первичной), синхронизации (дополнительной) и мониторинга. Полные доменные имена для этих конечных точек будут соответствовать имени службы синхронизации хранилища, если только это имя не содержит символы, не входящие в набор ASCII. Например, если служба синхронизации в регионе "Западная часть США 2" хранилища имеет имя mysyncservice, то эквивалентные конечные точки будут иметь полные доменные имена mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net и mysyncservicemonitoring.westus2.afs.azure.net. Каждая частная конечная точка для службы синхронизации хранилища будет содержать 4 различных IP-адреса.

Так как частная зона DNS Azure подключается к виртуальной сети, которая содержит частную конечную точку, при вызове командлета Resolve-DnsName из PowerShell на виртуальной машине Azure (или nslookup в Windows и Linux) вы получите следующую конфигурацию DNS:

Resolve-DnsName -Name "storageaccount.file.core.windows.net"

В нашем примере учетная запись хранения storageaccount.file.core.windows.net разрешается в частный IP-адрес частной конечной точки, то есть 192.168.0.4.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     csostoracct.privatelink.file.core.windows.net
net

Name       : storageaccount.privatelink.file.core.windows.net
QueryType  : A
TTL        : 1769
Section    : Answer
IP4Address : 192.168.0.4


Name                   : privatelink.file.core.windows.net
QueryType              : SOA
TTL                    : 269
Section                : Authority
NameAdministrator      : azureprivatedns-host.microsoft.com
SerialNumber           : 1
TimeToZoneRefresh      : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration       : 2419200
DefaultTTL             : 300

Если вы выполните такую же команду в локальной среде, это же имя учетной записи хранения будет разрешаться в общедоступный IP-адрес этой учетной записи хранения. storageaccount.file.core.windows.net имеет запись CNAME storageaccount.privatelink.file.core.windows.net, которое, в свою очередь, сопоставляется с кластером хранения Azure, где размещена учетная запись хранения.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  60    Answer     storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME  60    Answer     file.par20prdstr01a.store.core.windows.net
ore.windows.net

Name       : file.par20prdstr01a.store.core.windows.net
QueryType  : A
TTL        : 60
Section    : Answer
IP4Address : 52.239.194.40

Это отражает тот факт, что службы "Файлы Azure" и "Синхронизация файлов Azure" могут предоставлять как свои общедоступные конечные точки, так и одну или несколько частных конечных точек на ресурс. Чтобы полные доменные имена для ваших ресурсов разрешались в частные IP-адреса частных конечных точек, вы должны изменить конфигурацию на ваших локальных DNS-серверах. Это можно сделать несколькими способами.

Изменить файл hosts на клиентах, чтобы полные доменные имена учетных записей хранения и служб синхронизации хранилища разрешались в нужные частные IP-адреса. В рабочих средах этот способ настоятельно не рекомендуется, так как придется внести эти изменения для каждого клиента, которому требуется доступ к частным конечным точкам. Изменения в частных конечных точках и ресурсах (удаления, модификации и т. п.) не будут обрабатываться автоматически.
Создать зоны DNS на локальных серверах для privatelink.file.core.windows.net и privatelink.afs.azure.net с записями A для ваших ресурсов Azure. Этот вариант более предпочтителен тем, что клиенты в локальной среде смогут автоматически разрешать адреса ресурсов Azure без индивидуальной настройки каждого клиента. Но это решение так же ненадежно, как изменение файла hosts, так как изменения не распространяются автоматически. Но для некоторых сред такое решение будет оптимальным.
Переадресовать зоны core.windows.net и afs.azure.net с локальных DNS-серверов в частные зоны DNS Azure. Частный DNS-узел Azure доступен по специальному IP-адресу 168.63.129.16, который имеет видимость только внутри виртуальных сетей, связанных с частной зоной DNS Azure. Чтобы обойти это ограничение, можно создать в виртуальной сети дополнительные DNS-серверы для переадресации core.windows.net и afs.azure.net в соответствующие частные зоны DNS Azure. Чтобы упростить создание этой архитектуры, мы подготовили командлеты PowerShell для автоматического развертывания DNS-серверов в виртуальной сети Azure и их настройки в соответствии с вашими потребностями. Сведения о настройке перенаправления DNS для службы "Файлы Azure" см. в этой статье.

Шифрование при передаче

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

Дополнительные сведения о шифровании при передаче см. в статье Require secure transfer in Azure Storage (Требование безопасной передачи в службе хранилища Azure).