Considérations relatives à la mise en réseau pour Azure File Sync

Cet article traite des considérations réseau pour Azure File Sync, qui met en cache les partages de fichiers Azure sur des serveurs de fichiers Windows sur site. Pour les considérations relatives au réseau pour un déploiement direct d’Azure Files, consultez Considérations relatives au réseau pour Azure Files.

Le réseautage pour Azure File Sync implique deux objets Azure : un service de synchronisation de stockage (qui gère les serveurs enregistrés et les groupes de synchronisation) et un compte de stockage Azure (qui héberge les partages de fichiers). Dans la plupart des cas, vous n’avez pas besoin d’une configuration réseau spéciale au-delà d’une connexion internet basique, mais vous pouvez configurer des serveurs proxy, des pare-feux, un tunneling VPN ou ExpressRoute, des points de terminaison privés et un SMB via QUIC.

Connexion du serveur de fichiers Windows à Azure avec Azure File Sync

Pour configurer et utiliser Azure Files et Azure File Sync avec un serveur de fichiers Windows sur site, vous n'avez pas besoin d'un réseau spécial vers Azure au-delà d'une connexion internet basique. Pour déployer Azure File Sync, installez l’agent Azure File Sync sur le serveur de fichiers Windows que vous souhaitez synchroniser avec Azure. L’agent Azure File Sync permet de synchroniser avec un partage de fichiers Azure via deux canaux :

• Le protocole FileREST, qui est un protocole HTTPS utilisé pour accéder à votre partage de fichiers Azure. Comme le protocole FileREST utilise le protocole HTTPS standard pour le transfert de données, le port 443 doit être accessible en sortie. Azure File Sync n’utilise pas le protocole SMB pour transférer des données entre vos serveurs Windows locaux et votre partage de fichiers Azure.
• Le protocole de synchronisation Azure File Sync, qui est un protocole basé sur HTTPS utilisé pour échanger des informations de synchronisation, c’est-à-dire les informations de version sur les fichiers et les dossiers entre les points de terminaison de votre environnement. Ce protocole est également utilisé pour échanger des métadonnées sur les fichiers et les dossiers, tels que les horodateurs et les listes de contrôle d’accès.

Installer le partage de fichiers Azure directement sur SMB pour l'agent Azure File Sync n'est pas obligatoire et est déconseillé, car les modifications directes du partage de fichiers pourraient ne pas être détectées avant 24 heures. Pour utiliser le partage de fichiers directement sans Azure File Sync, consultez Azure Files Networking Overview.

Même si Azure File Sync ne nécessite pas de configuration de mise en réseau spéciale, certains clients peuvent souhaiter configurer des paramètres de mise en réseau avancés pour activer les scénarios suivants :

• Interopérer avec la configuration du serveur proxy de votre organisation.
• Ouvrir le pare-feu local de votre organisation pour accéder aux services Azure Files et Azure File Sync.
• Transférez en tunnel le trafic Azure Files et Azure File Sync via une connexion ExpressRoute ou un réseau privé virtuel (VPN).

Configuration de serveurs proxy

Azure File Sync peut interopérer entièrement avec un serveur proxy, mais vous devez configurer manuellement les paramètres de terminaison proxy pour votre environnement avec Azure File Sync. Utilisez PowerShell et le cmdlet Set-StorageSyncProxyConfigurationserveur Azure File Sync.

Pour plus d’informations sur la configuration d’Azure File Sync à l’aide d’un serveur proxy, consultez Configuration d’Azure File Sync avec un serveur proxy.

Configuration des pare-feu et des balises de service

Pour des raisons de sécurité, de nombreuses organisations isolent leurs serveurs de fichiers de la plupart des emplacements internet. Pour utiliser Azure File Sync dans un tel environnement, vous devez configurer votre pare-feu afin d’autoriser l’accès sortant à certains services Azure. Si votre pare-feu supporte le filtrage URL ou de domaine, autorisez l’accès sortant au port 443 aux points de terminaison cloud requis qui hébergent ces services Azure spécifiques. Si ce n’est pas le cas, vous pouvez récupérer les plages d’adresses IP pour ces services Azure via des étiquettes de service.

Azure File Sync requiert les plages d’adresses IP pour les services suivants, tels qu’identifiés par leurs balises de service :

Si vous utilisez Azure File Sync dans Azure, même dans une région différente, vous pouvez utiliser le nom de l’étiquette du service directement dans votre groupe de sécurité réseau pour autoriser le trafic vers ce service. Pour en savoir plus, consultez Groupes de sécurité réseau.

Si vous utilisez Azure File Sync localement, vous pouvez utiliser l’API d’étiquette de service pour obtenir des plages d’adresses IP spécifiques pour la liste verte de votre pare-feu. Il existe deux méthodes pour obtenir ces informations :

• La liste actuelle des plages d’adresses IP pour tous les services Azure qui prennent en charge les étiquettes de service est publiée chaque semaine dans le centre de téléchargement Microsoft sous la forme d’un document JSON. Chaque Cloud Azure possède son propre document JSON avec les plages d’adresses IP pertinentes pour ce Cloud :
  • Azure public
  • Azure Gouvernement des États-Unis
  • Microsoft Azure géré par 21Vianet
  • Azure Allemagne
• L’API de détection des étiquettes de service (préversion) permet la récupération par programmation de la liste actuelle des étiquettes de service. En préversion, l’API de détection des étiquettes de service peut renvoyer des informations qui sont moins récentes que les informations renvoyées par les documents JSON publiés sur le centre de téléchargement Microsoft. Vous pouvez utiliser l’aire de l’API en fonction de vos préférences d’automatisation :
  • REST API
  • Azure PowerShell
  • Service de contrôle d’accès Azure (CLI)

Pour en savoir plus sur l’utilisation de l’API des balises de service pour récupérer les adresses de vos services, consultez Liste d’autorisation des adresses IP d’Azure File Sync.

Tunneling du trafic sur un réseau privé virtuel ou ExpressRoute

Certaines organisations exigent que la communication avec Azure passe par un tunnel réseau, comme un réseau privé virtuel ou ExpressRoute, pour offrir une couche supplémentaire de sécurité ou pour garantir que la communication avec Azure suit une route déterministe.

Azure Files et Azure File Sync prennent en charge les mécanismes suivants pour transférer le trafic entre vos serveurs locaux et Azure :

• Passerelle VPN Azure : Une passerelle VPN est un type spécifique de passerelle réseau virtuelle que vous utilisez pour envoyer du trafic chiffré entre un réseau virtuel Azure et un emplacement alternatif (comme sur site) via Internet. Une Passerelle VPN Azure est une ressource Azure que vous déployez dans un groupe de ressources aux côtés d’un compte de stockage ou d’autres ressources Azure. Comme Azure File Sync est conçu pour être utilisé avec un serveur de fichiers Windows sur site, on utilise normalement un VPN site-à-site, bien qu'il soit techniquement possible d'utiliser un VPN point-à-site.

  Les connexions VPN site-à-site relient votre réseau virtuel Azure au réseau local de votre organisation. Une connexion VPN site-à-site vous permet de configurer une connexion VPN une seule fois, pour un serveur VPN ou un appareil hébergé sur le réseau de votre organisation, plutôt que de le faire pour chaque appareil client ayant besoin d'accéder à votre partage de fichiers Azure. Pour simplifier le déploiement d’une connexion VPN site-à-site, voir Configurer un VPN site-à-site pour une utilisation avec Azure Files.

• ExpressRoute, qui vous permet de créer une route définie (une connexion privée) entre Azure et votre réseau local qui ne passe pas par Internet. Étant donné qu’ExpressRoute fournit un chemin d’accès dédié entre votre centre de données local et Azure, ExpressRoute peut être utile lorsque les performances du réseau sont un élément clé à prendre en compte. ExpressRoute est également une bonne option quand une stratégie ou des exigences réglementaires de votre organisation exigent un chemin d’accès déterministe à vos ressources dans le cloud.

SMB sur QUIC

Si le port 445 est bloqué dans votre environnement, vous pouvez utiliser SMB via QUIC comme alternative au VPN ou à ExpressRoute. SMB sur QUIC utilise le protocole de transport QUIC via le port 443, que la plupart des organisations et fournisseurs d’accès Internet (FAI) ont ouvert pour supporter le trafic HTTPS. Cette fonctionnalité élimine une grande partie de la configuration réseau normalement nécessaire pour accéder à un partage de fichiers à distance via Internet public.

Pour utiliser SMB sur QUIC avec Azure File Sync :

• Le point de terminaison serveur Azure File Sync doit fonctionner sur une machine virtuelle Windows Server Datacenter : Azure Edition dans Azure.
• Les clients doivent utiliser Windows 11 ou versions ultérieures.

Pour les détails d’installation et de configuration, voir SMB via QUIC.

Points de terminaison privés pour Azure Files et Azure File Sync

Outre les points de terminaison publics par défaut qu’Azure Files et Azure File Sync fournissent via le compte de stockage et le service de synchronisation du stockage, ils offrent la possibilité de disposer d’un ou de plusieurs points de terminaison privés par ressource. Cette option vous permet de vous connecter de manière privée et sécurisée aux partages de fichiers Azure depuis des sites via un VPN ou ExpressRoute, ainsi que depuis un réseau virtuel Azure. Lorsque vous créez un point de terminaison privé pour une ressource Azure, il obtient une adresse IP privée provenant de l’espace d’adressage de votre réseau virtuel, de la même façon que votre serveur de fichiers Windows local a une adresse IP de l’espace d’adressage dédié de votre réseau local.

Un point de terminaison privé individuel est associé à un sous-réseau de réseau virtuel Azure spécifique. Les comptes de stockage et les services de synchronisation du stockage peuvent avoir des points de terminaison privés dans plusieurs réseaux virtuels.

L’utilisation de points de terminaison privés vous permet d’effectuer les opérations suivantes :

• Établir une connexion sécurisée à vos ressources Azure à partir de réseaux locaux en utilisant une connexion VPN ou ExpressRoute avec un peering privé.
• Sécuriser vos ressources Azure en désactivant les points de terminaison publics pour Azure Files et File Sync. Par défaut, la création d’un point de terminaison privé n’a pas pour effet de bloquer les connexions au point de terminaison public.
• Renforcer la sécurité du réseau virtuel en bloquant l’exfiltration des données du réseau virtuel (et des limites du peering).

Pour créer un point de terminaison privé, voir Configurer les terminaux privés pour Azure File Sync.

Points de terminaison privés et DNS

Lorsque vous créez un point de terminaison privé, Azure crée ou met à jour également une zone DNS privée correspondant au privatelink sous-domaine. Pour les régions de cloud public, ces zones DNS sont privatelink.file.core.windows.net pour Azure Files et privatelink.afs.azure.net pour Azure File Sync.

Lorsque vous créez des points de terminaison privés pour un compte de stockage et un service de synchronisation de stockage, Azure crée des enregistrements A pour eux dans leurs zones DNS privées respectives. Azure met également à jour l’entrée DNS publique de sorte que les noms de domaine pleinement qualifiés réguliers soient des CNAME pour le nom concernéprivatelink. Cette configuration permet aux noms de domaine pleinement qualifiés de pointer vers les adresses IP privées du point d’accès lorsque le demandeur est à l’intérieur du réseau virtuel et de pointer vers les adresses IP publiques lorsque le demandeur est en dehors du réseau virtuel.

Pour Azure Files, chaque point de terminaison privé a un nom de domaine complet unique, qui suit le modèle storageaccount.privatelink.file.core.windows.net, mappé à une adresse IP privée pour le point de terminaison privé. Pour Azure File Sync, chaque point de terminaison privé possède quatre noms de domaine complets, pour les quatre points de terminaison différents qu’Azure File Sync expose : gestion, synchronisation (principale), synchronisation (secondaire) et supervision. Les noms de domaine complets pour ces points de terminaison suivent normalement le nom du service de synchronisation du stockage, sauf si le nom contient des caractères non-ASCII. Par exemple, si le nom de votre service de synchronisation du stockage est mysyncservice dans la région USA Ouest 2, les points de terminaison équivalents sont mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net et mysyncservicemonitoring.westus2.afs.azure.net. Chaque point de terminaison privé pour un service de synchronisation du stockage contient quatre adresses IP distinctes.

Étant donné que votre zone DNS privée Azure est connectée au réseau virtuel contenant le point de terminaison privé, vous pouvez observer la configuration DNS en appelant l’applet Resolve-DnsName de commande à partir de PowerShell dans une machine virtuelle Azure (alternativement nslookup dans Windows et Linux) :

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

Dans cet exemple, le compte de stockage storageaccount.file.core.windows.net se résout en l’adresse IP privée du point de terminaison privé, à savoir 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

Si vous exécutez la même commande depuis l’infrastructure locale, vous constaterez que le même nom de compte de stockage pointe cette fois vers l’adresse IP publique du compte de stockage ; storageaccount.file.core.windows.net est un enregistrement CNAME pour storageaccount.privatelink.file.core.windows.net, qui à son tour est un enregistrement CNAME pour le cluster de stockage Azure hébergeant le compte de stockage :

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

Cette configuration reflète le fait que Azure Files et Azure File Sync peuvent exposer à la fois leurs points publics et un ou plusieurs points privés par ressource. Pour garantir que les noms de domaine complets (FQDN) de vos ressources pointent vers les adresses IP des points de terminaison privés, vous devez configurer vos serveurs DNS sur site. Vous pouvez accomplir cette tâche de plusieurs manières :

• En modifiant le fichier hosts sur vos clients afin que les noms de domaine complets de vos comptes de stockage et du service de synchronisation du stockage soient résolus en adresses IP privées. Ceci est fortement déconseillé pour les environnements de production, car vous devez alors apporter ces modifications à chaque client qui a besoin d’accéder à vos points de terminaison privés. Les modifications apportées à vos ressources/points de terminaison privés (suppressions, modifications, etc.) ne sont pas gérées automatiquement.
• Création de zones DNS sur vos serveurs locaux pour privatelink.file.core.windows.net et privatelink.afs.azure.net avec des enregistrements A pour vos ressources Azure. L’avantage de cette méthode est que les clients de votre environnement local pourront résoudre automatiquement les ressources Azure sans avoir à configurer chaque client. Cependant, cette solution s’avère tout aussi fragile pour ce qui est de la modification du fichier hôtes, car les modifications n’apparaîtront pas. Bien que fragile, cette solution peut s’avérer être le meilleur choix pour certains environnements.
• Transférez les zones core.windows.net et afs.azure.net de vos serveurs DNS locaux vers votre zone DNS privée Azure. Il est possible d’atteindre l’hôte DNS privé Azure via une adresse IP spéciale (168.63.129.16) qui est uniquement accessible à l’intérieur des réseaux virtuels qui sont liés à la zone DNS privée Azure. Pour contourner cette limitation, vous pouvez faire fonctionner des serveurs DNS supplémentaires dans votre réseau virtuel qui redirigent core.windows.net vers afs.azure.net les zones DNS privées Azure équivalentes. Pour simplifier cette configuration, Microsoft propose des cmdlets PowerShell qui déploient automatiquement les serveurs DNS dans votre réseau virtuel Azure et les configurent selon les souhaits. Pour savoir comment configurer le transfert DNS, voir Configurer le DNS avec Azure Files.

Chiffrement en transit

Les connexions établies à partir de l’agent Azure File Sync vers votre service de synchronisation du stockage ou le partage de fichiers Azure sont toujours chiffrées. Bien que les comptes de stockage Azure disposent d’un paramètre permettant de désactiver le chiffrement en transit pour les communications vers Azure Files (et les autres services de stockage Azure qui sont gérés à partir du compte de stockage), la désactivation de ce paramètre n’affecte pas le chiffrement d’Azure File Sync lors de la communication avec Azure Files. Par défaut, le chiffrement en transit est activé pour tous les comptes de stockage Azure.

Pour plus d’informations sur le chiffrement en transit, voir exiger un transfert sécurisé dans le stockage Azure.

Voir aussi

• Plan pour un déploiement Azure File Sync
• Déployer Azure File Sync