Netzwerküberlegungen für Azure-Dateisynchronisierung

Dieser Artikel behandelt Netzwerkaspekte für Azure-Dateisynchronisierung, das Azure-Dateifreigaben auf lokalen Windows-Dateiservern zwischenspeichert. Für Netzwerküberlegungen bei einer direkten Azure Files-Bereitstellung siehe Azure Files Netzwerküberlegungen.

Das Netzwerken für Azure-Dateisynchronisierung umfasst zwei Azure-Objekte: einen Storage Sync Service (der registrierte Server und Synchronisierungsgruppen verwaltet) und ein Azure-Speicherkonto (das die Dateifreigaben hostet). In den meisten Fällen brauchst du keine spezielle Netzwerkkonfiguration über eine einfache Internetverbindung hinaus, aber du kannst Proxy-Server, Firewalls, VPN- oder ExpressRoute-Tunneling, private Endpunkte und SMB über QUIC konfigurieren.

Herstellen einer Verbindung zwischen Windows-Dateiserver und Azure mit Azure-Dateisynchronisierung

Um Azure Files und Azure-Dateisynchronisierung mit einem lokalen Windows-Dateiserver einzurichten und zu nutzen, benötigen Sie kein spezielles Netzwerk für Azure außer einer einfachen Internetverbindung. Um Azure-Dateisynchronisierung bereitzustellen, installieren Sie den Azure-Dateisynchronisierung Agent auf dem Windows-Dateiserver, den Sie mit Azure synchronisieren möchten. Der Azure-Dateisynchronisierung Agent erreicht die Synchronisation mit einer Azure-Dateifreigabe über zwei Kanäle:

• Das FileREST-Protokoll, ein HTTPS-basiertes Protokoll, das für den Zugriff auf Ihre Azure-Dateifreigabe verwendet wird. Weil das FileREST-Protokoll den HTTPS-Standard für die Datenübertragung verwendet, muss ausgehend auf Port 443 zugegriffen werden. Die Azure-Dateisynchronisierung verwendet nicht das SMB-Protokoll für die Datenübertragung zwischen Ihren lokalen Windows-Servern und Ihrer Azure-Dateifreigabe.
• Dem Protokoll der Azure-Dateisynchronisierung, einem HTTPS-basierten Protokoll, das für den Austausch von Synchronisierungswissen, d. h. den Versionsinformationen zu den Dateien und Ordner zwischen Endpunkten in Ihrer Umgebung, verwendet wird. Dieses Protokoll wird auch zum Austauschen von Metadaten wie Zeitstempel und Zugriffssteuerungslisten (Access Control Lists, ACLs) über die Dateien und Ordner verwendet.

Das Mounten der Azure-Dateifreigabe direkt über SMB für den Azure-Dateisynchronisierung-Agenten ist nicht erforderlich und wird davon abgeraten, da direkte Änderungen an der Dateifreigabe bis zu 24 Stunden nicht erkannt werden können. Um die Dateifreigabe direkt ohne Azure-Dateisynchronisierung zu verwenden, siehe Azure Files Netzwerkübersicht.

Obwohl die Azure-Dateisynchronisierung keine besondere Netzwerkkonfiguration erfordert, möchten einige Kunden möglicherweise erweiterte Netzwerkeinstellungen konfigurieren, um die folgenden Szenarien zu ermöglichen:

• Interoperabilität mit der Proxyserverkonfiguration Ihrer Organisation.
• Öffnen Sie die lokale Firewall Ihrer Organisation für die Dienste Azure Files und Azure-Dateisynchronisierung.
• Tunneln des Datenverkehrs von Azure Files und der Azure-Dateisynchronisierung über ExpressRoute oder eine VPN-Verbindung (Virtual Private Network, virtuelles privates Netzwerk).

Konfigurieren von Proxyservern

Azure-Dateisynchronisierung kann vollständig mit einem Proxyserver zusammenarbeiten, aber Sie müssen die Proxyendpunkteinstellungen für Ihre Umgebung in Azure-Dateisynchronisierung manuell konfigurieren. Verwenden Sie PowerShell und das Azure-Dateisynchronisierung-Server-Cmdlet Set-StorageSyncProxyConfiguration.

Weitere Informationen dazu, wie Azure-Dateisynchronisierung mit einem Proxyserver konfiguriert wird, finden Sie unter Konfigurieren von Azure-Dateisynchronisierung mit einem Proxyserver.

Konfigurieren von Firewalls und Diensttags

Aus Sicherheitsgründen isolieren viele Organisationen ihre Dateiserver von den meisten Internetstandorten. Um die Azure-Dateisynchronisierung in einer solchen Umgebung verwenden zu können, müssen Sie Ihre Firewall so konfigurieren, dass sie ausgehenden Zugriff auf ausgewählte Azure-Dienste zulässt. Wenn Ihre Firewall URL- oder Domain-Filterung unterstützt, erlauben Sie Port 443 ausgehenden Zugriff auf die erforderlichen Cloud-Endpunkte, die diese spezifischen Azure-Dienste hosten. Ist dies nicht der Fall, können Sie die IP-Adressbereiche für diese Azure-Dienste über Diensttags abrufen.

Die Azure-Dateisynchronisierung benötigt die IP-Adressbereiche für die folgenden Dienste, wie durch die Diensttags angegeben:

Wenn Sie die Azure-Dateisynchronisierung in Azure nutzen (selbst wenn dies in einer anderen Region geschieht), können Sie den Namen des Diensttags direkt in Ihrer Netzwerksicherheitsgruppe verwenden, um Datenverkehr zu diesem Dienst zuzulassen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

Wenn Sie Azure-Dateisynchronisierung in Ihrer lokalen Umgebung verwenden, können Sie mit der Diensttag-API bestimmte IP-Adressbereiche für die Zulassungsliste Ihrer Firewall abrufen. Es gibt zwei Methoden zum Abrufen dieser Informationen:

• Die aktuelle Liste der IP-Adressbereiche für alle Azure-Dienste, die Diensttags unterstützen, wird wöchentlich im Microsoft Download Center in Form eines JSON-Dokuments veröffentlicht. Es gibt für jede Azure-Cloud ein eigenes JSON-Dokument mit den IP-Adressbereichen, die für diese Cloud relevant sind:
  • Azure Public
  • Azure für die US-Regierung
  • Microsoft Azure, betrieben von 21Vianet
  • Azure Deutschland
• Die Diensttagermittlungs-API (Vorschauversion) ermöglicht das programmgesteuerte Abrufen der aktuellen Liste von Diensttags. In der Vorschauversion gibt die Diensttagermittlungs-API eventuell weniger aktuelle Informationen zurück, als in den im Microsoft Download Center veröffentlichten JSON-Dokumenten enthalten sind. Sie können je nach Ihren Automatisierungsvorlieben auch die API-Benutzeroberfläche verwenden:
  • REST-API
  • Azure PowerShell
  • Azure-Befehlszeilenschnittstelle

Weitere Informationen zur Verwendung der Diensttag-API zum Abrufen der Adressen Ihrer Dienste finden Sie unter Positivliste für Azure-Dateisynchronisierungs-IP-Adressen.

Tunneln von Datenverkehr über ein virtuelles privates Netzwerk oder über ExpressRoute

Einige Organisationen fordern, dass die Kommunikation mit Azure über einen Netzwerktunnel erfolgt, z. B. ein VPN oder ExpressRoute, um eine zusätzliche Sicherheitsebene zu gewährleisten oder sicherzustellen, dass die Kommunikation mit Azure einer deterministischen Route folgt.

Azure Files und die Azure-Dateisynchronisierung unterstützen die folgenden Mechanismen zum Tunneln von Datenverkehr zwischen Ihren lokalen Servern und Azure:

• Azure VPN Gateway: Ein VPN-Gateway ist eine spezielle Art von virtuellem Netzwerk-Gateway, das Sie verwenden, um verschlüsselten Datenverkehr zwischen einem virtuellen Azure-Netzwerk und einem alternativen Standort (wie z. B. vor Ort) über das Internet zu senden. Ein Azure VPN Gateway ist eine Azure-Ressource, die Sie in einer Ressourcengruppe zusammen mit einem Speicherkonto oder anderen Azure-Ressourcen bereitstellen. Da Azure-Dateisynchronisierung für einen lokalen Windows-Dateiserver gedacht ist, nutzt man normalerweise ein Site-to-Site-VPN, obwohl es technisch möglich ist, ein Point-to-Site-VPN zu nutzen.

  Site-to-Site-VPN-Verbindungen verbinden Ihr virtuelles Azure-Netzwerk mit dem lokalen Netzwerk Ihrer Organisation. Eine Site-to-Site-VPN-Verbindung ermöglicht es Ihnen, eine VPN-Verbindung einmal für einen VPN-Server oder ein Gerät zu konfigurieren, das im Netzwerk Ihrer Organisation gehostet wird, anstatt dies für jedes Client-Gerät zu tun, das auf Ihre Azure-Dateifreigabe zugreifen muss. Um die Bereitstellung einer Site-to-Site-VPN-Verbindung zu vereinfachen, siehe Configure a Site-to-Site VPN for use with Azure Files.

• ExpressRoute ermöglicht Ihnen die Erstellung einer definierten Route (private Verbindung) zwischen Azure und Ihrem lokalen Netzwerk, die nicht über das Internet läuft. Da ExpressRoute einen dedizierten Pfad zwischen Ihrem lokalen Rechenzentrum und Azure bereitstellt, kann dieser Dienst sehr nützlich sein, wenn die Netzwerkleistung ein wichtiger Aspekt ist. ExpressRoute ist auch dann eine gute Option, wenn die Richtlinie Ihrer Organisation oder gesetzliche Vorschriften einen deterministischen Pfad zu den Ressourcen in der Cloud erfordern.

SMB über QUIC

Wenn Port 445 in deiner Umgebung blockiert ist, kannst du SMB statt QUIC als Alternative zu VPN oder ExpressRoute verwenden. SMB über QUIC verwendet das QUIC-Transportprotokoll über Port 443, das die meisten Organisationen und Internetdienstanbieter (ISPs) offen haben, um HTTPS-Verkehr zu unterstützen. Diese Funktion eliminiert einen Großteil der Netzwerkkonfiguration, die normalerweise erforderlich ist, um auf eine Dateifreigabe aus der Ferne über das öffentliche Internet zuzugreifen.

Um SMB über QUIC mit Azure-Dateisynchronisierung zu verwenden:

• Der Azure-Dateisynchronisierung Server Endpunkt muss auf einer Windows Server Datacenter: Azure Edition Virtual Machine in Azure ausgeführt werden.
• Die Clients müssen Windows 11 oder später ausführen.

Für Einrichtungs- und Konfigurationsdetails siehe SMB over QUIC.

Private Endpunkte für Azure Files und Azure-Dateisynchronisierung

Zusätzlich zu den standardmäßigen öffentlichen Endpunkten, die Azure Files und die Azure-Dateisynchronisierung über das Speicherkonto und den Speichersynchronisierungsdienst bereitstellen, bieten sie die Möglichkeit, pro Ressource über einen oder mehrere private Endpunkte zu verfügen. Diese Option ermöglicht es Ihnen, über VPN oder ExpressRoute aus der lokalen Umgebung sowie innerhalb eines virtuellen Azure-Netzwerks eine private und sichere Verbindung mit Azure-Dateifreigaben herzustellen. Wenn Sie einen privaten Endpunkt für eine Azure-Ressource erstellen, erhält sie eine private IP-Adresse aus dem Adressraum Ihres virtuellen Netzwerks. Dies ist vergleichbar mit einem lokalen Windows-Dateiserver, der eine IP-Adresse aus dem dedizierten Adressraum Ihres lokalen Netzwerks erhält.

Ein privater Endpunkt ist einem bestimmten Subnetz des virtuellen Azure-Netzwerks zugeordnet. Speicherkonten und Speichersynchronisierungsdienste können über private Endpunkte in mehreren virtuellen Netzwerken verfügen.

Die Verwendung privater Endpunkte ermöglicht Folgendes:

• Herstellen einer sicheren Verbindung mit Ihren Azure-Ressourcen aus lokalen Netzwerken über eine VPN- oder ExpressRoute-Verbindung mit privatem Peering.
• Sichern Ihrer Azure-Ressourcen durch Deaktivieren der öffentlichen Endpunkte für Azure Files und Dateisynchronisierung. Durch die Erstellung eines privaten Endpunkts werden Verbindungen mit dem öffentlichen Endpunkt nicht standardmäßig blockiert.
• Erhöhen Sie die Sicherheit des virtuellen Netzwerks, indem Sie die Exfiltration von Daten aus dem virtuellen Netzwerk (und über die Peering-Grenzen hinweg) blockieren können.

Um einen privaten Endpunkt zu erstellen, siehe Configure private endpoints for Azure-Dateisynchronisierung.

Private Endpunkte und DNS

Wenn Sie einen privaten Endpunkt erstellen, erstellt oder aktualisiert Azure auch eine private DNS-Zone, die der privatelink Subdomain entspricht. Für öffentliche Cloudregionen sind diese DNS-Zonen privatelink.file.core.windows.net für Azure Files und privatelink.afs.azure.net für die Azure-Dateisynchronisierung.

Wenn Sie private Endpunkte für ein Speicherkonto und einen Storage Sync Service erstellen, erstellt Azure A-Datensätze für diese in ihren jeweiligen privaten DNS-Zonen. Azure aktualisiert außerdem den öffentlichen DNS-Eintrag so, dass die regulären, vollständig qualifizierten Domainnamen CNAMEs für den jeweiligen privatelink Namen sind. Diese Konfiguration ermöglicht es den vollständig qualifizierten Domainnamen, auf die IP-Adressen des privaten Endpunkts zu verweisen, wenn sich der Anforderer im virtuellen Netzwerk befindet, und auf die öffentlichen Endpunkt-IP-Adressen zu zeigen, wenn der Anforderer sich außerhalb des virtuellen Netzwerks befindet.

Bei Azure Files verfügt jeder private Endpunkt über einen einzelnen, dem Muster storageaccount.privatelink.file.core.windows.net folgenden vollqualifizierten Domänennamen, der einer privaten IP-Adresse für den privaten Endpunkt zugeordnet ist. Für die Azure-Dateisynchronisierung hat jeder private Endpunkt vier vollständig qualifizierte Domänennamen für die vier verschiedenen Endpunkte, die die Azure-Dateisynchronisierung verfügbar macht: Verwaltung, Synchronisierung (primär), Synchronisierung (sekundär) und Überwachung. Die vollqualifizierten Domänennamen für diese Endpunkte folgen normalerweise dem Namen des Speichersynchronisierungsdiensts, außer wenn der Name Nicht-ASCII-Zeichen enthält. Wenn der Name Ihres Speichersynchronisierungsdiensts beispielsweise mysyncservice in der Region „USA, Westen 2“ ist, wären die entsprechenden Endpunkte mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net und mysyncservicemonitoring.westus2.afs.azure.net. Jeder private Endpunkt für einen Speichersynchronisierungsdienst enthält vier verschiedene IP-Adressen.

Da Ihre private Azure-DNS-Zone mit dem virtuellen Netzwerk verbunden ist, das den privaten Endpunkt enthält, können Sie die DNS-Konfiguration beobachten, indem Sie das Resolve-DnsName Cmdlet von PowerShell in einer Azure-VM aufrufen (alternativ nslookup in Windows und Linux):

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

In diesem Beispiel wird das Speicherkonto storageaccount.file.core.windows.net in die private IP-Adresse des privaten Endpunkts (192.168.0.4) aufgelöst.

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

Wenn Sie den gleichen Befehl lokal ausführen, sehen Sie, dass der gleiche Speicherkontoname stattdessen in die öffentliche IP-Adresse des Speicherkontos aufgelöst wird. storageaccount.file.core.windows.net ist ein CNAME-Eintrag für storageaccount.privatelink.file.core.windows.net, was wiederum ein CNAME-Eintrag für den Azure-Speichercluster ist, von dem das Speicherkonto gehostet wird:

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

Diese Konfiguration spiegelt wider, dass Azure Files und Azure-Dateisynchronisierung sowohl ihre öffentlichen Endpunkte als auch einen oder mehrere private Endpunkte pro Ressource offenlegen können. Um sicherzustellen, dass die vollständig qualifizierten Domainnamen für Ihre Ressourcen auf die privaten Endpunkt-IP-Adressen aufgelöst werden, müssen Sie Ihre lokalen DNS-Server konfigurieren. Sie können diese Aufgabe auf verschiedene Arten erfüllen:

• Ändern Sie die Hostdatei auf Ihren Clients, um die vollqualifizierten Domänennamen für Ihre Speicherkonten und Speichersynchronisierungsdienste in die gewünschten privaten IP-Adressen aufzulösen. Bei Produktionsumgebungen wird davon dringend abgeraten, da Sie diese Änderungen für jeden Client vornehmen müssen, der auf Ihre privaten Endpunkte zugreifen muss. Änderungen an Ihren privaten Endpunkten/Ressourcen (Löschungen, Modifizierungen usw.) werden nicht automatisch behandelt.
• Erstellen von DNS-Zonen auf Ihren lokalen Servern für privatelink.file.core.windows.net und privatelink.afs.azure.net mit A-Datensätzen für Ihre Azure-Ressourcen. Dies hat den Vorteil, dass Clients in Ihrer lokalen Umgebung Azure-Ressourcen automatisch auflösen können und Sie nicht jeden einzelnen Client konfigurieren müssen. Diese Lösung ist jedoch ähnlich fehleranfällig wie das Ändern der Hosts-Datei, weil Änderungen nicht angezeigt werden. Für einige Umgebungen ist diese Lösung trotz ihrer Fehleranfälligkeit möglicherweise die beste Wahl.
• Weiterleiten der Zonen core.windows.net und afs.azure.net von Ihren lokalen DNS-Servern an Ihre private Azure-DNS-Zone. Der private Azure-DNS-Host ist über eine spezielle IP-Adresse (168.63.129.16) erreichbar, auf die nur innerhalb von virtuellen Netzwerken zugegriffen werden kann, die mit der privaten Azure-DNS-Zone verknüpft sind. Um diese Einschränkung zu umgehen, können Sie zusätzliche DNS-Server innerhalb Ihres virtuellen Netzwerks betreiben, die auf die entsprechenden privaten Azure-DNS-Zonen weiterleiten core.windows.netafs.azure.net. Um diese Konfiguration zu vereinfachen, stellt Microsoft PowerShell-CMDLETS bereit, die DNS-Server automatisch in Ihrem virtuellen Azure-Netzwerk bereitstellen und nach Belieben konfigurieren. Um zu erfahren, wie man DNS-Weiterleitung einrichtet, siehe DNS mit Azure Files konfigurieren.

Verschlüsselung während der Übertragung

Verbindungen, die zwischen dem Azure-Dateisynchronisierung-Agent und Ihrer Azure-Dateifreigabe oder einem Speichersynchronisierungsdienst hergestellt werden, sind immer verschlüsselt. Obwohl Azure-Speicherkonten über eine Einstellung zum Deaktivieren der Voraussetzung der Verschlüsselung während der Übertragung für die Kommunikation mit Azure Files (und den anderen Azure-Speicherdiensten, die über das Speicherkonto verwaltet werden) verfügen, wirkt sich das Deaktivieren dieser Einstellung nicht auf die Verschlüsselung der Azure-Dateisynchronisierung bei der Kommunikation mit Azure Files aus. Standardmäßig ist in allen Azure-Speicherkonten die Verschlüsselung während der Übertragung aktiviert.

Weitere Informationen zur Verschlüsselung während des Transits finden Sie unter Require Secure Transfer in Azure Storage.

Siehe auch

• Plan für eine Azure-Dateisynchronisierung Bereitstellung
• Bereitstellen der Azure-Dateisynchronisierung