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.

Łą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:

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 korzystasz z Azure File Sync lokalnie, możesz użyć API service tag, aby uzyskać konkretne zakresy adresów IP dla listy dozwolonych adresów w zaporze. Istnieją dwie metody uzyskiwania tych informacji:

• Aktualna lista zakresów adresów IP dla wszystkich usług Azure obsługujących tagi usług jest publikowana co tydzień w Centrum pobierania Microsoft w formie dokumentu JSON. Każda chmura platformy Azure ma własny dokument JSON z zakresami adresów IP istotnych dla tej chmury:
  • Publiczna platforma Azure
  • Wersja platformy Azure dla administracji USA
  • Platforma Microsoft Azure obsługiwana przez firmę 21Vianet
  • Azure (Niemcy)
• Interfejs API odnajdywania tagów usługi (wersja zapoznawcza) umożliwia programowe pobieranie bieżącej listy tagów usługi. W podglądzie API wyszukiwania tagów serwisowych może zwracać informacje mniej aktualne niż te z dokumentów JSON opublikowanych w Centrum pobierania Microsoft. Możesz użyć interfejsu API w zależności od preferowanego sposobu automatyzacji:
  • API REST
  • Azure PowerShell
  • Interfejs wiersza polecenia platformy Azure

Aby dowiedzieć się więcej o tym, jak korzystać z API tagów serwisowych do pobierania adresów Twoich usług, zobacz listę dozwolonych adresów IP Azure File Sync.

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

Niektóre organizacje wymagają, aby komunikacja z platformą Azure odbywała się przez tunel sieciowy, taki jak VPN lub ExpressRoute, jako dodatkową warstwę zabezpieczeń lub aby zapewnić, że komunikacja z platformą Azure odbywa się przewidywalną trasą.

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. Instrukcje dotyczące łączenia klientów lokalnych z udziałem plików za pośrednictwem prywatnego punktu końcowego znajdują się w sekcji Łączenie ze środowiska lokalnego.

• 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 Azure Files i Azure File Sync udostępniają poprzez konto pamięci i Storage Sync Service, możesz skonfigurować jeden lub więcej prywatnych punktów końcowych 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 Storage Sync Services mogą mieć prywatne punkty końcowe w więcej niż jednej sieci wirtualnej.

Korzystając z prywatnych punktów końcowych, możesz:

• Bezpiecznie łącz się z zasobami Azure z sieci lokalnych, korzystając z VPN lub połączenia ExpressRoute z prywatnym peeringiem.
• 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.

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 domen dla tych punktów końcowych są zwykle oparte na nazwie usługi Storage Sync Service, chyba że nazwa zawiera znaki spoza ASCII. Na przykład, jeśli nazwa usługi Storage Sync Service to mysyncservice w regionie West US 2, równoważne 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 usługi synchronizacji pamięci 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 storageaccount.file.core.windows.net pamięci masowej rozwiązuje się do prywatnego adresu 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 wykonasz to samo polecenie z lokalnego serwera, zobaczysz, że ta sama nazwa konta magazynowego rozwiązuje się na publiczny adres IP konta pamięci;storageaccount.file.core.windows.net jest rekordem CNAME dla storageaccount.privatelink.file.core.windows.net, który z kolei jest rekordem CNAME dla klastra Azure hostującego to konto:

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:

• Zmodyfikuj plik hostów na swoich klientach, aby w pełni kwalifikowane nazwy domen dla Twoich kont magazynowych i Storage Sync Services wskazywały na pożądane prywatne adresy IP. Nie stosuj tego podejścia w środowiskach produkcyjnych, ponieważ musisz wprowadzać te zmiany dla każdego klienta, który potrzebuje dostępu do Twoich prywatnych punktów końcowych. Zmiany w Twoich prywatnych punktach końcowych lub zasobach (usunięcia, modyfikacje itd.) nie są automatycznie obsługiwane.
• Twórz strefy DNS na swoich serwerach lokalnych dla privatelink.file.core.windows.net i privatelink.afs.azure.net z rekordami A dla zasobów Azure. Takie podejście ma tę zaletę, że klienci w środowisku lokalnym mogą automatycznie rozwiązać zasoby 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. Możesz dotrzeć do prywatnego hosta DNS Azure przez specjalny adres IP (168.63.129.16), dostępny tylko w sieciach wirtualnych powiązanych ze strefą prywatnego DNS 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, które agent Azure File Sync tworzy z twoim udziałem plików Azure lub usługą Storage Sync Service, są zawsze szyfrowane. Chociaż konta usługi Azure Storage mają ustawienie wyłączające wymóg szyfrowania w tranzycie dla komunikacji z Azure Files (oraz innymi usługami przechowywania Azure, którymi zarządza to konto), wyłączenie tego ustawienia nie wpływa na szyfrowanie Azure File Sync podczas komunikacji z 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 FileREST szyfrowanie podczas przesyłania.

Zobacz też

• Planowanie wdrożenia usługi Azure File Sync
• Wdrażanie usługi Azure File Sync