Aandachtspunten voor netwerken voor Azure File Sync

Dit artikel behandelt netwerkoverwegingen voor Azure File Sync, dat Azure-bestandsdelingen op on-premises Windows-bestandsservers in de cache plaatst. Voor netwerkoverwegingen voor een directe Azure Files-implementatie, zie Azure Files netwerkoverwegingen.

Netwerken voor Azure File Sync omvat twee Azure-objecten: een Storage Sync Service (die geregistreerde servers en synchronisatiegroepen beheert) en een Azure opslagaccount (dat de bestandsdelingen host). In de meeste gevallen heb je geen speciale netwerkconfiguratie nodig behalve een basis internetverbinding, maar je kunt wel proxyservers, firewalls, VPN- of ExpressRoute-tunneling, privé-endpoints en SMB via QUIC configureren.

Windows-bestandsserver verbinden met Azure via Azure File Sync

Om Azure Files en Azure File Sync op te zetten en te gebruiken met een on-premises Windows-bestandsserver, heb je geen speciale netwerkverbinding nodig om Azure te verbinden, behalve een basis internetverbinding. Om Azure File Sync te implementeren, installeer je de Azure File Sync agent op de Windows-bestandsserver die je met Azure wilt synchroniseren. De Azure File Sync agent bereikt synchronisatie met een Azure-bestandsdeling via twee kanalen:

• Het FileREST-protocol, een HTTPS-protocol dat wordt gebruikt voor toegang tot uw Azure-bestandsshare. Omdat het FileREST-protocol gebruikmaakt van standaard HTTPS voor gegevensoverdracht, moet poort 443 uitgaand toegankelijk zijn. Azure File Sync gebruikt het SMB-protocol niet om gegevens over te dragen tussen uw on-premises Windows-servers en uw Azure-bestandsshare.
• Het Azure File Sync-synchronisatieprotocol, een HTTPS-protocol dat wordt gebruikt voor het uitwisselen van synchronisatiekennis, namelijk de versiegegevens over de bestanden en mappen tussen eindpunten in uw omgeving. Dit protocol wordt ook gebruikt voor het uitwisselen van metagegevens over de bestanden en mappen, zoals tijdstempels en toegangsbeheerlijsten (ACL's).

Het koppelen van de Azure-bestandsdeling direct over SMB voor de Azure File Sync-agent is niet vereist en wordt afgeraden, omdat directe wijzigingen aan de bestandsdeling mogelijk tot wel 24 uur niet worden gedetecteerd. Om de file share direct te gebruiken zonder Azure File Sync, zie Azure Files netwerkoverzicht.

Hoewel voor Azure File Sync geen speciale netwerkconfiguratie is vereist, willen sommige klanten mogelijk geavanceerde netwerkinstellingen configureren om de volgende scenario's mogelijk te maken:

• Samenwerken met de proxyserverconfiguratie van uw organisatie.
• Open de on-premises firewall van uw organisatie naar de services Azure Files en Azure File Sync.
• Leid het verkeer van Azure Files en Azure File Sync via een ExpressRoute- of VPN-verbinding.

Proxyservers configureren

Azure File Sync kan volledig samenwerken met een proxyserver, maar je moet handmatig de proxy-endpointinstellingen voor je omgeving configureren met Azure File Sync. Gebruik PowerShell en de Azure File Sync server cmdlet Set-StorageSyncProxyConfiguration.

Zie Azure File Sync configureren met een proxyserver voor meer informatie over hoe u Azure File Sync kunt configureren met een proxyserver.

Firewalls en servicetags configureren

Om veiligheidsredenen isoleren veel organisaties hun bestandsservers van de meeste internetlocaties. Als u Azure File Sync in een dergelijke omgeving wilt gebruiken, moet u uw firewall zo configureren dat uitgaande toegang wordt toegestaan om Azure-services te selecteren. Als je firewall URL- of domeinfiltering ondersteunt, sta dan port 443 uitgaande toegang toe tot de vereiste cloud-endpoints die die specifieke Azure-diensten hosten. Als dit niet het probleem is, kunt u de IP-adresbereiken voor deze Azure-services ophalen via servicetags.

Azure File Sync vereist de IP-adresbereiken voor de volgende services, zoals geïdentificeerd door hun servicetags:

Als u Azure File Sync in Azure gebruikt, zelfs als deze zich in een andere regio bevindt, kunt u de naam van de servicetag rechtstreeks in uw netwerkbeveiligingsgroep gebruiken om verkeer naar die service toe te staan. Zie Netwerkbeveiligingsgroepen voor meer informatie.

Als je Azure File Sync on-premises gebruikt, kun je de service tag API gebruiken om specifieke IP-adresbereiken voor je firewall toestemmingslijst te krijgen. Er zijn twee manieren om deze informatie op te halen:

• De huidige lijst met IP-adresbereiken voor alle Azure-diensten die servicetags ondersteunen, wordt wekelijks gepubliceerd op het Microsoft Downloadcentrum in de vorm van een JSON-document. Elke Azure-cloud heeft een eigen JSON-document met de IP-adresbereiken die relevant zijn voor die cloud:
  • Openbaar in Azure
  • Azure US Government
  • Microsoft Azure beheerd door 21Vianet
  • Azure Duitsland
• Met de API voor servicetagdetectie (preview-versie) kunt u de huidige lijst met servicetags programmatisch ophalen. In de preview kan de service tag discovery API informatie teruggeven die minder actueel is dan informatie die afkomstig is van de JSON-documenten die zijn gepubliceerd op het Microsoft Downloadcentrum. U kunt het API-oppervlak gebruiken op basis van uw automatiseringsvoorkeur:
  • REST API
  • Azure PowerShell
  • Azure-CLI

Voor meer informatie over hoe u de service tag API gebruikt om de adressen van uw diensten op te halen, zie toelatingslijst voor Azure File Sync IP-adressen.

Verkeer tunnelen via een virtueel particulier netwerk of ExpressRoute

Sommige organisaties vereisen communicatie met Azure via een netwerktunnel, zoals een VPN of ExpressRoute, voor een extra beveiligingslaag of om ervoor te zorgen dat communicatie met Azure een deterministische route volgt.

Azure Files en Azure File Sync ondersteunen de volgende mechanismen om verkeer tussen uw on-premises servers en Azure te tunnelen:

• Azure VPN-gateway: Een VPN-gateway is een specifiek type virtuele netwerkgateway die je gebruikt om versleuteld verkeer te verzenden tussen een virtueel Azure-netwerk en een alternatieve locatie (zoals on-premises) via het internet. Een Azure VPN-gateway is een Azure-resource die je uitrolt in een resourcegroep naast een opslagaccount of andere Azure-resources. Omdat Azure File Sync bedoeld is om te worden gebruikt met een on-premises Windows-bestandsserver, gebruik je normaal gesproken een site-to-site VPN, hoewel het technisch gezien mogelijk is om een point-to-site VPN te gebruiken.

  Site-to-site VPN-verbindingen verbinden je Azure virtuele netwerk met het on-premises netwerk van je organisatie. Een site-to-site VPN-verbinding stelt je in staat om één keer een VPN-verbinding te configureren, voor een VPN-server of apparaat dat op het netwerk van je organisatie wordt gehost, in plaats van dit voor elk clientapparaat dat toegang nodig heeft tot je Azure-bestandsdeling. Voor de stappen om on-premises clients via een privé-eindpunt te verbinden met een bestandsdeling, zie Verbinding maken vanaf on-premises.

• ExpressRoute, waarmee u een gedefinieerde route (privéverbinding) kunt maken tussen Azure en uw on-premises netwerk dat niet via internet gaat. Omdat ExpressRoute een speciaal pad biedt tussen uw on-premises datacenter en Azure, kan ExpressRoute handig zijn wanneer netwerkprestaties een belangrijke overweging zijn. ExpressRoute is ook een goede optie wanneer een deterministisch pad naar uw resources in de cloud vereist is vanwege het beleid of de wettelijke vereisten van uw organisatie.

SMB over QUIC

Als poort 445 in jouw omgeving geblokkeerd is, kun je SMB gebruiken via QUIC als alternatief voor VPN of ExpressRoute. SMB via QUIC gebruikt het QUIC transportprotocol via poort 443, dat de meeste organisaties en internetproviders (ISP's) open hebben om HTTPS-verkeer te ondersteunen. Deze functie elimineert veel van de netwerkconfiguratie die normaal nodig is om op afstand toegang te krijgen tot een bestandsdeling via het openbare internet.

Om SMB te gebruiken over QUIC met Azure File Sync:

• Het Azure File Sync server-eindpunt moet draaien op een Windows Server Datacenter: Azure Edition virtual machine in Azure.
• Clients moeten Windows 11 of later draaien.

Voor installatie- en configuratiedetails, zie SMB over QUIC.

Privé-eindpunten voor Azure Files en Azure File Sync

Naast de standaard publieke endpoints die Azure Files en Azure File Sync bieden via het opslagaccount en de Storage Sync Service, kun je één of meer privé-endpoints voor elke resource configureren. Met deze optie kun je privé en veilig verbinding maken met Azure-bestandsshares vanuit on-premises via VPN of ExpressRoute en vanuit een virtueel Azure-netwerk. Wanneer u een privé-eindpunt voor een Azure-resource maakt, ontvangt deze een privé-IP-adres binnen de adresruimte van uw virtuele netwerk, zoals uw on-premises Windows-bestandsserver een IP-adres heeft binnen de toegewezen adresruimte van uw on-premises netwerk.

Een privé-eindpunt is gekoppeld aan een specifiek subnet van het virtuele Azure-netwerk. Opslagaccounts en Storage Sync Services kunnen privé-endpoints hebben in meer dan één virtueel netwerk.

Door gebruik te maken van private endpoints kun je:

• Maak veilig verbinding met je Azure-bronnen vanaf lokale netwerken door gebruik te maken van een VPN- of ExpressRoute-verbinding met private peering.
• Beveilig uw Azure-resources door de openbare eindpunten voor Azure Files en File Sync uit te schakelen. Het maken van een privé-eindpunt blokkeert standaard geen verbindingen met het openbare eindpunt.
• De beveiliging van het virtuele netwerk verbeteren door u in staat te stellen data-exfiltratie vanuit het virtuele netwerk (en over peeringsgrenzen heen) te blokkeren.

Om een privé-endpoint te creëren, zie Configure private endpoints for Azure File Sync.

Privé-eindpunten en DNS

Wanneer je een privé-endpoint aanmaakt, maakt of werkt Azure ook een private DNS-zone aan die overeenkomt met het privatelink subdomein. Voor openbare cloudregio’s zijn deze DNS-zones privatelink.file.core.windows.net voor Azure Files en privatelink.afs.azure.net voor Azure File Sync.

Wanneer je privé-endpoints aanmaakt voor een opslagaccount en een Storage Sync Service, maakt Azure A-records voor hen aan in hun respectievelijke private DNS-zones. Azure werkt ook de publieke DNS-vermelding bij zodat de reguliere volledig gekwalificeerde domeinnamen CNAME's zijn voor de betreffende privatelink naam. Deze configuratie maakt het mogelijk dat de volledig gekwalificeerde domeinnamen wijzen naar de IP-adressen van het privé-eindpunt wanneer de aanvrager zich binnen het virtuele netwerk bevindt en naar de IP-adressen van het publieke eindpunt wanneer de aanvrager zich buiten het virtuele netwerk bevindt.

Voor Azure Files is er voor elk privé-eindpunt één Fully Qualified Domain Name (die het patroon storageaccount.privatelink.file.core.windows.net volgt) toegewezen aan één privé-IP-adres voor het privé-eindpunt. Voor Azure File Sync heeft elk privé-eindpunt vier Fully Qualified Domain Names, voor de vier verschillende eindpunten die Azure File Sync beschikbaar maakt: beheer, synchronisatie (primair), synchronisatie (secundair) en bewaking. De volledig gekwalificeerde domeinnamen voor deze eindpunten volgen normaal gesproken de naam van de Storage Sync Service, tenzij de naam niet-ASCII-tekens bevat. Als bijvoorbeeld de naam van je Storage Sync Service mysyncservice is in de regio West US 2, zijn de equivalente eindpunten mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net en mysyncservicemonitoring.westus2.afs.azure.net. Elk privé-eindpunt voor een Storage Sync Service bevat vier verschillende IP-adressen.

Omdat uw Azure privé-DNS-zone is verbonden met het virtuele netwerk met het privé-eindpunt, kunt u de DNS-configuratie observeren door de cmdlet Resolve-DnsName aan te roepen vanuit PowerShell in een Azure VM (alternatief nslookup in Windows en Linux):

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

In dit voorbeeld lost het opslagaccount storageaccount.file.core.windows.net op naar het privé-IP-adres van het privé-eindpunt, dat 192.168.0.4 is.

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

Als je hetzelfde commando on-premises uitvoert, zie je dat dezelfde opslagaccountnaam wordt omgezet naar het publieke IP-adres van het opslagaccount;storageaccount.file.core.windows.net is een CNAME-record voor storageaccount.privatelink.file.core.windows.net, wat op zijn beurt een CNAME-record is voor de Azure-opslagcluster die het opslagaccount host:

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

Deze configuratie weerspiegelt het feit dat Azure Files en Azure File Sync zowel hun publieke eindpunten als één of meer private eindpunten per resource kunnen blootstellen. Om ervoor te zorgen dat de volledig gekwalificeerde domeinnamen voor uw resources worden omgezet naar de private endpoint-IP-adressen, moet u uw on-premises DNS-servers configureren. Je kunt deze taak op verschillende manieren volbrengen:

• Pas het hosts-bestand op je clients aan zodat de volledig gekwalificeerde domeinnamen voor je opslagaccounts en Storage Sync Services verwijzen naar de gewenste privé-IP-adressen. Gebruik deze aanpak niet voor productieomgevingen, want je moet deze wijzigingen aanbrengen bij elke client die toegang heeft tot je privé-endpoints. Wijzigingen aan je privé-endpoints of resources (verwijderingen, aanpassingen, enzovoort) worden niet automatisch afgehandeld.
• Maak DNS-zones aan op je on-premises servers voor privatelink.file.core.windows.net en privatelink.afs.azure.net met A-records voor je Azure-bronnen. Deze aanpak heeft als voordeel dat clients in je on-premises omgeving Azure-resources automatisch kunnen oplossen zonder elke client te hoeven configureren. Deze oplossing is echter vergelijkbaar met het wijzigen van het hosts-bestand, omdat wijzigingen niet worden weerspiegeld. Hoewel deze oplossing broos is, kan het de beste keuze zijn voor sommige omgevingen.
• De zones core.windows.net en afs.azure.net doorsturen van uw on-premises DNS-servers naar uw privé-DNS-zone van Azure. Je kunt de Azure private DNS-host bereiken via een speciaal IP-adres (168.63.129.16) dat alleen toegankelijk is binnen virtuele netwerken die gekoppeld zijn aan de Azure private DNS-zone. Om deze beperking te omzeilen, kun je binnen je virtuele netwerk extra DNS-servers gebruiken die core.windows.net en afs.azure.net doorsturen naar de overeenkomende Azure Private DNS-zones. Om deze configuratie te vereenvoudigen, biedt Microsoft PowerShell-cmdlets aan die DNS-servers automatisch in je virtuele Azure-netwerk uitrollen en naar wens configureren. Om te leren hoe je DNS-forwarding opzet, zie DNS configureren met Azure Files.

Versleuteling tijdens transport

Verbindingen die de Azure File Sync agent maakt met je Azure file share of Storage Sync Service zijn altijd versleuteld. Hoewel Azure-opslagaccounts een instelling hebben die het vereisen van versleuteling tijdens transport voor communicatie naar Azure Files (en de andere Azure-opslagdiensten die het opslagaccount beheert) uitschakelt, heeft het uitschakelen van deze instelling geen invloed op de encryptie van Azure File Sync wanneer het communiceert met Azure Files. Standaard is versleuteling in-transit ingeschakeld voor alle Azure-opslagaccounts.

Voor meer informatie over encryptie tijdens transit, zie FileREST-versleuteling tijdens transit.

Zie ook

• Een Azure File Sync-implementatie plannen
• Azure Files SYNC implementeren