Considerazioni sulla rete per Sincronizzazione file di Azure

È possibile connettersi a una condivisione file di Azure in due modi:

1. Accedere alla condivisione direttamente tramite i protocolli SMB o FileREST. Questo modello di accesso viene usato principalmente per eliminare il maggior numero possibile di server locali.
2. Creare una cache della condivisione file di Azure in un server locale (o macchina virtuale di Azure) con Sincronizzazione file di Azure e accedere ai dati della condivisione file dal server locale con il protocollo scelto (SMB, NFS, FTPS e così via). Questo modello di accesso è utile perché combina il meglio delle prestazioni locali e della scalabilità cloud con servizi a valore aggiunto, ad esempio Backup di Azure.

Questo articolo è incentrato sul secondo scenario: come configurare la rete quando il caso d'uso richiede l'uso di Sincronizzazione file di Azure per memorizzare nella cache i file in locale anziché montare direttamente la condivisione file di Azure tramite SMB. Per altre informazioni sulle considerazioni di rete per una distribuzione di File di Azure, vedere Considerazioni sulla rete per File di Azure.

La configurazione di rete per Sincronizzazione file di Azure riguarda due oggetti di Azure diversi, ovvero un servizio di sincronizzazione archiviazione e un account di archiviazione di Azure. Un account di archiviazione è un costrutto di gestione che rappresenta un pool condiviso di archiviazione in cui è possibile distribuire più condivisioni file, nonché altre risorse di archiviazione, ad esempio BLOB o code. Il servizio di sincronizzazione archiviazione è un costrutto di gestione che rappresenta i server registrati, ovvero file server Windows con una relazione di trust stabilita con Sincronizzazione file di Azure, e i gruppi di sincronizzazione, che definiscono la topologia della relazione di sincronizzazione.

Connessione del file server Windows ad Azure con Sincronizzazione file di Azure

Per configurare e usare File di Azure e Sincronizzazione file di Azure con un file server Windows locale, non è necessaria alcuna rete speciale in Azure oltre a una connessione Internet di base. Per distribuire Sincronizzazione file di Azure, installare il relativo agente nel file server Windows da sincronizzare con Azure. L'agente di Sincronizzazione file di Azure esegue la sincronizzazione con una condivisione file di Azure tramite due canali:

• Il protocollo FileREST, che è un protocollo basato su HTTPS usato per accedere alla condivisione file di Azure. Poiché il protocollo FileREST usa HTTPS standard per il trasferimento dei dati, la porta 443 deve essere accessibile in uscita. Sincronizzazione file di Azure non usa il protocollo SMB per trasferire i dati tra i server Windows locali e la condivisione file di Azure.
• Il protocollo di sincronizzazione Sincronizzazione file di Azure, ovvero un protocollo basato su HTTPS usato per lo scambio di informazioni sulla sincronizzazione, vale a dire le informazioni sulla versione dei file e delle cartelle tra gli endpoint nell'ambiente. Questo protocollo viene usato anche per scambiare metadati relativi ai file e alle cartelle, ad esempio timestamp ed elenchi di controllo di accesso (ACL).

Poiché File di Azure offre l'accesso diretto al protocollo SMB nelle condivisioni file di Azure, i clienti spesso si chiedono se devono configurare una rete speciale per montare le condivisioni file di Azure usando SMB per l'accesso all'agente Sincronizzazione file di Azure. Questo non è obbligatorio ed è effettivamente sconsigliato tranne negli scenari di amministratore, a causa della mancanza di rilevamento rapido delle modifiche apportate direttamente alla condivisione file di Azure. Le modifiche potrebbero non essere individuate per più di 24 ore a seconda delle dimensioni e del numero di elementi nella condivisione file di Azure. Se si vuole usare direttamente la condivisione file di Azure anziché usare Sincronizzazione file di Azure per memorizzare nella cache locale, vedere panoramica della rete File di Azure.

Anche se Sincronizzazione file di Azure non richiede alcuna configurazione di rete speciale, alcuni clienti potrebbero voler configurare impostazioni di rete avanzate per abilitare gli scenari seguenti:

• Interoperabilità con la configurazione del server proxy dell'organizzazione.
• Aprire il firewall locale dell'organizzazione per i servizi File di Azure e Sincronizzazione file di Azure.
• Tunnel File di Azure e Sincronizzazione file di Azure traffico tramite una connessione ExpressRoute o una rete privata virtuale (VPN).

Configurazione dei server proxy

Molte organizzazioni usano un server proxy come intermediario tra le risorse interne alla rete locale e le risorse esterne, ad esempio in Azure. I server proxy sono utili per molte applicazioni, ad esempio l'isolamento della rete e la sicurezza, il monitoraggio e la registrazione. Sincronizzazione file di Azure può interagire completamente con un server proxy, ma è necessario configurare manualmente le impostazioni dell'endpoint proxy per l'ambiente con Sincronizzazione file di Azure. Questa operazione deve essere eseguita tramite PowerShell usando il cmdlet Set-StorageSyncProxyConfigurationdel server Sincronizzazione file di Azure .

Per altre informazioni su come configurare Sincronizzazione file di Azure con un server proxy, vedere Configurazione di Sincronizzazione file di Azure con un server proxy.

Configurazione di firewall e tag di servizio

Molte organizzazioni isolano i file server dalla maggior parte dei percorsi Internet a scopo di sicurezza. Per usare Sincronizzazione file di Azure in un ambiente di questo tipo, è necessario configurare il firewall per consentire l'accesso in uscita per selezionare i servizi di Azure. A tale scopo, è possibile consentire l'accesso in uscita alla porta 443 agli endpoint cloud necessari che ospitano tali servizi di Azure specifici se il firewall supporta URL/domini. In caso contrario, è possibile recuperare gli intervalli di indirizzi IP per questi servizi di Azure tramite tag di servizio.

Sincronizzazione file di Azure richiede gli intervalli di indirizzi IP per i servizi seguenti, identificati dai rispettivi tag del servizio:

Se si usa Sincronizzazione file di Azure in Azure, anche se si trova in un'area diversa, è possibile usare il nome del tag di servizio direttamente nel gruppo di sicurezza di rete per consentire il traffico verso tale servizio. Per altre informazioni, vedere Gruppi di sicurezza di rete.

Se si usa Sincronizzazione file di Azure locale, è possibile usare l'API tag del servizio per ottenere intervalli di indirizzi IP specifici per l'elenco di indirizzi CONSENTITI del firewall. Per recuperare queste informazioni, sono disponibili due metodi:

• L'elenco corrente degli intervalli di indirizzi IP per tutti i servizi di Azure che supportano i tag di servizio viene pubblicato settimanalmente nell'Area download Microsoft sotto forma di documento JSON. Ogni cloud di Azure ha un proprio documento JSON con gli intervalli di indirizzi IP pertinenti per il cloud:
  • Pubblico di Azure
  • Azure US Gov
  • Microsoft Azure gestito da 21Vianet
  • Azure Germania
• L'API di individuazione di tag di servizio (anteprima) consente il recupero a livello di codice dell'elenco corrente di tag di servizio. Nella versione di anteprima questa API potrebbe restituire informazioni meno aggiornate di quelle restituite dai documenti JSON pubblicati nell'Area download Microsoft. È possibile usare la superficie API in base alle preferenze di automazione:
  • REST API
  • Azure PowerShell
  • Interfaccia della riga di comando di Azure

Per altre informazioni su come usare l'API dei tag di servizio per recuperare gli indirizzi dei servizi, vedere Allowlist for Sincronizzazione file di Azure IP addresses (Elenco di indirizzi IP di Sincronizzazione file di Azure).

Tunneling del traffico su una rete privata virtuale o ExpressRoute

Alcune organizzazioni richiedono la comunicazione con Azure per passare tramite un tunnel di rete, ad esempio una VPN o ExpressRoute, per un ulteriore livello di sicurezza o per garantire la comunicazione con Azure segue una route deterministica.

Quando si stabilisce un tunnel di rete tra la rete locale e Azure, si esegue il peering della rete locale con una o più reti virtuali in Azure. Una rete virtuale o una rete virtuale è simile a una rete tradizionale che si potrebbe usare in locale. Come un account di archiviazione di Azure o una macchina virtuale di Azure, una rete virtuale è una risorsa di Azure distribuita in un gruppo di risorse.

File di Azure e Sincronizzazione file di Azure supportano i meccanismi seguenti per eseguire il tunneling del traffico tra i server locali e Azure:

• Azure Gateway VPN: un gateway VPN è un tipo specifico di gateway di rete virtuale usato per inviare traffico crittografato tra una rete virtuale di Azure e un percorso alternativo (ad esempio in locale) tramite Internet. Un gateway VPN di Azure è una risorsa di Azure che può essere distribuita in un gruppo di risorse insieme a un account di archiviazione o ad altre risorse di Azure. Poiché Sincronizzazione file di Azure è destinato a essere usato con un file server Windows locale, in genere si usa una VPN da sito a sito, anche se tecnicamente è possibile usare una VPN da punto a sito.

  Le VPN da sito a sito connettono la rete virtuale di Azure e la rete locale dell'organizzazione. Una connessione VPN da sito a sito consente di configurare una connessione VPN una sola volta, per un dispositivo o un server VPN ospitato nella rete dell'organizzazione, invece che per ogni dispositivo client che ha la necessità di accedere alla condivisione file di Azure. Per semplificare la distribuzione di una connessione VPN da sito a sito, vedere Configurare una VPN da sito a sito per l'uso con File di Azure.

• ExpressRoute, che consente di creare una route definita (connessione privata) tra Azure e la rete locale che non attraversa Internet. Poiché ExpressRoute fornisce un percorso dedicato tra il data center locale e Azure, ExpressRoute può essere utile quando le prestazioni di rete sono una considerazione fondamentale. ExpressRoute è un'opzione valida anche laddove i criteri dell'organizzazione o i requisiti ambientali impongono un percorso deterministico verso le risorse nel cloud.

Endpoint privati

Oltre agli endpoint pubblici predefiniti File di Azure e Sincronizzazione file di Azure fornire tramite l'account di archiviazione e il servizio di sincronizzazione archiviazione, offrono la possibilità di avere uno o più endpoint privati per risorsa. In questo modo è possibile connettersi privatamente e in modo sicuro alle condivisioni file di Azure dall'ambiente locale tramite VPN o ExpressRoute e dall'interno di una rete virtuale di Azure. Un endpoint privato creato per una risorsa di Azure ottiene un indirizzo IP privato dallo spazio di indirizzi della rete virtuale, in modo simile a un file server Windows locale che riceve un indirizzo IP all'interno dello spazio di indirizzi dedicato della rete locale.

Un singolo endpoint privato è associato a una specifica subnet di rete virtuale di Azure. Un account di archiviazione e i servizi di sincronizzazione archiviazione possono avere endpoint privati in più reti virtuali.

L'uso di endpoint privati consente di:

• Connettersi in modo sicuro alle risorse di Azure dalle reti locali usando una connessione VPN o ExpressRoute con peering privato.
• Proteggere le risorse di Azure disabilitando gli endpoint pubblici per File di Azure e Sincronizzazione file. Per impostazione predefinita, la creazione di un endpoint privato non blocca le connessioni all'endpoint pubblico.
• Aumentare la sicurezza per la rete virtuale consentendo di bloccare l'esfiltrazione dei dati dalla rete virtuale e dai limiti di peering.

Per creare un endpoint privato, vedere Configurazione di endpoint privati per Sincronizzazione file di Azure.

Endpoint privati e DNS

Quando si crea un endpoint privato, per impostazione predefinita viene creata o aggiornata anche una zona DNS privata esistente corrispondente al privatelink sottodominio. Per le aree del cloud pubblico, queste zone DNS sono privatelink.file.core.windows.net per File di Azure e privatelink.afs.azure.net per Sincronizzazione file di Azure.

Quando si creano endpoint privati per un account di archiviazione e un servizio di sincronizzazione archiviazione, viene creato un record A per le rispettive zone DNS privato. Aggiorniamo anche la voce DNS pubblica in modo che i normali nomi di dominio completi siano CNAM per il nome pertinente privatelink . In questo modo i nomi di dominio completo puntano agli indirizzi IP degli endpoint privati quando il richiedente si trova all'interno della rete virtuale e agli indirizzi IP degli endpoint pubblici quando il richiedente si trova all'esterno.

Per File di Azure, ogni endpoint privato ha un singolo nome di dominio completo, seguendo il modello storageaccount.privatelink.file.core.windows.net, mappato a un indirizzo IP privato per l'endpoint privato. Per Sincronizzazione file di Azure, ogni endpoint privato ha quattro nomi di dominio completi, per i quattro endpoint diversi esposti da Sincronizzazione file di Azure, ossia gestione, sincronizzazione (primaria), sincronizzazione (secondaria) e monitoraggio. I nomi di dominio completi per questi endpoint seguono normalmente il nome del servizio di sincronizzazione archiviazione, a meno che il nome non contenga caratteri non ASCII. Se ad esempio il nome del servizio di sincronizzazione archiviazione è mysyncservice nell'area Stati Uniti occidentali 2, gli endpoint equivalenti saranno mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net e mysyncservicemonitoring.westus2.afs.azure.net. Ogni endpoint privato per un servizio di sincronizzazione archiviazione conterrà quattro indirizzi IP distinti.

Poiché la zona DNS privata di Azure è connessa alla rete virtuale contenente l'endpoint privato, è possibile osservare la configurazione DNS quando si chiama il Resolve-DnsName cmdlet da PowerShell in una macchina virtuale di Azure (in alternativa nslookup in Windows e Linux):

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

Per questo esempio, l'account di archiviazione storageaccount.file.core.windows.net viene risolto nell'indirizzo IP privato dell'endpoint privato, che è 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

Se si esegue lo stesso comando dall'ambiente locale, si noterà che lo stesso nome dell'account di archiviazione viene invece risolto nell'indirizzo IP pubblico dell'account di archiviazione; storageaccount.file.core.windows.net è un record CNAME per storageaccount.privatelink.file.core.windows.net, che a sua volta è un record CNAME per il cluster di archiviazione di Azure che ospita l'account di archiviazione:

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

Ciò riflette il fatto che File di Azure e Sincronizzazione file di Azure possono esporre sia gli endpoint pubblici che uno o più endpoint privati per ogni risorsa. Per assicurarsi che i nomi di dominio completi delle risorse si risolvano negli indirizzi IP privati degli endpoint privati, è necessario cambiare la configurazione nei server DNS locali. A questo scopo è possibile procedere in vari modi:

• Modificare il file hosts nei client per risolvere i nomi di dominio completi per gli account di archiviazione e i servizi di sincronizzazione archiviazione negli indirizzi IP privati desiderati. Questo è fortemente sconsigliato per gli ambienti di produzione, poiché è necessario apportare queste modifiche a ogni client che deve accedere agli endpoint privati. Le modifiche apportate agli endpoint/risorse private (eliminazioni, modifiche e così via) non verranno gestite automaticamente.
• Creare zone DNS nei server locali per privatelink.file.core.windows.net e privatelink.afs.azure.net con i record A per le risorse di Azure. Questo ha il vantaggio che i client nell'ambiente locale saranno in grado di risolvere automaticamente le risorse di Azure senza dover configurare ogni client. Tuttavia, questa soluzione è analogamente fragile per modificare il file hosts perché le modifiche non vengono riflesse. Anche se questa soluzione è fragile, potrebbe essere la scelta migliore per alcuni ambienti.
• Inoltrare le zone core.windows.net e afs.azure.net dai server DNS locali alla zona DNS privato di Azure. L'host DNS privato di Azure è raggiungibile tramite un indirizzo IP speciale (168.63.129.16) accessibile solo all'interno delle reti virtuali collegate alla zona DNS privato di Azure. Per ovviare a questa limitazione, è possibile eseguire altri server DNS all'interno della rete virtuale che verranno inoltrati core.windows.net e afs.azure.net alle zone DNS private di Azure equivalenti. Per semplificare questa configurazione, sono stati forniti cmdlet di PowerShell che distribuiranno automaticamente i server DNS nella rete virtuale di Azure e li configureranno in base alle esigenze. Per informazioni su come configurare l'inoltro DNS, vedere Configurazione di DNS con File di Azure.

Crittografia dei dati in transito

Le connessioni effettuate dall'agente di Sincronizzazione file di Azure alla condivisione file di Azure o al servizio di sincronizzazione archiviazione sono sempre crittografate. Anche se gli account di archiviazione di Azure hanno un'impostazione per disabilitare la richiesta di crittografia in transito per le comunicazioni a File di Azure (e gli altri servizi di archiviazione di Azure gestiti dall'account di archiviazione), la disabilitazione di questa impostazione non influirà sulla crittografia Sincronizzazione file di Azure durante la comunicazione con File di Azure. Per impostazione predefinita, la crittografia in transito è abilitata per tutti gli account di archiviazione di Azure.

Per altre informazioni sulla crittografia in transito, vedere Richiedere il trasferimento sicuro in Archiviazione di Azure.

Vedi anche

• Pianificazione per la distribuzione di Sincronizzazione file di Azure
• Come distribuire Sincronizzazione file di Azure