рекомендации по работе с сетями Azure Files

✔️ Применяется к: все общие папки Azure

Вы можете получить доступ к общим папкам Azure через общедоступную конечную точку Интернета, через одну или несколько частных конечных точек в сети или кэширование локальной общей папки Azure с помощью Azure File Sync (только для общих папок SMB). В этой статье рассматривается, как настроить Azure Files для прямого доступа через публичные или частные конечные точки. Сведения о том, как кэшировать локальный файловый ресурс Azure с помощью Azure File Sync, см. в статье Introduction to Azure File Sync.

Перед прочтением этого руководства рекомендуется ознакомиться с Планированием развертывания Azure Files.

Для доступа к общей папке Azure напрямую часто требуется уделить дополнительное внимание сетевому взаимодействию.

• Общие SMB-файлы взаимодействуют через порт 445, который многие организации и интернет-провайдеры блокируют для исходящего интернет-трафика. Эта практика исходит из устаревших рекомендаций по безопасности по устаревшим и небезопасным версиям протокола SMB. Хотя SMB 3.x является интернет-безопасным протоколом, изменить политики организации или поставщика услуг может быть невозможно. Поэтому для монтирования общей папки SMB часто требуется дополнительная конфигурация сети для использования за пределами Azure.

• Общие папки NFS используют проверку подлинности на уровне сети и поэтому доступны только через ограниченные сети. Для использования общей папки NFS всегда требуется определенный уровень конфигурации сети.

Настройка публичных и частных конечных точек для Azure Files выполняется на верхнем уровне управления в учетной записи хранения Azure. Учетная запись хранения — это конструкция управления, представляющая общий пул хранилища, в котором можно развернуть несколько файловых хранилищ Azure, а также ресурсы для других служб хранения Azure, таких как контейнеры BLOB или очереди.

Безопасная передача

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

• SMB: параметр 'Требовать шифрование при передаче для SMB' управляет тем, требуется ли шифрование для доступа к SMB. Для новых учетных записей хранения, созданных с помощью портала Azure, этот параметр включен по умолчанию. Учетные записи хранения, созданные с помощью Azure PowerShell, Azure CLI или API FileREST, задают это значение как Not selected для обеспечения обратной совместимости. Для существующих учетных записей хранения обязательный параметр безопасной передачи продолжает управлять поведением шифрования SMB, пока не будет явно настроен параметр SMB для каждого протокола. Если требуется шифрование SMB при передаче, для всех общих папок SMB в этой учетной записи хранения требуется протокол SMB 3.x с алгоритмами шифрования AES-128-CCM, AES-128-GCM или AES-256-GCM. Вы можете переключить, какие алгоритмы разрешены с помощью параметров безопасности SMB. Отключение этого параметра позволяет подключать SMB 2.1 и SMB 3.x без шифрования.

• NFS: параметр "Требовать шифрование в транзите для NFS" определяет, требуется ли шифрование для доступа к NFS. Общие папки NFS Azure используют пакет служебной программы AZNFS для упрощения зашифрованных монтирований путем установки и настройки Stunnel (оболочки TLS с открытым кодом) на клиенте. См. раздел Шифрование данных при передаче для общих ресурсов NFS Azure. Для новых учетных записей хранения, созданных с помощью портала Azure, этот параметр включен по умолчанию. Учетные записи хранения, созданные с помощью Azure PowerShell, Azure CLI или API FileREST, задают это значение как Not selected для обеспечения обратной совместимости. Для существующих учетных записей хранения обязательный параметр безопасной передачи продолжает управлять поведением шифрования NFS, пока не будет явно настроен параметр NFS для каждого протокола.

• FileREST: обязательный параметр безопасной передачи применяется к трафику REST/HTTPS. При включении протокол FileREST может использоваться только с HTTPS.

Общедоступная конечная точка

Общедоступная конечная точка для Azure файловых хранилищ в учетной записи хранения — это конечная точка, подключенная к Интернету. Общедоступная конечная точка — это конечная точка по умолчанию для учетной записи хранения, но ее можно отключить при необходимости.

Протоколы SMB, NFS и FileREST могут использовать общедоступную конечную точку. Однако у каждого есть несколько разных правил для доступа:

• Общие папки SMB доступны из любой точки мира через общедоступную конечную точку учетной записи хранения с помощью SMB 3.x с шифрованием. Это означает, что прошедшие проверку подлинности запросы, такие как запросы, авторизованные удостоверением входа пользователя, могут безопасно выполняться изнутри или за пределами Azure региона. Если требуется SMB 2.1 или SMB 3.x без шифрования, необходимо выполнить два условия:

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

• Общие папки NFS доступны из общедоступной конечной точки учетной записи хранения, если и только если общедоступная конечная точка учетной записи хранения ограничена определенными виртуальными сетями с помощью конечных точек службы. См. параметри брандмауэра для общедоступной конечной точки в разделе параметры брандмауэра общедоступной конечной точки для получения дополнительных сведений о конечных точках службы.

• FileREST доступен через общедоступную конечную точку. Если требуется безопасная передача, принимаются только HTTPS-запросы. Если безопасная передача отключена, HTTP-запросы принимаются общедоступной конечной точкой независимо от источника.

Параметры брандмауэра общедоступной конечной точки

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

При ограничении трафика общедоступной конечной точки на одну или несколько виртуальных сетей вы используете возможность виртуальной сети, называемой конечными точками службы. Запросы, направленные на конечную точку службы Azure Files, по-прежнему направляются на публичный IP-адрес учетной записи хранения. Однако сетевой уровень производит дополнительную проверку запроса, чтобы убедиться, что он поступает из уполномоченной виртуальной сети. Протоколы SMB, NFS и FileREST поддерживают все конечные точки службы. В отличие от SMB и FileREST, доступ к общим папкам NFS возможен только через общедоступную конечную точку, используя конечную точку службы.

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

Доступ к порталу Azure и брандмауэр учетной записи хранения

При доступе к общим папкам Azure через портал Azure выполняются два отдельных запроса:

1. Запрос из браузера на пользовательский интерфейс портала Azure (https://portal.azure.com).
2. Запрос из вашего браузера непосредственно в конечную точку плоскости данных Azure Files (например, https://<storage-account-name>.file.core.windows.net), обычно используя маркер SAS, выданный для интерфейса портала.

Брандмауэр учетной записи хранения оценивает только прямой запрос к конечной точке данных Azure Files, а не запросу portal.azure.com. Таким образом, даже если вы можете получить доступ к порталу Azure без проблем, может возникнуть ошибка 403 (запрещено) при просмотре данных общей папки, если общедоступный IP-адрес исходящего трафика в запросе браузера в хранилище не разрешен брандмауэром. Это относится только к трафику FileREST/HTTPS, а не К SMB или NFS.

Маршрутизация сети общедоступной конечной точки

Azure Files поддерживает несколько вариантов маршрутизации сети. Параметр по умолчанию Microsoft маршрутизации работает со всеми конфигурациями Azure Files. Параметр маршрутизации через Интернет не поддерживает сценарии присоединения к домену AD или Azure File Sync.

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

Помимо общедоступной конечной точки по умолчанию для учетной записи хранения, Azure Files предоставляет возможность иметь одну или несколько частных конечных точек. Частная конечная точка — это конечная точка, доступная только в Azure виртуальной сети. При создании частной конечной точки для учетной записи хранения ваша учетная запись хранения получает частный IP-адрес из адресного пространства виртуальной сети, так же как локальный файловый сервер или устройство NAS получает IP-адрес в выделенном адресном пространстве локальной сети.

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

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

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

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

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

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

Azure Files поддерживает следующие механизмы туннелирования трафика между локальными рабочими станциями и серверами и файловыми ресурсами Azure SMB/NFS:

• Azure VPN Gateway: VPN-шлюз — это конкретный тип шлюза виртуальной сети, который используется для отправки зашифрованного трафика между виртуальной сетью Azure и альтернативным расположением (например, локальной) через Интернет. Azure VPN Gateway — это Azure ресурс, который можно развернуть в группе ресурсов вместе с учетной записью хранения или другими Azure ресурсами. VPN-шлюзы предоставляют два различных типа подключений:
  • Point-to-Site (P2S) VPN соединения через шлюз, которые представляют собой VPN-подключения между Azure и отдельным клиентом. Это решение в первую очередь полезно для устройств, которые не являются частью локальной сети организации. Распространенный вариант использования заключается в том, что удаленные сотрудники хотят иметь возможность подключать свой общий ресурс Azure из дома, кафе или отеля во время путешествия. Чтобы использовать VPN-подключение P2S с Azure Files, необходимо настроить VPN-подключение P2S для каждого клиента, который хочет подключиться. См. Настройка VPN типа "точка — сеть" (P2S) на Windows для использования с Azure Files и Настройка VPN типа "точка — сеть" (P2S) на Linux для использования с Azure Files.
  • VPN Site-to-Site (S2S) — это VPN-подключения между Azure и сетью вашей организации. VPN-подключение S2S позволяет настроить VPN-подключение один раз для VPN-сервера или устройства, размещенного в сети вашей организации, а не настраивать подключение для каждого клиентского устройства, которое должно получить доступ к Azure общей папке. См. раздел Configure VPN типа "сеть — сеть" (S2S) для использования с Azure Files.
• ExpressRoute, что позволяет создавать определенный маршрут между Azure и локальной сетью, которая не проходит через Интернет. Так как ExpressRoute предоставляет выделенный путь между локальным центром обработки данных и Azure, ExpressRoute может оказаться полезным при рассмотрении производительности сети. ExpressRoute также является хорошим вариантом, если политика или нормативные требования вашей организации предполагают детерминированный путь к ресурсам в облаке.

DNS configuration (Настройка DNS)

При создании частной конечной точки по умолчанию мы также создадим частную зону DNS (или обновим существующую) частную зону DNS, соответствующую поддомену privatelink . Строго говоря, создание частной зоны DNS не требуется для использования частной конечной точки для учетной записи хранения. Тем не менее рекомендуется в целом, и это обязательно при подключении файлового хранилища Azure с помощью учетной записи пользователя Active Directory или доступа к нему из API FileREST.

В частной зоне DNS мы создадим запись A и запись storageaccount.privatelink.file.core.windows.net CNAME для регулярного имени учетной записи хранения, которая соответствует шаблону storageaccount.file.core.windows.net. Поскольку ваша частная зона 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

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

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

SMB через QUIC

Windows Server 2022 Azure Edition поддерживает новый транспортный протокол с именем QUIC для сервера SMB, предоставленного ролью файлового сервера. QUIC — это замена TCP, построенного на основе UDP, что обеспечивает многочисленные преимущества по протоколу TCP, обеспечивая надежный механизм транспорта. Одним из ключевых преимуществ протокола SMB является то, что вместо использования порта 445 весь транспорт выполняется через порт 443, который широко открыт для поддержки HTTPS. Это означает, что SMB через QUIC предлагает "VPN SMB" для общего доступа к файлам через общедоступный Интернет. Windows 11 поставляется с клиентом SMB с поддержкой QUIC.

В настоящее время Azure Files не поддерживает SMB через QUIC. Однако вы можете получить доступ к общим папкам Azure с помощью Azure File Sync, запущенных на Windows Server, как показано на схеме ниже. Это также предоставляет вам возможность использовать Azure File Sync для кэширования как на локальных серверах, так и в разных центрах обработки данных Azure, чтобы обеспечить локальные кэши для распределенной рабочей силы. Дополнительные сведения об этом параметре см. в разделе Deploy Azure File Sync и SMB по QUIC.

См. также

• Обзор Azure Files
• Планнинг для развертывания Azure Files