Considerações de rede para o Azure File Sync

Este artigo aborda considerações de rede para o Azure File Sync, que armazena em cache partilhas de ficheiros Azure em servidores de ficheiros Windows locais. Para considerações de rede para uma implementação direta do Ficheiros do Azure, veja considerações de rede do Ficheiros do Azure.

A rede para Azure File Sync envolve dois objetos Azure: um Serviço de Sincronização de Armazenamento (que gere servidores registados e grupos de sincronização) e uma conta de armazenamento Azure (que aloja as partilhas de ficheiros). Na maioria dos casos, não precisa de uma configuração especial de rede para além de uma ligação básica à internet, mas pode configurar servidores proxy, firewalls, VPN ou tunelamento ExpressRoute, endpoints privados e SMB via QUIC.

Importante

O Azure File Sync não suporta o encaminhamento da Internet. A opção de encaminhamento de rede predefinida, o encaminhamento da Microsoft, é suportada pelo Azure File Sync.

Conectando o servidor de arquivos do Windows ao Azure com o Azure File Sync

Para configurar e usar o Ficheiros do Azure e o Azure File Sync com um servidor de ficheiros Windows local, não precisa de rede especial para o Azure além de uma ligação básica à internet. Para implementar o Azure File Sync, instale o agente Azure File Sync no servidor de ficheiros Windows que pretende sincronizar com o Azure. O agente Azure File Sync consegue sincronização com uma partilha de ficheiros Azure através de dois canais:

  • O protocolo FileREST, que é um protocolo baseado em HTTPS usado para acessar seu compartilhamento de arquivos do Azure. Como o protocolo FileREST usa HTTPS padrão para transferência de dados, a porta 443 deve ser de saída acessível. O Azure File Sync não usa o protocolo SMB para transferir dados entre seus Servidores Windows locais e seu compartilhamento de arquivos do Azure.
  • O protocolo de sincronização do Azure File Sync, que é um protocolo baseado em HTTPS utilizado para trocar informações de sincronização, nomeadamente as informações de versão relativas aos ficheiros e pastas entre extremidades no seu ambiente. Esse protocolo também é usado para trocar metadados sobre os arquivos e pastas, como carimbos de data/hora e listas de controle de acesso (ACLs).

Montar diretamente a partilha de ficheiros do Azure através de SMB para o agente do Azure File Sync não é necessário e é desaconselhado, porque as alterações efetuadas diretamente na partilha de ficheiros podem não ser detetadas durante até 24 horas. Para usar a partilha de ficheiros diretamente sem o Azure File Sync, consulte a visão geral de rede do Ficheiros do Azure.

Embora o Azure File Sync não exija nenhuma configuração de rede especial, alguns clientes podem querer definir configurações avançadas de rede para habilitar os seguintes cenários:

  • Interopere com a configuração do servidor proxy da sua organização.
  • Abra o firewall local da sua organização nos Serviços Ficheiros do Azure e Azure File Sync.
  • Encaminhe o tráfego do Ficheiros do Azure e do Azure File Sync através de uma ligação ExpressRoute ou de uma ligação de rede privada virtual (VPN).

Configurando servidores proxy

O Azure File Sync pode interoperar totalmente com um servidor proxy, mas deve configurar manualmente as definições do endpoint proxy para o seu ambiente com o Azure File Sync. Use o PowerShell e o cmdlet Set-StorageSyncProxyConfigurationdo servidor Azure File Sync.

Para obter mais informações sobre como configurar o Azure File Sync com um servidor proxy, consulte Configurando o Azure File Sync com um servidor proxy.

Configurando firewalls e tags de serviço

Por razões de segurança, muitas organizações isolam os seus servidores de ficheiros da maioria dos locais na internet. Para usar o Azure File Sync em tal ambiente, você precisa configurar seu firewall para permitir o acesso de saída para selecionar serviços do Azure. Se o seu firewall suportar filtragem de URL ou domínio, permita o acesso de saída da porta 443 aos endpoints cloud necessários que alojam esses serviços específicos do Azure. Se isso não acontecer, você poderá recuperar os intervalos de endereços IP desses serviços do Azure por meio de marcas de serviço.

A Sincronização de Ficheiros do Azure requer os intervalos de endereços IP para os seguintes serviços, conforme identificados pelas respetivas etiquetas de serviço:

Serviço Descrição Etiqueta de serviço
Azure File Sync O serviço Azure File Sync, conforme representado pelo objeto Storage Sync Service, é responsável pela atividade principal de sincronização de dados entre um compartilhamento de arquivos do Azure e um servidor de arquivos do Windows. StorageSyncService
Ficheiros do Azure Todos os dados sincronizados através do Azure File Sync são armazenados numa partilha de ficheiros do Azure. Os arquivos alterados em seus servidores de arquivos do Windows são replicados para seu compartilhamento de arquivos do Azure e os arquivos hierarquizados em seu servidor de arquivos local são baixados diretamente quando um usuário os solicita. Storage
Azure Resource Manager O Azure Resource Manager é a interface de gerenciamento do Azure. Todas as chamadas de gerenciamento, incluindo o registro do servidor do Azure File Sync e as tarefas contínuas do servidor de sincronização, são feitas por meio do Gerenciador de Recursos do Azure. AzureResourceManager
Microsoft Entra ID O Microsoft Entra ID (anteriormente Azure AD) contém as identidades de utilizador necessárias para autorizar o registo do servidor num Storage Sync Service e as identidades de serviço necessárias para que o Azure File Sync seja autorizado a aceder aos seus recursos na cloud. AzureActiveDirectory

Se estiver a utilizar a Sincronização de Ficheiros do Azure no Azure, mesmo que esteja numa região diferente, pode utilizar o nome da etiqueta de serviço diretamente no seu grupo de segurança de rede para permitir o tráfego para esse serviço. Para obter mais informações, veja Grupos de segurança de rede.

Se estiver a utilizar o Azure File Sync no local, pode utilizar a API da etiqueta de serviço para obter intervalos de endereços IP específicos para a lista de permissões da firewall. Existem dois métodos para obter estas informações:

  • A lista atual de intervalos de endereços IP para todos os serviços do Azure que suportam etiquetas de serviço é publicada semanalmente no Centro de Transferências da Microsoft, sob a forma de um documento JSON. Cada nuvem do Azure tem seu próprio documento JSON com os intervalos de endereços IP relevantes para essa nuvem:
  • A API de deteção de etiquetas de serviço (pré-visualização) permite a obtenção programática da lista atual de etiquetas de serviço. Em versão preliminar, a API de deteção de etiquetas de serviço pode devolver informações menos atualizadas do que a informação devolvida pelos documentos JSON publicados no Centro de Transferências da Microsoft. Você pode usar a superfície da API com base em sua preferência de automação:

Para saber mais sobre como utilizar a API da etiqueta de serviço para obter os endereços dos seus serviços, consulte Lista de permissões para endereços IP do Azure File Sync.

Tunelização de tráfego através de uma rede virtual privada ou ExpressRoute

Algumas organizações exigem comunicação com o Azure para passar por um túnel de rede, como uma VPN ou Rota Expressa, para obter uma camada adicional de segurança ou para garantir que a comunicação com o Azure siga uma rota determinística.

Os Arquivos do Azure e a Sincronização de Arquivos do Azure dão suporte aos seguintes mecanismos para encapsular o tráfego entre seus servidores locais e o Azure:

  • Gateway de VPN do Azure: Um gateway VPN é um tipo específico de gateway de rede virtual que utiliza para enviar tráfego encriptado entre uma rede virtual Azure e um local alternativo (como on-premises) através da internet. Um Gateway de VPN do Azure é um recurso Azure que implementa num grupo de recursos juntamente com uma conta de armazenamento ou outros recursos Azure. Como o Azure File Sync foi pensado para ser usado com um servidor de ficheiros Windows local, normalmente utiliza-se uma VPN site-to-site, embora tecnicamente seja possível usar uma VPN point-to-site.

    As ligações VPN site-to-site ligam a sua rede virtual Azure à rede local da sua organização. Uma ligação VPN site-to-site permite-lhe configurar uma ligação VPN uma vez, para um servidor ou dispositivo VPN alojado na rede da sua organização, em vez de o fazer para cada dispositivo cliente que precisa de aceder à sua partilha de ficheiros Azure. Para simplificar a implementação de uma ligação VPN site a site, consulte Configurar uma VPN site a site para utilização com o Ficheiros do Azure.

  • ExpressRoute, que permite criar uma rota definida (conexão privada) entre o Azure e sua rede local que não atravessa a Internet. Como a Rota Expressa fornece um caminho dedicado entre seu datacenter local e o Azure, a Rota Expressa pode ser útil quando o desempenho da rede é uma consideração fundamental. O ExpressRoute também é uma boa opção quando os requisitos regulatórios ou de política da sua organização exigem um caminho determinístico para seus recursos na nuvem.

SMB sobre QUIC

Se a porta 445 estiver bloqueada no seu ambiente, pode usar SMB sobre QUIC como alternativa a VPN ou ExpressRoute. O SMB sobre QUIC utiliza o protocolo de transporte QUIC através da porta 443, que a maioria das organizações e dos fornecedores de serviços de Internet (ISPs) têm aberta para permitir tráfego HTTPS. Esta funcionalidade elimina grande parte da configuração de rede normalmente necessária para aceder remotamente a uma partilha de ficheiros através da internet pública.

Para usar SMB sobre QUIC com Azure File Sync:

  • O endpoint do servidor Azure File Sync deve correr numa máquina virtual Windows Server Datacenter: Azure Edition no Azure.
  • Os clientes devem estar a correr Windows 11 ou versão posterior.

Para obter detalhes sobre a instalação e a configuração, consulte SMB over QUIC.

Endpoints privados para Ficheiros do Azure e Azure File Sync

Além dos pontos de extremidade públicos padrão que os Arquivos do Azure e a Sincronização de Arquivos do Azure fornecem por meio da conta de armazenamento e do Serviço de Sincronização de Armazenamento, eles fornecem a opção de ter um ou mais pontos de extremidade privados por recurso. Esta opção permite-lhe conectar-se de forma privada e segura a partilhas de ficheiros Azure a partir do local usando VPN ou ExpressRoute e dentro de uma rede virtual Azure. Quando você cria um ponto de extremidade privado para um recurso do Azure, ele obtém um endereço IP privado de dentro do espaço de endereço de sua rede virtual, de forma muito semelhante a como seu servidor de arquivos do Windows local tem um endereço IP dentro do espaço de endereço dedicado de sua rede local.

Um ponto de extremidade privado individual está associado a uma sub-rede de rede virtual específica do Azure. As contas de armazenamento e os Serviços de Sincronização de Armazenamento podem ter pontos finais privados em mais do que uma rede virtual.

A utilização de pontos finais privados permite-lhe:

  • Conecte-se com segurança aos seus recursos do Azure a partir de redes locais usando uma conexão VPN ou ExpressRoute com emparelhamento privado.
  • Proteja seus recursos do Azure desabilitando os pontos de extremidade públicos para Arquivos do Azure e Sincronização de Arquivos. Por padrão, a criação de um ponto de extremidade privado não bloqueia conexões com o ponto de extremidade público.
  • Aumente a segurança da rede virtual ao permitir-lhe bloquear a exfiltração de dados da rede virtual (e dos limites de peering).

Para criar um endpoint privado, consulte Configurar endpoints privados para Azure File Sync.

Pontos finais privados e DNS

Quando cria um endpoint privado, o Azure também cria ou atualiza uma zona DNS privada que corresponde ao privatelink subdomínio. Para regiões de nuvem pública, essas zonas DNS são privatelink.file.core.windows.net para Arquivos do Azure e privatelink.afs.azure.net para a Sincronização de Arquivos do Azure.

Nota

Este artigo usa o sufixo DNS da conta de armazenamento para as regiões Públicas do Azure, core.windows.net. Isso também se aplica às nuvens Sovereign do Azure, como a nuvem Azure US Government e o Microsoft Azure operado pela nuvem 21Vianet - basta substituir os sufixos apropriados para o seu ambiente.

Quando crias endpoints privados para uma conta de armazenamento e um Serviço de Sincronização de Armazenamento, o Azure cria registos A para eles nas respetivas zonas DNS privadas. O Azure também atualiza a entrada DNS pública de modo que os nomes de domínio totalmente qualificados regulares sejam CNAMEs para o nome relevanteprivatelink. Esta configuração permite que os nomes de domínio totalmente qualificados apontem para os endereços IP privados do endpoint quando o requerente está dentro da rede virtual e apontem para os endereços IP públicos do endpoint quando o requerente está fora da rede virtual.

Para o Ficheiros do Azure, cada ponto de extremidade privado tem um único nome de domínio totalmente qualificado, seguindo o padrão storageaccount.privatelink.file.core.windows.net, associado a um endereço IP privado. Para o Azure File Sync, cada ponto de extremidade privado tem quatro nomes de domínio totalmente qualificados, para os quatro pontos de extremidade diferentes que o Azure File Sync expõe: gerenciamento, sincronização (principal), sincronização (secundária) e monitoramento. Os nomes de domínio totalmente qualificados destes pontos finais corresponderão normalmente ao nome do Storage Sync Service, a menos que esse nome contenha caracteres não ASCII. Por exemplo, se o nome do seu Serviço de Sincronização de Armazenamento for mysyncservice na região E.U.A. Oeste 2, os pontos finais equivalentes seriam mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net e mysyncservicemonitoring.westus2.afs.azure.net. Cada ponto de extremidade privado para um Serviço de Sincronização de Armazenamento conterá quatro endereços IP distintos.

Como a sua Azure zona DNS privada está ligada à rede virtual que contém o endpoint privado, pode observar a configuração DNS chamando o cmdlet Resolve-DnsName do PowerShell numa VM Azure (alternativamente nslookup no Windows e Linux):

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

Neste exemplo, a conta storageaccount.file.core.windows.net de armazenamento é resolvida para o endereço IP privado do ponto de extremidade privado, que por acaso é 192.168.0.4.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     storageaccount.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

Se você executar o mesmo comando localmente, verá que o mesmo nome de conta de armazenamento é resolvido para o endereço IP público da conta de armazenamento; storageaccount.file.core.windows.net é um registro CNAME para storageaccount.privatelink.file.core.windows.net, que, por sua vez, é um registro CNAME para o cluster de armazenamento do Azure que hospeda a conta de armazenamento:

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

Esta configuração reflete o facto de que o Ficheiros do Azure e o Azure File Sync podem expor tanto os seus endpoints públicos como um ou mais endpoints privados por recurso. Para garantir que os nomes de domínio totalmente qualificados dos seus recursos se resolvam para os endereços IP dos pontos finais privados, deve configurar os seus servidores DNS locais. Pode realizar esta tarefa de várias formas:

  • Modificar o ficheiro hosts nos seus clientes para que os nomes de domínio totalmente qualificados das suas contas de armazenamento e dos seus serviços Storage Sync Service resolvam para os endereços IP privados pretendidos. Isso é fortemente desencorajado para ambientes de produção, já que você precisará fazer essas alterações em todos os clientes que precisam acessar seus endpoints privados. As alterações aos seus endpoints/recursos privados (eliminações, modificações, etc.) não serão tratadas automaticamente.
  • Criar zonas DNS em seus servidores locais para privatelink.file.core.windows.net e privatelink.afs.azure.net com registros A para seus recursos do Azure. Isso tem a vantagem de que os clientes em seu ambiente local poderão resolver automaticamente os recursos do Azure sem a necessidade de configurar cada cliente. No entanto, essa solução é igualmente frágil para modificar o arquivo hosts porque as alterações não são refletidas. Embora esta solução seja frágil, pode ser a melhor escolha para alguns ambientes.
  • Encaminhe as zonas core.windows.net e afs.azure.net dos seus servidores DNS no local para a sua zona DNS privada do Azure. O host DNS privado do Azure pode ser acessado por meio de um endereço IP especial (168.63.129.16) que só é acessível dentro de redes virtuais vinculadas à zona DNS privada do Azure. Para contornar esta limitação, pode executar servidores DNS adicionais dentro da sua rede virtual que encaminham core.windows.net para afs.azure.net as zonas DNS privadas equivalentes do Azure. Para simplificar esta configuração, a Microsoft disponibiliza comandos PowerShell que implementam automaticamente os servidores DNS na sua rede virtual Azure e os configuram conforme desejado. Para aprender a configurar o encaminhamento DNS, veja Configurar DNS com Ficheiros do Azure.

Encriptação em trânsito

As conexões feitas do agente do Azure File Sync ao seu compartilhamento de arquivos do Azure ou ao Serviço de Sincronização de Armazenamento são sempre criptografadas. Embora as contas de armazenamento do Azure tenham uma configuração para desabilitar a exigência de criptografia em trânsito para comunicações com os Arquivos do Azure (e os outros serviços de armazenamento do Azure gerenciados fora da conta de armazenamento), desabilitar essa configuração não afetará a criptografia do Azure File Sync ao se comunicar com os Arquivos do Azure. Por padrão, todas as contas de armazenamento do Azure têm a criptografia em trânsito habilitada.

Para mais informações sobre encriptação em trânsito, consulte exigir transferência segura no armazenamento Azure.

Consulte também