zagadnienia dotyczące sieci Azure Files
Dostęp do udziałów plików platformy Azure można uzyskać za pośrednictwem publicznego internetowego punktu końcowego dostępnego przez co najmniej jeden prywatny punkt końcowy w sieci lub buforując udział plików platformy Azure lokalnie przy użyciu Azure File Sync (tylko udziały plików SMB). W tym artykule opisano sposób konfigurowania Azure Files na potrzeby bezpośredniego dostępu za pośrednictwem publicznych i/lub prywatnych punktów końcowych. Aby dowiedzieć się, jak buforować lokalny udział plików platformy Azure przy użyciu Azure File Sync, zobacz Wprowadzenie do Azure File Sync.
Zalecamy zapoznanie się z tematem Planowanie wdrożenia Azure Files przed przeczytaniem tego przewodnika koncepcyjnego.
Bezpośrednie uzyskiwanie dostępu do udziału plików platformy Azure często wymaga dodatkowej myśli w odniesieniu do sieci:
Udziały plików SMB komunikują się za pośrednictwem portu 445, który wielu organizacji i dostawców usług internetowych (ISPS) blokuje ruch wychodzący (internet). Ta praktyka pochodzi ze starszych wskazówek dotyczących zabezpieczeń dotyczących przestarzałych i nie-internetowych bezpiecznych wersji protokołu SMB. Chociaż protokół SMB 3.x jest protokołem bezpiecznym z Internetu, zasady organizacji lub usługodawcy internetowego mogą nie być możliwe do zmiany. W związku z tym instalowanie udziału plików SMB często wymaga dodatkowej konfiguracji sieci do użycia poza platformą Azure.
Udziały plików NFS opierają się na uwierzytelnianiu na poziomie sieci i dlatego są dostępne tylko za pośrednictwem sieci z ograniczeniami. Korzystanie z udziału plików NFS zawsze wymaga pewnego poziomu konfiguracji sieci.
Konfigurowanie publicznych i prywatnych punktów końcowych dla Azure Files odbywa się w obiekcie zarządzania najwyższego poziomu dla Azure Files konta 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 platformy Azure, a także zasoby magazynu dla innych usług azure Storage, takich jak kontenery obiektów blob lub kolejki.
Ten film wideo jest przewodnikiem i pokazem dotyczącym bezpiecznego uwidaczniania udziałów plików platformy Azure bezpośrednio dla procesów roboczych i aplikacji informacyjnych w pięciu prostych krokach. Poniższe sekcje zawierają linki i dodatkowy kontekst do dokumentacji, do których odwołuje się film wideo.
Dotyczy
| Typ udziału plików | SMB | NFS |
|---|---|---|
| Udziały plików w warstwie Standardowa (GPv2), LRS/ZRS |  |
 |
| Udziały plików w warstwie Standardowa (GPv2), GRS/GZRS | |
|
| Udziały plików w warstwie Premium (FileStorage), LRS/ZRS | |
|
Bezpieczny transfer
Domyślnie konta usługi Azure Storage wymagają bezpiecznego transferu, niezależnie od tego, czy dane są dostępne za pośrednictwem publicznego lub prywatnego punktu końcowego. W przypadku Azure Files wymagane ustawienie bezpiecznego transferu jest wymuszane dla wszystkich protokołów dostępu do danych przechowywanych w udziałach plików platformy Azure, w tym SMB, NFS i FileREST. Możesz wyłączyć ustawienie wymaganego bezpiecznego transferu , aby zezwolić na niezaszyfrowany ruch. W Azure Portal można również zobaczyć to ustawienie oznaczone jako wymagające bezpiecznego transferu dla operacji interfejsu API REST.
Protokoły SMB, NFS i FileREST mają nieco inne zachowanie w odniesieniu do ustawienia wymaganego bezpiecznego transferu :
W przypadku włączenia bezpiecznego transferu na koncie magazynu wszystkie udziały plików SMB na tym koncie magazynu będą wymagały protokołu SMB 3.x z protokołem AES-128-CCM, AES-128-GCM lub AES-256-GCM, w zależności od dostępnych/wymaganych negocjacji szyfrowania między klientem SMB i Azure Files. Można przełączać, które algorytmy szyfrowania SMB są dozwolone za pośrednictwem ustawień zabezpieczeń protokołu SMB. Wyłączenie ustawienia wymaganego bezpiecznego transferu umożliwia instalowanie protokołu SMB 2.1 i SMB 3.x bez szyfrowania.
Udziały plików NFS nie obsługują mechanizmu szyfrowania, więc aby używać protokołu NFS do uzyskiwania dostępu do udziału plików platformy Azure, należy wyłączyć opcję Wymagaj bezpiecznego transferu dla konta magazynu.
Jeśli wymagany jest bezpieczny transfer, protokół FileREST może być używany tylko z protokołem HTTPS. PlikREST jest obecnie obsługiwany tylko w udziałach plików SMB.
Publiczny punkt końcowy
Publiczny punkt końcowy udziałów plików platformy Azure na koncie magazynu jest internetowym uwidoczniony punkt końcowy. Publiczny punkt końcowy jest domyślnym punktem końcowym konta magazynu, jednak w razie potrzeby można go wyłączyć.
Protokoły SMB, NFS i FileREST mogą używać publicznego punktu końcowego. Jednak każdy z nich ma nieco inne reguły dostępu:
Udziały plików SMB są dostępne z dowolnego miejsca na świecie za pośrednictwem publicznego punktu końcowego konta magazynu z szyfrowaniem SMB 3.x. Oznacza to, że uwierzytelnione żądania, takie jak żądania autoryzowane przez tożsamość logowania użytkownika, mogą bezpiecznie pochodzić z wewnątrz lub poza regionem świadczenia usługi Azure. Jeśli protokół SMB 2.1 lub SMB 3.x bez szyfrowania jest wymagany, należy spełnić dwa warunki:
- Ustawienie bezpiecznego transferu na koncie magazynu musi być wyłączone.
- Żądanie musi pochodzić z regionu świadczenia usługi Azure. Jak wspomniano wcześniej, zaszyfrowane żądania SMB są dozwolone z dowolnego miejsca, wewnątrz lub poza regionem świadczenia usługi Azure.
Udziały plików NFS są dostępne z publicznego punktu końcowego konta magazynu, jeśli i tylko wtedy, gdy publiczny punkt końcowy konta magazynu jest ograniczony do określonych sieci wirtualnych przy użyciu punktów końcowych usługi. Aby uzyskać dodatkowe informacje na temat punktów końcowych usługi, zobacz ustawienia zapory publicznego punktu końcowego.
PlikREST jest dostępny za pośrednictwem publicznego punktu końcowego. Jeśli wymagany jest bezpieczny transfer, akceptowane są tylko żądania HTTPS. Jeśli bezpieczny transfer jest wyłączony, żądania HTTP są akceptowane przez publiczny punkt końcowy niezależnie od źródła.
Ustawienia zapory publicznego punktu końcowego
Zapora konta magazynu ogranicza dostęp do publicznego punktu końcowego dla konta magazynu. Za pomocą zapory konta magazynu można ograniczyć dostęp do określonych adresów IP/zakresów adresów IP, do określonych sieci wirtualnych lub całkowicie wyłączyć publiczny punkt końcowy.
Jeśli ograniczasz ruch publicznego punktu końcowego do co najmniej jednej sieci wirtualnej, używasz możliwości sieci wirtualnej nazywanej punktami końcowymi usługi. Żądania skierowane do punktu końcowego usługi Azure Files nadal idą do publicznego adresu IP konta magazynu. Jednak warstwa sieci wykonuje dodatkową weryfikację żądania w celu sprawdzenia, czy pochodzi z autoryzowanej sieci wirtualnej. Protokoły SMB, NFS i FileREST obsługują punkty końcowe usługi. W przeciwieństwie do protokołu SMB i FileREST, jednak udziały plików NFS mogą być dostępne tylko z publicznym punktem końcowym przy użyciu punktu końcowego usługi.
Aby dowiedzieć się więcej na temat konfigurowania zapory konta magazynu, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Storage.
Routing sieciowy publicznego punktu końcowego
Azure Files obsługuje wiele opcji routingu sieciowego. Opcja domyślna, routing firmy Microsoft, współdziała ze wszystkimi konfiguracjami Azure Files. Opcja routingu internetowego nie obsługuje scenariuszy przyłączania do domeny usługi AD ani Azure File Sync.
Prywatne punkty końcowe
Oprócz domyślnego publicznego punktu końcowego dla konta magazynu Azure Files zapewnia opcję posiadania co najmniej jednego prywatnego punktu końcowego. Prywatny punkt końcowy to punkt końcowy, który jest dostępny tylko w sieci wirtualnej platformy Azure. Podczas tworzenia prywatnego punktu końcowego dla konta magazynu konto magazynu pobiera prywatny adres IP z przestrzeni adresowej sieci wirtualnej, podobnie jak sposób, w jaki lokalny serwer plików lub urządzenie NAS odbiera adres IP w dedykowanej przestrzeni adresowej sieci lokalnej.
Pojedynczy prywatny punkt końcowy jest skojarzony z określoną podsiecią sieci wirtualnej platformy Azure. Konto magazynu może mieć prywatne punkty końcowe w więcej niż jednej sieci wirtualnej.
Użycie prywatnych punktów końcowych z usługą Azure Files zapewnia następujące możliwości:
- bezpieczne łączenie się z udziałami plików platformy Azure z sieci lokalnych przy użyciu sieci VPN lub połączenia ExpressRoute z prywatną komunikacją równorzędną,
- zabezpieczenie udziałów plików platformy Azure przez skonfigurowanie zapory konta magazynu w celu blokowania wszystkich połączeń w publicznym punkcie końcowym, 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 Files.
Tunelowanie ruchu za pośrednictwem wirtualnej sieci prywatnej lub usługi ExpressRoute
Aby używać prywatnych punktów końcowych do uzyskiwania dostępu do udziałów plików SMB lub NFS ze środowiska lokalnego, należy ustanowić tunel sieciowy między siecią lokalną a platformą Azure. Sieć wirtualna lub sieć wirtualna jest podobna do tradycyjnej sieci lokalnej. 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 obsługuje następujące mechanizmy tunelowania ruchu między lokalnymi stacjami roboczymi i serwerami oraz udziałami plików usługi Azure SMB/NFS:
- 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 obok konta magazynu lub innych zasobów platformy Azure. Bramy sieci VPN uwidaczniają dwa różne typy połączeń:
- Połączenia bramy sieci VPN typu punkt-lokacja (P2S), które są połączeniami sieci VPN między platformą Azure a pojedynczym klientem. To rozwiązanie jest przede wszystkim przydatne w przypadku urządzeń, które nie są częścią sieci lokalnej organizacji. Typowym przypadkiem użycia jest praca telekomunikacyjna, którzy chcą mieć możliwość zainstalowania udziału plików platformy Azure z domu, kawiarni lub hotelu na drodze. Aby użyć połączenia sieci VPN punkt-lokacja z Azure Files, należy skonfigurować połączenie sieci VPN punkt-lokacja dla każdego klienta, który chce nawiązać połączenie. Aby uprościć wdrażanie połączenia sieci VPN typu punkt-lokacja, zobacz Konfigurowanie sieci VPN typu punkt-lokacja (P2S) w systemie Windows do użycia z Azure Files i Konfigurowanie sieci VPN typu punkt-lokacja (P2S) w systemie Linux do użycia z Azure Files.
- Sieć VPN typu lokacja-lokacja (S2S), która jest połączeniami sieci VPN między platformą Azure a siecią organizacji. Połączenie sieci VPN S2S umożliwia skonfigurowanie połączenia sieci VPN raz dla serwera sieci VPN lub urządzenia hostowanego w sieci organizacji zamiast konfigurowania połączenia 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 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 należy wziąć pod uwagę wydajność sieci. Usługa ExpressRoute jest również dobrym rozwiązaniem, gdy zasady organizacji lub wymagania prawne wymagają deterministycznej ścieżki do zasobów w chmurze.
Uwaga
Mimo że zalecamy używanie prywatnych punktów końcowych w celu ułatwienia rozszerzania sieci lokalnej na platformę Azure, technicznie możliwe jest kierowanie do publicznego punktu końcowego za pośrednictwem połączenia sieci VPN. Jednak wymaga to kodowania na stałe adresu IP publicznego punktu końcowego dla klastra usługi Azure Storage, który obsługuje konto magazynu. Ponieważ konta magazynu mogą być przenoszone między klastrami magazynu w dowolnym momencie, a nowe klastry są często dodawane i usuwane, wymaga to regularnego kodowania wszystkich możliwych adresów IP usługi Azure Storage do reguł routingu.
Konfiguracja usługi DNS
Podczas tworzenia prywatnego punktu końcowego domyślnie tworzymy również prywatną strefę DNS (lub aktualizując istniejącą) odpowiadającą privatelink poddomenie. Ściśle rzecz biorąc, utworzenie prywatnej strefy DNS nie jest wymagane do używania prywatnego punktu końcowego dla konta magazynu. Jednak jest to zdecydowanie zalecane ogólnie i jawnie wymagane podczas instalowania udziału plików platformy Azure za pomocą jednostki użytkownika usługi Active Directory lub uzyskiwania do niego dostępu z interfejsu API FileREST.
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.
W prywatnej strefie DNS utworzymy rekord A dla storageaccount.privatelink.file.core.windows.net i rekord CNAME dla regularnej nazwy konta magazynu, który jest zgodny ze wzorcem storageaccount.file.core.windows.net. Ponieważ prywatna strefa DNS platformy Azure jest połączona z siecią wirtualną zawierającą prywatny punkt końcowy, możesz obserwować konfigurację DNS, wywołując Resolve-DnsName polecenie 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 konto magazynu może uwidocznić publiczny punkt końcowy i co najmniej jeden prywatny punkt końcowy. Aby upewnić się, że nazwa konta magazynu jest rozpoznawana jako prywatny adres IP prywatnego punktu końcowego, należy zmienić konfigurację na lokalnych serwerach DNS. Można to osiągnąć na kilka sposobów:
- Modyfikowanie pliku hosts na klientach w celu
storageaccount.file.core.windows.netrozpoznania adresu IP żądanego prywatnego punktu końcowego. Jest to zdecydowanie odradzane w środowiskach produkcyjnych, ponieważ konieczne będzie wprowadzenie tych zmian do każdego klienta, który chce zainstalować udziały plików platformy Azure, a zmiany na koncie magazynu lub prywatnym punkcie końcowym nie będą automatycznie obsługiwane. - Tworzenie rekordu A dla
storageaccount.file.core.windows.netw lokalnych serwerach DNS. Ma to zaletę, że klienci w środowisku lokalnym będą mogli automatycznie rozpoznawać konto magazynu 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. - Przekaż strefę
core.windows.netz 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ą przekazywanecore.windows.netdo prywatnej strefy 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.
Protokół SMB przez QUIC
System Windows Server 2022 Azure Edition obsługuje nowy protokół transportowy o nazwie QUIC dla serwera SMB udostępnionego przez rolę serwera plików. QUIC to zamiennik protokołu TCP, który jest oparty na protokole UDP, zapewniając wiele zalet protokołu TCP, jednocześnie zapewniając niezawodny mechanizm transportu. Jedną z kluczowych zalet protokołu SMB jest to, że zamiast używać portu 445, cały transport odbywa się za pośrednictwem portu 443, który jest powszechnie otwarty dla ruchu wychodzącego do obsługi protokołu HTTPS. Oznacza to, że protokół SMB przez QUIC oferuje "SMB VPN" do udostępniania plików za pośrednictwem publicznego Internetu. Windows 11 dostarczane z klientem obsługującym protokół SMB za pośrednictwem usługi QUIC.
Obecnie Azure Files nie obsługuje bezpośrednio protokołu SMB za pośrednictwem usługi QUIC. Można jednak uzyskać dostęp do udziałów plików platformy Azure za pośrednictwem Azure File Sync uruchomionych w systemie Windows Server, jak pokazano na poniższym diagramie. Dzięki temu można również mieć Azure File Sync pamięci podręczne zarówno lokalnie, jak i w różnych centrach danych platformy Azure w celu zapewnienia lokalnych pamięci podręcznych dla rozproszonej siły roboczej. Aby dowiedzieć się więcej na temat tej opcji, zobacz Deploy Azure File Sync and SMB over QUIC (Wdrażanie Azure File Sync i protokołu SMB za pośrednictwem quiC).
