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

Artykuł
11/06/2024

Możesz nawiązać połączenie z udziałem plików platformy Azure na dwa sposoby:

Dostęp do udziału bezpośrednio za pośrednictwem protokołów SMB lub FileREST. Ten wzorzec dostępu jest używany głównie w celu wyeliminowania jak największej liczby serwerów lokalnych, jak to możliwe.
Utwórz pamięć podręczną udziału plików platformy Azure na serwerze lokalnym (lub maszynie wirtualnej platformy Azure) za pomocą usługi Azure File Sync i uzyskaj dostęp do danych udziału plików z serwera lokalnego przy użyciu wybranego protokołu (SMB, NFS, FTPS itp.). Ten wzorzec dostępu jest przydatny, ponieważ łączy najlepsze zarówno wydajność lokalną, jak i skalę chmury z usługami dodanymi wartościami, takimi jak Azure Backup.

Ten artykuł koncentruje się na drugim scenariuszu: jak skonfigurować sieć, gdy przypadek użycia wywołuje użycie usługi Azure File Sync do buforowania plików lokalnych, a nie bezpośredniego instalowania udziału plików platformy Azure za pośrednictwem protokołu SMB. Aby uzyskać więcej informacji na temat zagadnień dotyczących sieci dla wdrożenia usługi Azure Files, zobacz Zagadnienia dotyczące sieci usługi Azure Files.

Konfiguracja sieci dla usługi Azure File Sync obejmuje dwa różne obiekty platformy Azure: usługę synchronizacji magazynu i konto usługi Azure Storage. Konto magazynu to konstrukcja zarządzania, która reprezentuje udostępnioną pulę magazynu, w której można wdrożyć wiele udziałów plików, a także inne zasoby magazynu, takie jak obiekty blob lub kolejki. Usługa synchronizacji magazynu to konstrukcja zarządzania reprezentująca zarejestrowane serwery, które są serwerami plików systemu Windows z ustanowioną relacją zaufania z usługą Azure File Sync i grupami synchronizacji, które definiują topologię relacji synchronizacji.

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ć usług Azure Files i Azure File Sync z lokalnym serwerem plików systemu Windows, nie jest wymagana żadna specjalna sieć na platformie Azure poza podstawowym połączeniem internetowym. Aby wdrożyć usługę Azure File Sync, zainstaluj agenta usługi Azure File Sync na serwerze plików systemu Windows, który chcesz zsynchronizować z platformą Azure. Agent usługi Azure File Sync umożliwia synchronizację z udziałem plików platformy Azure za pośrednictwem 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 transferu danych między lokalnymi serwerami z systemem Windows i udziałem plików platformy 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).

Ponieważ usługa Azure Files oferuje bezpośredni dostęp do protokołu SMB w udziałach plików platformy Azure, klienci często zastanawiają się, czy muszą skonfigurować specjalną sieć w celu zainstalowania udziałów plików platformy Azure przy użyciu protokołu SMB dla agenta usługi Azure File Sync w celu uzyskania dostępu. Nie jest to wymagane i jest w rzeczywistości odradzane z wyjątkiem scenariuszy administratora, ze względu na brak szybkiego wykrywania zmian wprowadzonych bezpośrednio w udziale plików platformy Azure. Zmiany mogą nie zostać odnalezione przez więcej niż 24 godziny w zależności od rozmiaru i liczby elementów w udziale plików platformy Azure. Jeśli chcesz używać udziału plików platformy Azure bezpośrednio zamiast używać usługi Azure File Sync do buforowania w środowisku lokalnym, zobacz Omówienie sieci usługi 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łanie z konfiguracją serwera proxy organizacji.
Otwórz lokalną zaporę organizacji w usługach Azure Files i Azure File Sync.
Tuneluj ruch usługi Azure Files i azure File Sync za pośrednictwem połączenia usługi ExpressRoute lub wirtualnej sieci prywatnej (VPN).

Konfigurowanie serwerów proxy

Wiele organizacji używa serwera proxy jako pośrednika między zasobami w sieci lokalnej i zasobami spoza sieci, na przykład na platformie Azure. Serwery proxy są przydatne w przypadku wielu aplikacji, takich jak izolacja sieci i zabezpieczenia, monitorowanie i rejestrowanie. Usługa Azure File Sync może w pełni współdziałać z serwerem proxy, jednak należy ręcznie skonfigurować ustawienia punktu końcowego serwera proxy dla środowiska za pomocą usługi Azure File Sync. Należy to zrobić za pomocą programu PowerShell przy użyciu polecenia cmdlet Set-StorageSyncProxyConfigurationserwera usługi Azure File Sync.

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ługi

Wiele organizacji izoluje serwery plików od większości lokalizacji internetowych do celów bezpieczeństwa. 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. Można to zrobić, zezwalając na dostęp wychodzący na porcie 443 do wymaganych punktów końcowych chmury hostujących te konkretne usługi platformy Azure, jeśli zapora obsługuje adresy URL/domeny. 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 usługi synchronizacji magazynu, jest odpowiedzialna za podstawowe działanie synchronizacji danych między udziałem plików platformy Azure a serwerem plików systemu Windows.	`StorageSyncService`
Azure Files	Wszystkie dane synchronizowane za pośrednictwem usługi Azure File Sync są przechowywane w udziale plików platformy 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 podmioty zabezpieczeń użytkownika wymagane do autoryzowania rejestracji serwera w usłudze synchronizacji magazynu oraz jednostki usługi wymagane do autoryzowania dostępu do zasobów w chmurze przez usługę Azure File Sync.	`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 lokalnej usługi Azure File Sync, możesz użyć interfejsu API tagów usługi, aby uzyskać określone zakresy adresów IP dla listy dozwolonych zapory. Istnieją dwie metody uzyskiwania tych informacji:

Bieżąca lista zakresów adresów IP dla wszystkich tagów usługi obsługujących usługi platformy Azure 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:
Interfejs API odnajdywania tagów usługi (wersja zapoznawcza) umożliwia programowe pobieranie bieżącej listy tagów usługi. W wersji zapoznawczej interfejs API odnajdywania tagów usługi może zwrócić informacje, które są mniej aktualne niż informacje zwracane z dokumentów JSON publikowanych w Centrum pobierania Microsoft. Możesz użyć powierzchni interfejsu API na podstawie preferencji automatyzacji:

Aby dowiedzieć się więcej o sposobie używania interfejsu API tagów usługi do pobierania adresów usług, zobacz Allowlist for Azure File Sync IP addresses (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ą.

Podczas ustanawiania tunelu sieciowego między siecią lokalną a platformą Azure komunikacja równorzędna sieci lokalnej jest oparta na komunikacji równorzędnej z co najmniej jedną siecią wirtualną na platformie Azure. Sieć wirtualna lub sieć wirtualna jest podobna do tradycyjnej sieci, która będzie działać lokalnie. Podobnie jak konto usługi Azure Storage lub maszyna wirtualna platformy Azure, sieć wirtualna to zasób platformy Azure wdrożony w grupie zasobów.

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 sieci VPN to określony typ bramy sieci wirtualnej, która służy do wysyłania zaszyfrowanego ruchu między siecią wirtualną platformy Azure a alternatywną lokalizacją (taką jak lokalna) przez Internet. Usługa Azure VPN Gateway to zasób platformy Azure, który można wdrożyć w grupie zasobów po stronie konta magazynu lub innych zasobów platformy Azure. Ponieważ usługa Azure File Sync ma być używana z lokalnym serwerem plików systemu Windows, zwykle należy użyć sieci VPN typu lokacja-lokacja (S2S), chociaż technicznie można użyć sieci VPN typu punkt-lokacja (P2S).

Połączenia sieci VPN typu lokacja-lokacja (S2S) łączą sieć wirtualną platformy Azure i sieć lokalną organizacji. Połączenie sieci VPN S2S umożliwia jednokrotne skonfigurowanie połączenia sieci VPN dla serwera sieci VPN lub urządzenia hostowanego w sieci organizacji, a nie dla każdego urządzenia klienckiego, które musi uzyskać dostęp do udziału plików platformy Azure. Aby uprościć wdrażanie połączenia sieci VPN typu lokacja-lokacja, zobacz Konfigurowanie sieci VPN typu lokacja-lokacja (S2S) do użycia z usługą 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.

Prywatne punkty końcowe

Oprócz domyślnych publicznych punktów końcowych usług Azure Files i Azure File Sync udostępniają za pośrednictwem konta magazynu i usługi synchronizacji magazynu, zapewniają one opcję posiadania co najmniej jednego prywatnego punktu końcowego na zasób. Dzięki temu można prywatnie i bezpiecznie łączyć się z udziałami plików platformy Azure ze środowiska lokalnego przy użyciu sieci VPN lub usługi ExpressRoute i z 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ększenie bezpieczeństwa sieci wirtualnej przez umożliwienie blokowania eksfiltracji danych z sieci wirtualnej (i granic komunikacji równorzędnej).

Aby utworzyć prywatny punkt końcowy, zobacz Konfigurowanie prywatnych punktów końcowych dla usługi Azure File Sync.

Prywatne punkty końcowe i system DNS

Podczas tworzenia prywatnego punktu końcowego domyślnie tworzymy (lub aktualizujemy istniejącą) prywatną strefę DNS odpowiadającą privatelink poddomenie. 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.

Podczas tworzenia prywatnych punktów końcowych dla konta magazynu i usługi synchronizacji magazynu tworzymy dla nich rekordy A w odpowiednich prywatnych strefach DNS. Aktualizujemy również publiczny wpis DNS, tak aby regularne w pełni kwalifikowane nazwy domen to nazwy CAM Dla odpowiedniej privatelink nazwy. Dzięki temu w pełni kwalifikowane nazwy domen mogą wskazywać na prywatny adres IP punktu końcowego(es), gdy żądający znajduje się w sieci wirtualnej i wskazuje na publiczny adres IP punktu końcowego, gdy żądający 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 zwykle będą zgodne z nazwą usługi synchronizacji magazynu, chyba że nazwa zawiera znaki inne niż ASCII. Jeśli na przykład nazwa usługi synchronizacji magazynu znajduje się mysyncservice w regionie Zachodnie stany USA 2, równoważne punkty końcowe to mysyncservicemanagement.westus2.afs.azure.net, , mysyncservicesyncp.westus2.afs.azure.netmysyncservicesyncs.westus2.afs.azure.neti 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 platformy Azure jest połączona z siecią wirtualną zawierającą prywatny punkt końcowy, możesz obserwować konfigurację DNS podczas wywoływania Resolve-DnsName polecenia cmdlet z programu PowerShell na maszynie wirtualnej platformy Azure (alternatywnie nslookup w systemach Windows i Linux):

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

W tym przykładzie konto storageaccount.file.core.windows.net magazynu jest rozpoznawane jako prywatny adres IP prywatnego punktu końcowego, który ma wartość 192.168.0.4.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     csostoracct.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 jest rozpoznawana jako publiczny adres IP konta magazynu. storageaccount.file.core.windows.net to rekord CNAME dla storageaccount.privatelink.file.core.windows.netprogramu , który z kolei jest rekordem CNAME klastra usługi Azure Storage hostujące 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

Odzwierciedla to fakt, że usługi Azure Files i Azure File Sync mogą uwidaczniać zarówno publiczne punkty końcowe, jak i co najmniej jeden prywatny punkt końcowy na zasób. Aby upewnić się, że w pełni kwalifikowane nazwy domen dla zasobów są rozpoznawane jako prywatne adresy IP punktów końcowych, należy zmienić konfigurację na lokalnych serwerach DNS. Można to zrobić na kilka sposobów:

Modyfikując plik hostów na klientach, aby w pełni kwalifikowane nazwy domen dla kont magazynu i usług synchronizacji magazynu rozpoznawały żą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 podobnie kruche, aby zmodyfikować plik hostów, ponieważ zmiany nie są odzwierciedlane. Chociaż to rozwiązanie jest kruche, może to być najlepszy wybór dla niektórych środowisk.
core.windows.net Przekaż strefy 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 sieci wirtualnej, które będą przekazywane core.windows.net i afs.azure.net do równoważnych prywatnych stref DNS platformy Azure. Aby uprościć tę konfigurację, udostępniliśmy polecenia cmdlet programu PowerShell, które będą automatycznie wdrażać serwery DNS w sieci wirtualnej platformy Azure i konfigurować je zgodnie z potrzebami. Aby dowiedzieć się, jak skonfigurować przekazywanie DNS, zobacz Konfigurowanie usługi DNS przy użyciu usługi Azure Files.

Szyfrowanie podczas transferu

Połączenia wykonywane z agenta usługi Azure File Sync do udziału plików platformy Azure lub usługi synchronizacji magazynu 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.

Aby uzyskać więcej informacji na temat szyfrowania podczas przesyłania, zobacz wymaganie bezpiecznego transferu w usłudze Azure Storage.

Udostępnij za pośrednictwem