Considerazioni sulla connettività di 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 di archiviazione condiviso in cui è possibile creare più condivisioni di file, nonché altre risorse di archiviazione, ad esempio blob o code. Il Servizio di sincronizzazione dell'archiviazione è un costrutto di gestione che rappresenta i server registrati, ovvero server di file Windows con una relazione di attendibilità stabilita con Sincronizzazione file di Azure, e i gruppi di sincronizzazione, che definiscono la topologia della relazione di sincronizzazione.

Collegare Windows File Server 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, si installa l'agente di Sincronizzazione file di Azure nel server file Windows che si desidera 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 di Sincronizzazione file di Azure, ossia un protocollo basato su HTTPS usato per scambiare informazioni di sincronizzazione, in particolare le informazioni sulla versione di file e cartelle tra gli endpoint del proprio 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 desidera usare direttamente la condivisione file di Azure anziché usare Sincronizzazione file di Azure per memorizzare nella cache in locale, vedere Panoramica della rete di 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.
• Instradare il traffico di File di Azure e Sincronizzazione file di Azure 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

Per motivi di sicurezza, molte organizzazioni isolano i propri file server dalla maggior parte delle località internet. 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. Se il tuo firewall supporta il filtraggio di URL o domini, consenti l'accesso in uscita alla porta 443 agli endpoint cloud richiesti che ospitano quei specifici servizi Azure. 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 usi Sincronizzazione file di Azure in Azure, anche se si trova in un'area geografica diversa, puoi usare direttamente il nome del tag di servizio nel gruppo di sicurezza di rete per consentire il traffico verso quel servizio. Per altre informazioni, vedere Gruppi di sicurezza di rete.

Se si usa Sincronizzazione file di Azure in locale, è possibile utilizzare l'API dei tag di servizio per ottenere intervalli di indirizzi IP specifici da usare per l'elenco elementi 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:
  • API REST
  • Azure PowerShell
  • Interfaccia della riga di comando di Azure

Per altre informazioni su come usare l'API del tag di servizio per recuperare gli indirizzi dei propri servizi, vedi Allowlist per gli indirizzi IP di Sincronizzazione file di Azure.

Instradamento del traffico tramite una rete privata virtuale (VPN) 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 VNET, è simile a una rete tradizionale che gestiresti 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 è progettato per essere usato con un file server Windows locale, normalmente si usa una VPN Site-to-Site (S2S), anche se tecnicamente è possibile usare una VPN Point-to-Site (P2S).

  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.

SMB su QUIC

Se la porta 445 è bloccata nel tuo ambiente, puoi usare SMB su QUIC come alternativa a VPN o ExpressRoute. SMB su QUIC utilizza il protocollo di trasporto QUIC sulla porta 443, che la maggior parte delle organizzazioni e dei provider di servizi internet (ISP) ha aperto per supportare il traffico HTTPS. Questa funzione elimina gran parte della configurazione di rete normalmente necessaria per accedere a una condivisione file da remoto tramite internet pubblico.

Per usare SMB su QUIC con Sincronizzazione file di Azure:

• L'endpoint server Sincronizzazione file di Azure deve funzionare su una macchina virtuale Windows Server Datacenter: Azure Edition in Azure.
• I client devono essere in esecuzione di Windows 11 o versioni successive.

Per i dettagli di installazione e configurazione, vedere SMB su QUIC.

Endpoint privati

Oltre agli endpoint pubblici predefiniti che File di Azure e Sincronizzazione file di Azure forniscono tramite l'account di archiviazione e il servizio Storage Sync, offrono anche la possibilità di avere uno o più endpoint privati per ogni 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. Gli account di archiviazione e i servizi di sincronizzazione dell'archiviazione possono avere endpoint privati in più di una rete virtuale.

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 crei endpoint privati per un account di archiviazione e per uno Storage Sync Service, creiamo record A nelle rispettive zone DNS private. 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, secondo il modello storageaccount.privatelink.file.core.windows.net, associato a un singolo 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. Ad esempio, se il nome del servizio di sincronizzazione di archiviazione è mysyncservice nell'area geografica West US 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"

In questo esempio, l'account di archiviazione storageaccount.file.core.windows.net si risolve nell'indirizzo IP privato dell'endpoint privato, che in questo caso è 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 endpoint pubblici sia uno o più endpoint privati per ogni risorsa. Per assicurarsi che i nomi di dominio completi delle proprie risorse si risolvano negli indirizzi IP privati associati agli endpoint privati, è necessario modificare la configurazione sui server DNS locali. A questo scopo è possibile procedere in vari modi:

• Modificare il file hosts sui client per fare in modo che i nomi di dominio completi degli account di archiviazione e dei servizi di sincronizzazione dell’archiviazione vengano risolti 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.
• Creazione di zone DNS nei server locali per privatelink.file.core.windows.net e privatelink.afs.azure.net con 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 è altrettanto vulnerabile alle modifiche del file hosts, perché tali modifiche non vengono recepite. 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. Sebbene gli account di archiviazione di Azure dispongano di un'impostazione per disabilitare la richiesta della crittografia in transito per le comunicazioni con File di Azure (e con gli altri servizi di archiviazione di Azure gestiti tramite l'account di archiviazione), la disattivazione di questa impostazione non influirà sulla crittografia usata da Sincronizzazione file di Azure nelle comunicazioni 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 della distribuzione di Sincronizzazione file di Azure
• Distribuire Sincronizzazione file di Azure