Zagadnienia dotyczące sieci w usłudze Azure File Sync

Ten artykuł omawia kwestie sieciowe dla Azure File Sync, który buforuje udziały plików Azure na lokalnych serwerach plików Windows. Informacje dotyczące zagadnień sieciowych związanych z bezpośrednim wdrożeniem usługi Azure Files znajdują się w artykule Zagadnienia dotyczące sieci dla usługi Azure Files.

Obsługa sieci dla Azure File Sync obejmuje dwa obiekty platformy Azure: Storage Sync Service (który zarządza zarejestrowanymi serwerami i grupami synchronizacji) oraz konto magazynu Azure (na którym znajdują się udziały plików). W większości przypadków nie potrzebujesz specjalnej konfiguracji sieciowej poza podstawowym połączeniem internetowym, ale możesz skonfigurować serwery proxy, zapory sieciowe, tunelowanie VPN lub ExpressRoute, prywatne punkty końcowe oraz SMB przez QUIC.

Ważne

Funkcja Azure File Sync nie obsługuje routingu internetowego. Domyślna opcja routingu sieciowego, routing firmy Microsoft, jest obsługiwana przez funkcję Azure File Sync.

Łączenie serwera plików z systemem Windows z platformą Azure za pomocą usługi Azure File Sync

Aby skonfigurować i używać Azure Files oraz Azure File Sync z lokalnym serwerem plików Windows, nie potrzebujesz specjalnej sieci do Azure poza podstawowym połączeniem internetowym. Aby wdrożyć Azure File Sync, zainstaluj agenta Azure File Sync na serwerze plików Windows, który chcesz zsynchronizować z Azure. Agent usługi Azure File Sync realizuje synchronizację z udziałem plików platformy Azure za pomocą dwóch kanałów:

  • Protokół FileREST, który jest protokołem opartym na protokole HTTPS używanym do uzyskiwania dostępu do udziału plików platformy Azure. Ponieważ protokół FileREST używa standardowego protokołu HTTPS do transferu danych, port 443 musi być dostępny dla ruchu wychodzącego. Usługa Azure File Sync nie używa protokołu SMB do przesyłania danych między lokalnymi serwerami z systemem Windows a udziałem plików Azure.
  • Protokół synchronizacji usługi Azure File Sync, który jest protokołem opartym na protokole HTTPS używanym do wymiany wiedzy na temat synchronizacji, a mianowicie informacji o wersji plików i folderów między punktami końcowymi w danym środowisku. Ten protokół służy również do wymiany metadanych dotyczących plików i folderów, takich jak znaczniki czasu i listy kontroli dostępu (ACL).

Bezpośrednie montowanie udziału plików Azure przez SMB na potrzeby agenta Azure File Sync nie jest wymagane i jest odradzane, ponieważ bezpośrednie zmiany w udziale mogą pozostać niewykryte nawet przez 24 godziny. Aby korzystać bezpośrednio z udostępniania plików bez Azure File Sync, zobacz przegląd sieci Azure Files.

Mimo że usługa Azure File Sync nie wymaga żadnej specjalnej konfiguracji sieci, niektórzy klienci mogą chcieć skonfigurować zaawansowane ustawienia sieci, aby włączyć następujące scenariusze:

  • Współdziałaj z konfiguracją serwera proxy Twojej organizacji.
  • Otwórz zaporę lokalną organizacji dla usług Azure Files i Azure File Sync.
  • Tunelowanie ruchu usługi Azure Files i usługi Azure File Sync przez połączenie ExpressRoute lub połączenie sieci VPN.

Konfigurowanie serwerów proxy

Azure File Sync może w pełni współpracować z serwerem proxy, ale musisz ręcznie skonfigurować ustawienia punktu końcowego proxy dla swojego środowiska za pomocą Azure File Sync. Użyj PowerShell oraz Azure File Sync server cmdlet Set-StorageSyncProxyConfiguration.

Aby uzyskać więcej informacji na temat konfigurowania usługi Azure File Sync z serwerem proxy, zobacz Konfigurowanie usługi Azure File Sync z serwerem proxy.

Konfigurowanie zapór i tagów usług

Ze względów bezpieczeństwa wiele organizacji izoluje swoje serwery plików od większości lokalizacji internetowych. Aby używać usługi Azure File Sync w takim środowisku, należy skonfigurować zaporę, aby zezwolić na dostęp wychodzący do wybranych usług platformy Azure. Jeśli Twoja zapora obsługuje filtrowanie URL lub domeny, pozwól portowi 443 na dostęp wychodzący do wymaganych punktów końcowych chmury, które hostują te konkretne usługi Azure. Jeśli tak nie jest, możesz pobrać zakresy adresów IP dla tych usług platformy Azure za pomocą tagów usługi.

Usługa Azure File Sync wymaga zakresów adresów IP dla następujących usług, zgodnie z ich tagami usług:

Usługa Opis Tag usługi
Azure File Sync Usługa Azure File Sync, reprezentowana przez obiekt Storage Sync Service, odpowiada za podstawowy mechanizm synchronizacji danych między udziałem plików Azure a serwerem plików systemu Windows. StorageSyncService
Azure Files Wszystkie dane zsynchronizowane przez Azure File Sync są przechowywane w udziale plików Azure. Pliki zmienione na serwerach plików systemu Windows są replikowane do udziału plików platformy Azure, a pliki warstwowe na lokalnym serwerze plików są bezproblemowo pobierane, gdy użytkownik żąda ich. Storage
Azure Resource Manager Usługa Azure Resource Manager to interfejs zarządzania dla platformy Azure. Wszystkie wywołania zarządzania, w tym rejestracja serwera usługi Azure File Sync i bieżące zadania serwera synchronizacji, są wykonywane za pośrednictwem usługi Azure Resource Manager. AzureResourceManager
Microsoft Entra ID Microsoft Entra ID (dawniej Azure AD) zawiera tożsamości użytkowników wymagane do autoryzacji rejestracji serwera w usłudze Storage Sync Service oraz nazwy główne usług wymagane, aby usługa Azure File Sync była upoważniona do uzyskiwania dostępu do zasobów w chmurze. AzureActiveDirectory

Jeśli używasz usługi Azure File Sync na platformie Azure, nawet jeśli znajdujesz się w innym regionie, możesz użyć nazwy tagu usługi bezpośrednio w sieciowej grupie zabezpieczeń, aby zezwolić na ruch do tej usługi. Aby dowiedzieć się więcej, zobacz Sieciowe grupy zabezpieczeń.

Jeśli używasz programu Azure File Sync w środowisku lokalnym, możesz użyć interfejsu API tagów usług, aby uzyskać określone zakresy adresów IP na liście dozwolonych adresów zapory. Istnieją dwie metody uzyskiwania tych informacji:

Aby dowiedzieć się więcej o tym, jak używać interfejsu API tagów usług do pobierania adresów swoich usług, zobacz Lista dozwolonych adresów IP usługi Azure File Sync.

Tunelowanie ruchu za pośrednictwem wirtualnej sieci prywatnej lub usługi ExpressRoute

Niektóre organizacje wymagają komunikacji z platformą Azure w celu przejścia przez tunel sieciowy, na przykład sieci VPN lub usługi ExpressRoute, w celu zapewnienia dodatkowej warstwy zabezpieczeń lub zapewnienia komunikacji z platformą Azure zgodnie z trasą deterministyczną.

Usługi Azure Files i Azure File Sync obsługują następujące mechanizmy tunelowania ruchu między serwerami lokalnymi i platformą Azure:

  • Azure VPN Gateway: Brama VPN to specyficzny typ wirtualnej bramy, której używasz do przesyłania zaszyfrowanego ruchu między siecią Azure a alternatywną lokalizacją (np. lokalną) przez internet. Azure VPN Gateway to zasób Azure, który wdrażasz w grupie zasobów obok konta pamięci masowej lub innych zasobów Azure. Ponieważ Azure File Sync jest przeznaczony do użytku z lokalnym serwerem plików z systemem Windows, zazwyczaj używa się sieci VPN typu site-to-site, chociaż technicznie możliwe jest użycie sieci VPN typu point-to-site.

    Połączenia VPN między lokalizacjami łączą Twoją sieć wirtualną Azure z siecią lokalną Twojej organizacji. Połączenie VPN site-to-site pozwala skonfigurować połączenie VPN raz, dla serwera VPN lub urządzenia hostowanego w sieci organizacji, zamiast robić to dla każdego urządzenia klienta, które musi uzyskać dostęp do udostępnienia plików Azure. Aby uprościć wdrożenie połączenia VPN site-to-site, zobacz Configure a Site-to-Site VPN for use with Azure Files.

  • Usługa ExpressRoute, która umożliwia utworzenie zdefiniowanej trasy (połączenia prywatnego) między platformą Azure i siecią lokalną, która nie przechodzi przez Internet. Ponieważ usługa ExpressRoute zapewnia dedykowaną ścieżkę między lokalnym centrum danych a platformą Azure, usługa ExpressRoute może być przydatna, gdy wydajność sieci jest kluczową kwestią. Usługa ExpressRoute jest również dobrym rozwiązaniem, gdy zasady lub wymagania prawne organizacji wymagają deterministycznej ścieżki do zasobów w chmurze.

SMB over QUIC (protokół dla udostępniania plików z użyciem QUIC)

Jeśli port 445 jest zablokowany w twoim środowisku, możesz użyć SMB przez QUIC jako alternatywę dla VPN lub ExpressRoute. SMB przez QUIC korzysta z protokołu transportowego QUIC przez port 443, który większość organizacji i dostawców usług internetowych (ISP) ma otwarty, aby obsługiwać ruch HTTPS. Ta funkcja eliminuje większość konfiguracji sieciowej zwykle wymaganej do zdalnego dostępu do udostępniania plików przez publiczny internet.

Aby używać SMB over QUIC w usłudze Azure File Sync:

  • Endpoint serwera Azure File Sync musi działać na wirtualnej maszynie Windows Server: Azure Edition w Azure.
  • Klienci muszą korzystać z Windows 11 lub nowszych.

Szczegółowe informacje dotyczące instalacji i konfiguracji można znaleźć w artykule SMB over QUIC.

Prywatne punkty końcowe dla Azure Files i Azure File Sync

Oprócz domyślnych publicznych punktów końcowych, które usługi Azure Files i Azure File Sync udostępniają za pośrednictwem konta magazynu i usługi Storage Sync Service, oferują one również możliwość skonfigurowania co najmniej jednego prywatnego punktu końcowego dla każdego zasobu. Ta opcja umożliwia prywatne i bezpieczne łączenie się z udziałami plików Azure ze środowiska lokalnego przy użyciu sieci VPN lub ExpressRoute oraz z poziomu sieci wirtualnej platformy Azure. Podczas tworzenia prywatnego punktu końcowego dla zasobu platformy Azure pobiera prywatny adres IP z przestrzeni adresowej sieci wirtualnej, podobnie jak lokalny serwer plików systemu Windows ma adres IP w dedykowanej przestrzeni adresowej sieci lokalnej.

Pojedynczy prywatny punkt końcowy jest skojarzony z określoną podsiecią sieci wirtualnej platformy Azure. Konta magazynu i usługi synchronizacji magazynu mogą mieć prywatne punkty końcowe w więcej niż jednej sieci wirtualnej.

Korzystanie z prywatnych punktów końcowych umożliwia:

  • Bezpiecznie nawiąż połączenie z zasobami platformy Azure z sieci lokalnych przy użyciu połączenia sieci VPN lub usługi ExpressRoute z prywatną komunikacją równorzędną.
  • Zabezpiecz zasoby platformy Azure, wyłączając publiczne punkty końcowe dla usług Azure Files i File Sync. Domyślnie tworzenie prywatnego punktu końcowego nie blokuje połączeń z publicznym punktem końcowym.
  • Zwiększ bezpieczeństwo sieci wirtualnej, umożliwiając blokowanie eksfiltracji danych z sieci wirtualnej (oraz granic połączeń równorzędnych).

Aby utworzyć prywatny endpoint, zobacz Configure private endpoints for Azure File Sync.

Prywatne punkty końcowe i system DNS

Gdy tworzysz prywatny punkt końcowy, Azure tworzy lub aktualizuje także prywatną strefę DNS odpowiadającą subdomenieprivatelink. W przypadku regionów chmury publicznej te strefy DNS są privatelink.file.core.windows.net przeznaczone dla usługi Azure Files i privatelink.afs.azure.net usługi Azure File Sync.

Uwaga

W tym artykule jest używany sufiks DNS konta magazynu dla regionów publicznych platformy Azure. core.windows.net Dotyczy to również chmur suwerennych platformy Azure, takich jak chmura azure US Government i platforma Microsoft Azure obsługiwana przez chmurę 21Vianet — wystarczy zastąpić odpowiednie sufiksy dla danego środowiska.

Gdy tworzysz prywatne endpointy dla konta pamięci i usługi synchronizacji danych, Azure tworzy dla nich rekordy A w ich odpowiednich strefach DNS. Azure aktualizuje także publiczny rekord DNS w taki sposób, że standardowe w pełni kwalifikowane nazwy domenowe są rekordami CNAME wskazującymi odpowiednią nazwę privatelink. Ta konfiguracja pozwala w pełni kwalifikowanym nazwam domen wskazywać prywatne adresy IP punktów końcowych, gdy wnioskodawca znajduje się w sieci wirtualnej, oraz wskazywać publiczne adresy IP punktów końcowych, gdy wnioskodawca znajduje się poza siecią wirtualną.

W przypadku usługi Azure Files każdy prywatny punkt końcowy ma jedną w pełni kwalifikowaną nazwę domeny, zgodnie ze wzorcem storageaccount.privatelink.file.core.windows.net, zamapowany na jeden prywatny adres IP dla prywatnego punktu końcowego. W przypadku usługi Azure File Sync każdy prywatny punkt końcowy ma cztery w pełni kwalifikowane nazwy domen, dla czterech różnych punktów końcowych udostępnianych przez usługę Azure File Sync: zarządzanie, synchronizacja (podstawowa), synchronizacja (pomocnicza) i monitorowanie. W pełni kwalifikowane nazwy domenowe dla tych punktów końcowych będą zwykle oparte na nazwie usługi Storage Sync Service, chyba że nazwa zawiera znaki spoza zestawu ASCII. Na przykład jeśli nazwa usługi Storage Sync Service to mysyncservice w regionie West US 2, odpowiadające punkty końcowe to mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net i mysyncservicemonitoring.westus2.afs.azure.net. Każdy prywatny punkt końcowy dla usługi synchronizacji magazynu będzie zawierać cztery odrębne adresy IP.

Ponieważ prywatna strefa DNS Azure jest połączona z siecią wirtualną zawierającą prywatny punkt końcowy, możesz obserwować konfigurację DNS, wywołując polecenie cmdlet Resolve-DnsName z programu PowerShell na maszynie wirtualnej Azure (alternatywnie nslookup w Windows i Linux):

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

W tym przykładzie konto magazynu storageaccount.file.core.windows.net jest rozpoznawane na prywatny adres IP prywatnego punktu końcowego, którym jest 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

Jeśli uruchomisz to samo polecenie ze środowiska lokalnego, zobaczysz, że ta sama nazwa konta magazynu wskazuje zamiast tego na publiczny adres IP konta magazynu; storageaccount.file.core.windows.net to rekord CNAME dla storageaccount.privatelink.file.core.windows.net, który z kolei jest rekordem CNAME dla klastra usługi Azure Storage hostującego to konto magazynu:

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

Ta konfiguracja odzwierciedla fakt, że Azure Files i Azure File Sync mogą udostępniać zarówno swoje publiczne punkty końcowe, jak i jeden lub więcej prywatnych punktów końcowych na zasób. Aby mieć pewność, że w pełni kwalifikowane nazwy domenowe Twoich zasobów będą wskazywać adresy IP prywatnych punktów końcowych, musisz skonfigurować lokalne serwery DNS w środowisku lokalnym. Możesz to zadanie wykonać na kilka sposobów:

  • Modyfikowanie pliku hosts na klientach, aby w pełni kwalifikowane nazwy domenowe kont magazynu danych i usług Storage Sync były rozpoznawane jako żądane prywatne adresy IP. Jest to zdecydowanie odradzane w środowiskach produkcyjnych, ponieważ należy wprowadzić te zmiany do każdego klienta, który musi uzyskać dostęp do prywatnych punktów końcowych. Zmiany w prywatnych punktach końcowych/zasobach (usunięcia, modyfikacje itp.) nie będą automatycznie obsługiwane.
  • Tworzenie stref DNS na serwerach lokalnych dla privatelink.file.core.windows.net i privatelink.afs.azure.net przy użyciu rekordów A dla zasobów platformy Azure. Ma to zaletę, że klienci w środowisku lokalnym będą mogli automatycznie rozwiązywać problemy z zasobami platformy Azure bez konieczności konfigurowania każdego klienta. Jednak to rozwiązanie jest równie podatne na problemy przy modyfikowaniu pliku hosts, ponieważ zmiany nie są uwzględniane. Chociaż to rozwiązanie jest kruche, może to być najlepszy wybór dla niektórych środowisk.
  • Przekieruj strefy core.windows.net i afs.azure.net z lokalnych serwerów DNS do prywatnej strefy DNS platformy Azure. Prywatny host DNS platformy Azure można uzyskać za pośrednictwem specjalnego adresu IP (168.63.129.16), który jest dostępny tylko w sieciach wirtualnych połączonych z prywatną strefą DNS platformy Azure. Aby obejść to ograniczenie, możesz uruchomić dodatkowe serwery DNS w swojej sieci wirtualnej, które przekierowują core.windows.net i afs.azure.net do odpowiednich prywatnych stref DNS Azure. Aby uprościć tę konfigurację, Microsoft udostępnia cmdlets PowerShell, które automatycznie wdrażają serwery DNS w Twojej wirtualnej sieci Azure i konfigurują je według potrzeb. Aby dowiedzieć się, jak skonfigurować przekierowanie DNS, zobacz Konfiguruj DNS z Azure Files.

Szyfrowanie podczas transferu

Połączenia nawiązywane przez agenta usługi Azure File Sync z udziałem plików Azure lub usługą Storage Sync Service są zawsze szyfrowane. Mimo że konta usługi Azure Storage mają ustawienie wyłączające wymaganie szyfrowania podczas przesyłania w celu komunikacji z usługą Azure Files (i innymi usługami usługi Azure Storage zarządzanymi poza kontem magazynu), wyłączenie tego ustawienia nie wpłynie na szyfrowanie usługi Azure File Sync podczas komunikacji z usługą Azure Files. Domyślnie wszystkie konta usługi Azure Storage mają włączone szyfrowanie podczas przesyłania.

Więcej informacji o szyfrowaniu podczas transportu można znaleźć w artykule "wymagaj bezpiecznego transferu w pamięci Azure".

Zobacz też

  • Last updated on