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

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

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

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

Конфигурация сети для синхронизации файлов Azure охватывает два разных объекта Azure: службу синхронизации хранилища и учетную запись хранения Azure. Учетная запись хранения — это управляемый объект, означающий общий пул хранилища, в котором можно развернуть несколько файловых ресурсов, а также другие ресурсы хранилища, такие как блобы или очереди. Служба синхронизации хранилища — это конструкция управления, представляющая зарегистрированные серверы, которые являются файловыми серверами Windows с установленным отношением доверия с синхронизацией файлов 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 Files и Azure File Sync.
• Передача трафика служб Azure Files и Azure File Sync через соединение ExpressRoute или виртуальную частную сеть (VPN).

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

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

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

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

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

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

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

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

• Текущий список диапазонов IP-адресов для всех служб Azure, поддерживающих теги служб, публикуется еженедельно в Центре загрузки Майкрософт в виде документа JSON. В каждом облаке Azure есть собственный документ JSON с диапазонами IP-адресов, соответствующими этому облаку:
  • Общедоступная служба Azure
  • Azure для государственных организаций США
  • Microsoft Azure, управляемый 21Vianet
  • Azure Германия
• API обнаружения тегов службы (предварительная версия) позволяет программно получить текущий список тегов служб. В предварительной версии API обнаружения тегов службы может возвращать информацию, которая меньше текущей, чем информация, возвращаемая документами JSON, опубликованными в Центре загрузки Майкрософт. Вы можете использовать поверхность API в зависимости от ваших предпочтений автоматизации.
  • REST API
  • Azure PowerShell
  • Azure CLI

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

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

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

При установке сетевого туннеля между локальной сетью и Azure вы пирингуете локальную сеть с одной или несколькими виртуальными сетями в Azure. Виртуальная сеть, или VNET похожа на традиционную сеть, которую вы бы использовали в локальной среде. Как и учетная запись хранения 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. Чтобы упростить развертывание VPN-подключения S2S, см. статью "Настройка VPN типа "сеть — сеть" (S2S) для использования с файлами Azure.

• ExpressRoute, который позволяет создать определенный маршрут (частное подключение) между Azure и локальной сетью, которая не проходит через Интернет. Так как ExpressRoute предоставляет выделенный путь между локальным центром обработки данных и Azure, ExpressRoute может оказаться полезным, если производительность сети является ключевым фактором. ExpressRoute также является хорошим вариантом, если политика или нормативные требования вашей организации предполагают детерминированный путь к ресурсам в облаке.

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

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

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

Использование частных конечных точек позволяет:

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

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

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

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

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

Для файлов Azure каждая частная конечная точка имеет одно полное доменное имя, которое соответствует шаблону storageaccount.privatelink.file.core.windows.net, и сопоставляется с одним частным IP-адресом. Для синхронизации файлов Azure каждая частная конечная точка имеет четыре полных доменных имен для четырех разных конечных точек, предоставляемых Службой синхронизации файлов Azure: управление, синхронизация (основной), синхронизация (вторичная) и мониторинг. Полные доменные имена для этих конечных точек обычно следуют имени службы синхронизации хранилища, если имя не содержит символы, отличные от ASCII. Например, если имя службы синхронизации хранилища находится mysyncservice в регионе "Западная часть США 2", то эквивалентные конечные точки будут mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.netи mysyncservicesyncs.westus2.afs.azure.netmysyncservicemonitoring.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, которая, в свою очередь, является CNAME-записью для кластера хранилища 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, смотрите Настройка DNS с помощью Azure Files.

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

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

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

См. также

• Планирование развертывания службы синхронизации файлов Azure
• Развертывание службы синхронизации файлов Azure