zagadnienia dotyczące sieci Azure File Sync

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

  • Uzyskiwanie dostępu 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.
  • Tworzenie pamięci podręcznej udziału plików platformy Azure na serwerze lokalnym (lub maszynie wirtualnej platformy Azure) przy użyciu Azure File Sync i uzyskiwanie dostępu do danych udziału plików z serwera lokalnego przy użyciu wybranego protokołu (SMB, NFS, FTPS itp.) w twoim przypadku użycia. Ten wzorzec dostępu jest przydatny, ponieważ łączy najlepsze zarówno lokalne usługi wydajności, jak i skalowania w chmurze oraz bezserwerowe dołączane usługi, takie jak Azure Backup.

W tym artykule opisano sposób konfigurowania sieci, gdy przypadek użycia wywołuje metodę używania 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 Azure Files, zobacz zagadnienia dotyczące sieci Azure Files.

Konfiguracja sieci dla 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 reprezentująca udostępnioną pulę magazynu, w której można wdrożyć wiele udziałów plików, a także inne zasoby magazynu, takie jak kontenery obiektów blob lub kolejki. Usługa synchronizacji magazynu to konstrukcja zarządzania, która reprezentuje zarejestrowane serwery plików systemu Windows z ustanowioną relacją zaufania z Azure File Sync i grupami synchronizacji, które definiują topologię relacji synchronizacji.

Ważne

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

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

Aby skonfigurować i używać 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ć Azure File Sync, zainstaluj agenta Azure File Sync na serwerze plików systemu Windows, który chcesz zsynchronizować z platformą Azure. Agent 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, tylko port 443 musi być dostępny dla ruchu wychodzącego. 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 Azure File Sync, który jest protokołem opartym na protokole HTTPS używanym do wymiany wiedzy na temat synchronizacji, tj. 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 w środowisku, takich jak znaczniki czasu i listy kontroli dostępu (ACL).

Ponieważ 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 Azure File Sync w celu uzyskania dostępu. Nie jest to wymagane i nie jest to wymagane, 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 ponad 24 godziny w zależności od rozmiaru i liczby elementów w udziale plików platformy Azure). Jeśli chcesz bezpośrednio używać udziału plików platformy Azure, tj. nie używaj Azure File Sync do buforowania lokalnie, zobacz omówienie sieci Azure Files.

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

  • Współdziałanie z konfiguracją serwera proxy w organizacji.
  • Otwórz lokalną zaporę organizacji w usługach Azure Files i Azure File Sync.
  • Tunel Azure Files i ruch Azure File Sync za pośrednictwem usługi ExpressRoute lub połączenia sieci VPN.

Konfigurowanie serwerów proxy

Wiele organizacji używa serwera proxy jako pośrednika między zasobami wewnątrz sieci lokalnej i zasobów spoza sieci, takich jak na platformie Azure. Serwery proxy są przydatne w przypadku wielu aplikacji, takich jak izolacja sieci i zabezpieczenia, oraz monitorowanie i rejestrowanie. 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 przy użyciu Azure File Sync. Należy to zrobić za pomocą programu PowerShell przy użyciu polecenia cmdlet Set-StorageSyncProxyConfigurationserwera Azure File Sync .

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

Konfigurowanie zapór i tagów usługi

Wiele organizacji izoluje serwery plików z większości lokalizacji internetowych do celów bezpieczeństwa. Aby użyć 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 hostowania tych określonych usług 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.

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 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 Azure File Sync i trwające zadania serwera synchronizacji, są wykonywane za pośrednictwem usługi Azure Resource Manager. AzureResourceManager
Azure Active Directory Usługa Azure Active Directory lub Azure AD zawiera podmioty zabezpieczeń użytkownika wymagane do autoryzowania rejestracji serwera w usłudze synchronizacji magazynu oraz jednostki usługi wymagane do Azure File Sync autoryzacji dostępu do zasobów w chmurze. AzureActiveDirectory

Jeśli używasz 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 Azure File Sync lokalnie, możesz użyć interfejsu API tagu 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 usług pomocniczych 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 zwrócone z dokumentów JSON opublikowanych w centrum pobierania Microsoft. Powierzchnię interfejsu API można użyć na podstawie preferencji automatyzacji:

Aby dowiedzieć się więcej na temat używania interfejsu API tagów usługi do pobierania adresów usług, zobacz Allowlist for Azure File Sync IP address (Lista dozwolonych adresów IP Azure File Sync).

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

Niektóre organizacje wymagają komunikacji z platformą Azure, aby przejść przez tunel sieciowy, taki jak wirtualna sieć prywatna (VPN) lub ExpressRoute, aby zapewnić dodatkową warstwę zabezpieczeń lub zapewnić komunikację z platformą Azure zgodnie z trasą deterministyczną.

Podczas ustanawiania tunelu sieciowego między siecią lokalną a platformą Azure komunikacja równorzędna sieci lokalnej 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.

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

  • Azure VPN Gateway: Brama sieci VPN jest konkretnym typem 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) za pośrednictwem Internetu. 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ż Azure File Sync ma być używana z lokalnym serwerem plików systemu Windows, zwykle należy używać sieci VPN typu lokacja-lokacja (S2S), chociaż technicznie można używać 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 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 udostępnia 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 Azure Files i Azure File Sync zapewniają za pośrednictwem konta magazynu i usługi synchronizacji magazynu, zapewniają one opcję posiadania co najmniej jednego prywatnego punktu końcowego na zasób w celu prywatnego i bezpiecznego nawiązywania połączenia z udziałami plików platformy Azure ze środowiska lokalnego przy użyciu sieci VPN lub 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 sposób, w jaki lokalny serwer plików systemu Windows ma adres IP w dedykowanej przestrzeni adresowej sieci lokalnej.

Ważne

Aby używać prywatnych punktów końcowych w zasobie usługi synchronizacji magazynu, należy użyć agenta Azure File Sync w wersji 10.1 lub nowszej. Wersje agenta wcześniejsze niż 10.1 nie obsługują prywatnych punktów końcowych w usłudze synchronizacji magazynu. Wszystkie wcześniejsze wersje agenta obsługują prywatne punkty końcowe w zasobie konta magazynu.

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ą.
  • Zabezpieczanie zasobów platformy Azure przez wyłączenie publicznych punktów końcowych dla Azure Files i File Sync. Domyślnie utworzenie 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 Azure File Sync.

Prywatne punkty końcowe i system DNS

Podczas tworzenia prywatnego punktu końcowego domyślnie również 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 Azure Files i privatelink.afs.azure.net Azure File Sync.

Uwaga

W tym artykule użyto sufiksu DNS konta magazynu dla regionów publicznych platformy Azure. core.windows.net Ten komentarz dotyczy również chmur suwerennych platformy Azure, takich jak chmura Azure US Government i chmura Azure —Chiny — wystarczy zastąpić odpowiednie sufiksy dla twojego ś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, 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 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 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, które Azure File Sync uwidacznia: 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 usługi synchronizacji magazynu będzie zawierać 4 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 w systemach nslookup 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 jest rekordem CNAME dla storageaccount.privatelink.file.core.windows.netprogramu , który z kolei jest rekordem CNAME dla 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 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 zasobów są rozpoznawane jako prywatne adresy IP punktów końcowych, należy zmienić konfigurację na lokalnych serwerach DNS. Można to osiągnąć na kilka sposobów:

  • Modyfikowanie pliku hostów na klientach w celu ustawienia w pełni kwalifikowanych nazw domen dla kont magazynu i usług synchronizacji magazynu rozpoznawanych jako odpowiednie prywatne adresy IP. Jest to zdecydowanie odradzane w środowiskach produkcyjnych, ponieważ należy wprowadzić te zmiany do każdego klienta, który musi uzyskiwać dostęp do prywatnych punktów końcowych. Zmiany prywatnych punktów końcowych/zasobów (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ć zasoby platformy Azure bez konieczności konfigurowania każdego klienta, jednak to rozwiązanie jest podobnie kruche w celu modyfikowania pliku 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 Prześlij dalej 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żna 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 systemu DNS przy użyciu Azure Files.

Szyfrowanie podczas transferu

Połączenia z agenta 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 do komunikacji w celu Azure Files (i innych usług magazynu platformy Azure zarządzanych poza kontem magazynu), wyłączenie tego ustawienia nie wpłynie 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.

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

Zobacz też