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 u azure File Sync on-premises gebruikt, kunt u de servicetag-API gebruiken om specifieke IP-adresbereiken op te halen voor de acceptatielijst van uw firewall. Er zijn twee manieren om deze informatie op te halen:

• De huidige lijst met IP-adresbereiken voor alle Azure-services die servicetags ondersteunen, wordt wekelijks in het Microsoft Downloadcentrum gepubliceerd 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-versie kan de API voor servicetagdetectie informatie retourneren die minder actueel is dan informatie die wordt geretourneerd uit de JSON-documenten die in het Microsoft Downloadcentrum worden gepubliceerd. U kunt het API-oppervlak gebruiken op basis van uw automatiseringsvoorkeur:
  • REST API
  • Azure PowerShell
  • Azure-CLI

Zie Allowlist voor IP-adressen van Azure File Sync voor meer informatie over het gebruik van de servicetag-API om de adressen van uw services op te halen.

Verkeer tunnelen via een virtueel particulier netwerk of ExpressRoute

Voor sommige organisaties is communicatie met Azure vereist om een netwerktunnel, zoals een VPN of ExpressRoute, te doorlopen voor een extra beveiligingslaag of om ervoor te zorgen dat de 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. Om de implementatie van een site-to-site VPN-verbinding te vereenvoudigen, zie Configureer een Site-to-Site VPN voor gebruik met Azure Files.

• 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 openbare eindpunten die Azure Files en Azure File Sync bieden via het opslagaccount en de opslagsynchronisatieservice, bieden ze de mogelijkheid om een of meer privé-eindpunten per resource te hebben. 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 opslagsynchronisatieservices kunnen privé-eindpunten hebben in meer dan één virtueel netwerk.

Door gebruik te maken van privé-eindpunten kunt u het volgende doen:

• Maak veilig verbinding met uw Azure-resources vanuit on-premises netwerken met behulp van een VPN- of ExpressRoute-verbinding met persoonlijke 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 opslagsynchronisatieservice, tenzij de naam niet-ASCII-tekens bevat. Als de naam van uw opslagsynchronisatieservice bijvoorbeeld mysyncservice is in de regio VS - west 2, zouden de equivalente eindpunten mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net en mysyncservicemonitoring.westus2.afs.azure.net zijn. Elk privé-eindpunt voor een opslagsynchronisatieservice bevat vier afzonderlijke 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 wordt het opslagaccount storageaccount.file.core.windows.net omgezet in het privé-IP-adres van het privé-eindpunt. Dat is 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

Als u dezelfde opdracht uitvoert vanuit een on-premises locatie, ziet u dat dezelfde opslagaccountnaam wordt omgezet in het openbare IP-adres van het opslagaccount. storageaccount.file.core.windows.net is een CNAME-record voor storageaccount.privatelink.file.core.windows.net, die op zijn beurt weer een CNAME-record is voor het Azure-opslagcluster dat als host fungeert voor het opslagaccount:

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:

• Het hosts-bestand op uw clients wijzigen zodat de Fully Qualified Domain Names voor uw opslagaccounts en opslagsynchronisatieservices worden omgezet in de gewenste privé-IP-adressen. Dit wordt sterk afgeraden voor productieomgevingen, omdat u deze wijzigingen moet aanbrengen aan elke client die toegang nodig heeft tot uw privé-eindpunten. Wijzigingen in uw privé-eindpunten/resources (verwijderingen, wijzigingen, enzovoort) worden niet automatisch verwerkt.
• DNS-zones op uw on-premises servers maken voor privatelink.file.core.windows.net en privatelink.afs.azure.net met A-records voor uw Azure-resources. Dit heeft het voordeel dat clients in uw on-premises omgeving automatisch Azure-resources kunnen oplossen zonder dat elke client hoeft te worden geconfigureerd. 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. De privé-DNS-host van Azure kan worden bereikt via een speciaal IP-adres (168.63.129.16) dat alleen toegankelijk is in virtuele netwerken die zijn gekoppeld aan de privé-DNS-zone van Azure. 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 Azure-virtuele 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 worden gemaakt van de Azure File Sync-agent naar uw Azure-bestandsshare of opslagsynchronisatieservice, worden altijd versleuteld. Hoewel Azure-opslagaccounts een instelling hebben om versleuteling in transit uit te schakelen voor communicatie met Azure Files (en de andere Azure-opslagservices die buiten het opslagaccount worden beheerd), heeft het uitschakelen van deze instelling geen invloed op de versleuteling van Azure File Sync bij het communiceren met Azure Files. Standaard is versleuteling in-transit ingeschakeld voor alle Azure-opslagaccounts.

Voor meer informatie over versleuteling tijdens transit, zie 'require secure transfer in Azure storage.

Zie ook

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