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

Статья
06/13/2024

Подключиться к общей папке 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 Server и общей папкой 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 ID	Идентификатор 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".

Частные конечные точки и 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. Каждая частная конечная точка для службы синхронизации хранилища будет содержать четыре отдельных IP-адреса.

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

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 без необходимости настраивать каждый клиент. Однако это решение аналогично сбоем в изменении файла узлов, так как изменения не отражаются. Хотя это решение является хрупким, это может быть лучшим выбором для некоторых сред.
Переадресовать зоны 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).

Поделиться через