Azure Files zagadnienia dotyczące sieci

✔️ Dotyczy: Wszystkich udziałów plikowych Azure

Dostęp do udziałów plików Azure można uzyskać za pośrednictwem publicznego punktu końcowego dostępnego w Internecie, za pośrednictwem co najmniej jednego prywatnego punktu końcowego w sieci lub buforując udział plików Azure lokalnie za pomocą 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 zbuforować udział plików Azure lokalnie przy użyciu Azure File Sync, zobacz Introduction to Azure File Sync.

Przeczytaj Planowanie wdrożenia Azure Files, zanim przeczytasz ten przewodnik.

Bezpośredni dostęp do dzielenia plików Azure często wymaga dodatkowego zastanowienia się nad kwestiami sieciowymi:

• Udziały plików SMB komunikują się za pośrednictwem portu 445, który wiele organizacji i dostawców usług internetowych (ISP) blokuje dla ruchu wychodzącego (internet). Ta praktyka wynika ze starszych wskazówek dotyczących zabezpieczeń dotyczących przestarzałych i nieinternestycznych wersji protokołu SMB. Mimo że protokół SMB 3.x jest protokołem bezpiecznym dla Internetu, zasady organizacji lub usługodawcy internetowego mogą nie być możliwe do zmiany. W związku z tym montowanie udziału plików SMB często wymaga dodatkowej konfiguracji sieci do użycia poza platformą Azure.

• Udziały plików NFS korzystają z uwierzytelniania na poziomie sieci i dlatego są dostępne tylko za pośrednictwem sieci z ograniczeniami. Korzystanie z zasobu plików NFS zawsze wymaga pewnego poziomu konfiguracji sieci.

Konfigurujesz publiczne i prywatne endpointy dla Azure Files na najwyższym obiekcie zarządzania dla Azure Files: kontu Azure storage. Konto przechowywania to konstrukcja zarządcza, która reprezentuje udostępnioną pulę przechowywania, w której można wdrożyć wiele udziałów plików Azure, a także zasoby przechowywania dla innych usług przechowywania Azure, takich jak kontenery obiektów blob lub kolejki.

Bezpieczny transfer

Domyślnie konta magazynu Azure wymagają bezpiecznego transferu, niezależnie od tego, czy dane są dostępne za pośrednictwem publicznych lub prywatnych punktów końcowych. W przypadku Azure Files szyfrowanie podczas przesyłania jest kontrolowane na poziomie protokołu:

Szyfrowanie podczas przesyłania dla SMB

Ustawienie Require Encryption in Transit for SMB reguluje, czy szyfrowanie jest wymagane dla dostępu SMB. W przypadku nowych kont magazynu utworzonych przy użyciu portalu Azure to ustawienie jest domyślnie włączone. Konta magazynowe utworzone przy użyciu Azure PowerShell, Azure CLI lub FileREST API ustawiają tę wartość jako Not selected w celu zapewnienia zgodności z poprzednimi wersjami. W przypadku istniejących kont magazynu ustawienie Wymagany bezpieczny transfer nadal będzie kontrolować zachowanie szyfrowania SMB do momentu jawnej konfiguracji ustawienia dla poszczególnych protokołów SMB. Gdy wymagane jest szyfrowanie SMB w tranzycie, wszystkie udziały plików SMB na tym koncie magazynu wymagają protokołu SMB 3.x z algorytmami szyfrowania AES-128-CCM, AES-128-GCM i AES-256-GCM. Można przełączać, które algorytmy są dozwolone za pośrednictwem ustawień zabezpieczeń protokołu SMB. Wyłączenie tego ustawienia umożliwia instalowanie protokołu SMB 2.1 i SMB 3.x bez szyfrowania.

Szyfrowanie w tranzycie dla NFS

Ustawienie Require Encryption in Transit for NFS reguluje, czy szyfrowanie jest wymagane do dostępu do NFS. Udziały plików NFS Azure umożliwiają użycie pakietu narzędziowego AZNFS w celu uproszczenia zaszyfrowanych montowań przez zainstalowanie i skonfigurowanie Stunnel (otwartoźródłowej otoki TLS) na kliencie. Zobacz Szyfrowanie podczas przesyłania dla udziałów plików Azure NFS. W przypadku nowych kont magazynu utworzonych przy użyciu portalu Azure to ustawienie jest domyślnie włączone. Konta magazynowe utworzone przy użyciu Azure PowerShell, Azure CLI lub FileREST API ustawiają tę wartość jako Not selected w celu zapewnienia zgodności z poprzednimi wersjami. W przypadku istniejących kont magazynu ustawienie Wymagany bezpieczny transfer będzie nadal regulować zachowanie szyfrowania NFS, dopóki nie skonfigurujesz ustawień NFS dla poszczególnych protokołów.

Szyfrowanie w transporcie dla FileREST

Ustawienie Secure transfer required dotyczy ruchu REST/HTTPS. Po włączeniu protokołu FileREST można używać tylko z protokołem HTTPS.

Publiczny punkt końcowy

Publiczny punkt końcowy udziałów plików Azure na koncie magazynowym jest punktem końcowym wystawionym na internet. Publiczny punkt końcowy jest domyślnym punktem końcowym dla konta magazynowego, 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 magazynowego 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 Azure. Jeśli protokół SMB 2.1 lub SMB 3.x bez szyfrowania jest wymagany, należy spełnić dwa warunki:

  1. Ustawienie Wymagaj szyfrowania podczas przesyłania dla protokołu SMB musi być wyłączone (lub w przypadku istniejących kont, na których to ustawienie nie zostało jawnie skonfigurowane, ustawienie Wymagany bezpieczny transfer musi być wyłączone).
  2. Żądanie musi pochodzić z wewnątrz regionu Azure. Jak wspomniano wcześniej, zaszyfrowane żądania SMB są dozwolone z dowolnego miejsca lub poza regionem 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. Zobacz ustawienia zapory punktu końcowego publicznego dla dodatkowych informacji na temat punktów końcowych usługi.

• FileREST 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 sieciowej punktu końcowego publicznego

Zapora konta przechowywania ogranicza dostęp do publicznego punktu końcowego dla konta przechowywania. Możesz ograniczyć dostęp do określonych adresów IP lub zakresów adresów IP, do konkretnych sieci wirtualnych lub całkowicie wyłączyć publiczny punkt końcowy.

Gdy ograniczasz publiczny punkt końcowy do jednej lub więcej sieci, korzystasz z funkcji sieci wirtualnej zwanej punktami końcowymi usług. Żądania kierowane do punktu końcowego usługi Azure Files nadal trafiają na publiczny adres IP konta magazynowego. Jednak warstwa sieciowa wykonuje dodatkową weryfikację żądania, aby potwierdzić, że pochodzi ono z autoryzowanej sieci wirtualnej. Wszystkie protokoły SMB, NFS i FileREST obsługują punkty końcowe usługi. W przeciwieństwie do SMB i FileREST, do udostępnień plików NFS można uzyskać dostęp tylko przez publiczny punkt końcowy za pośrednictwem punktu końcowego usługi.

Dostęp do witryny Azure Portal i zapora konta magazynu

Gdy uzyskujesz dostęp do udziałów plików platformy Azure za pośrednictwem witryny Azure Portal, są wykonywane dwa oddzielne żądania:

1. Żądanie z przeglądarki do interfejsu użytkownika portalu Azure (https://portal.azure.com).
2. Żądanie z przeglądarki bezpośrednio do punktu końcowego płaszczyzny danych usługi Azure Files (na przykład https://<storage-account-name>.file.core.windows.net), zazwyczaj przy użyciu tokenu SAS wystawionego dla środowiska portalu.

Zapora konta magazynu ocenia tylko bezpośrednie żądanie do punktu końcowego płaszczyzny danych usługi Azure Files, a nie żądanie do portal.azure.com. W związku z tym, nawet jeśli możesz uzyskać dostęp do portalu Azure bez problemów, możesz napotkać błąd 403 (Zabronione) podczas przeglądania danych udziału plików, jeśli publiczny wychodzący adres IP w żądaniu przeglądarki do magazynu nie jest dozwolony przez zaporę. To ograniczenie dotyczy tylko ruchu FileREST/HTTPS, nie SMB czy NFS. Więcej informacji można znaleźć w artykule Autoryzuj dostęp do danych plików w portalu Azure.

Routing sieci publicznego punktu końcowego

Azure Files obsługuje dwie opcje routingu sieciowego:

• Routing Microsoft (domyślnie): Ruch między klientem a kontem pamięci masowej przechodzi przez globalny szkielet sieci Microsoft tak długo, jak to możliwe, zanim trafi do internetu. Ta opcja działa ze wszystkimi konfiguracjami Azure Files, w tym scenariuszami łączenia domeny Active Directory (AD) oraz Azure File Sync.
• Trasowanie internetowe: Ruch jest kierowany przez publiczną sieć internetową na możliwie najwcześniejszym etapie. Ta opcja nie obsługuje scenariuszy łączenia domeny Active Directory (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 Azure sieci wirtualnej. Gdy tworzysz prywatny punkt końcowy dla swojego konta magazynu, konto to otrzymuje prywatny adres IP z przestrzeni adresowej twojej sieci wirtualnej, podobnie jak serwer plików lub urządzenie NAS w lokalnej sieci otrzymuje adres IP wewnątrz dedykowanej przestrzeni adresowej twojej sieci lokalnej.

Pojedynczy prywatny punkt końcowy jest skojarzony z określoną podsiecią sieci wirtualnej Azure. Konto magazynowe może mieć prywatne punkty końcowe w więcej niż jednej sieci wirtualnej.

Używanie prywatnych punktów końcowych z Azure Files umożliwia:

• Połącz się bezpiecznie z udziałami plików Azure z sieci lokalnych przy użyciu połączenia sieci VPN lub usługi ExpressRoute z prywatnego peeringu.
• Zabezpiecz udziały plików Azure, konfigurując zaporę konta magazynowego w celu blokowania wszystkich połączeń w publicznym punkcie końcowym. Domyślnie tworzenie prywatnego punktu końcowego nie blokuje połączeń z publicznym punktem końcowym.
• Zwiększenie bezpieczeństwa sieci wirtualnej przez umożliwianie blokowania eksfiltracji danych z sieci wirtualnej oraz granic komunikacyjnych sieci równorzędnych.

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 Azure. Sieć wirtualna jest podobna do tradycyjnej sieci lokalnej. Podobnie jak konto Azure storage lub maszyna wirtualna Azure, sieć wirtualna to zasób Azure, który wdrażasz w grupie zasobów.

Azure Files obsługuje następujące mechanizmy tunelowania ruchu między stacjami roboczymi i serwerami lokalnymi a udziałami plików SMB/NFS Azure:

Sieć VPN typu punkt-lokacja

Azure VPN Gateway obsługuje połączenia VPN typu punkt-lokacja, czyli połączenia VPN między platformą Azure a pojedynczym klientem. To rozwiązanie jest szczególnie przydatne w przypadku urządzeń, które nie są częścią sieci lokalnej organizacji. Typowym przypadkiem użycia są pracownicy zdalni, którzy chcą mieć możliwość zamontowania swojego udziału plików Azure z domu, kawiarni lub hotelu podczas podróży. Aby użyć połączenia point-to-site VPN z Azure Files, musisz skonfigurować połączenie Point-to-Site VPN dla każdego klienta, który chce się połączyć. Zobacz Konfigurowanie sieci VPN typu punkt-lokacja w systemie Windows na potrzeby usługi Azure Files oraz Konfigurowanie sieci VPN typu punkt-lokacja w systemie Linux na potrzeby usługi Azure Files.

VPN między lokalizacjami

Azure VPN Gateway obsługuje także połączenia VPN między lokalizacjami, czyli połączenia VPN między Azure a siecią Twojej organizacji. Połączenie VPN między lokalizacjami pozwala skonfigurować połączenie VPN raz dla serwera VPN lub urządzenia hostowanego w sieci organizacji, zamiast konfigurować połączenie dla każdego urządzenia klienta, które musi uzyskać dostęp do udostępnienia plików Azure. Zobacz Konfigurowanie sieci VPN typu lokacja-lokacja na potrzeby korzystania z usługi Azure Files.

ExpressRoute

ExpressRoute pozwala utworzyć zdefiniowaną trasę między Azure a siecią lokalną, która nie przechodzi przez internet. Ponieważ usługa ExpressRoute udostępnia dedykowaną ścieżkę między lokalnym centrum danych i 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 lub wymagania prawne organizacji wymagają deterministycznej ścieżki do zasobów w chmurze.

Konfiguracja DNS

Gdy tworzysz prywatny punkt końcowy, Azure tworzy lub aktualizuje także prywatną strefę DNS odpowiadającą subdomenieprivatelink. Mówiąc ściśle, tworzenie prywatnej strefy DNS nie jest wymagane do korzystania z prywatnego punktu końcowego dla konta magazynowego. Jest to jednak zdecydowanie zalecane, a także wyraźnie wymagane podczas instalowania udziału plików platformy Azure przy użyciu tożsamości użytkownika usługi Active Directory lub podczas uzyskiwania do niego dostępu za pomocą interfejsu API FileREST.

W prywatnej strefie DNS platforma Azure tworzy rekord A dla storageaccount.privatelink.file.core.windows.net oraz rekord CNAME dla standardowej nazwy konta magazynu, która jest zgodna ze wzorcem storageaccount.file.core.windows.net. 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 magazynowe storageaccount.file.core.windows.net odnosi 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 uruchomisz to samo polecenie ze środowiska lokalnego, zobaczysz, że ta sama nazwa konta magazynu jest rozpoznawana jako publiczny adres IP konta magazynu. Na przykład storageaccount.file.core.windows.net jest rekordem CNAME dla storageaccount.privatelink.file.core.windows.net, który z kolei jest rekordem CNAME dla klastra magazynu Azure 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

Ta konfiguracja odzwierciedla, że konto pamięci masowej może eksponować zarówno publiczny punkt końcowy, jak i jeden lub więcej prywatnych punktów końcowych. 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 zrobić na kilka sposobów:

• Modyfikowanie pliku hostów na klientach w celu storageaccount.file.core.windows.net rozpoznania adresu IP żądanego prywatnego punktu końcowego. Jest to zdecydowanie odradzane w środowiskach produkcyjnych, ponieważ należy wprowadzić te zmiany na każdym kliencie, który chce zamontować udziały plikowe Azure, a zmiany w koncie magazynowym lub prywatnym punkcie dostępu nie będą automatycznie obsługiwane.
• Tworzenie rekordu A dla storageaccount.file.core.windows.net w lokalnych serwerach DNS. Ma to zaletę, że klienci w środowisku lokalnym będą mogli automatycznie rozwiązywać konto magazynowe bez konieczności konfigurowania każdego klienta. Jednak to rozwiązanie jest równie mało odporne, jak modyfikacja pliku hosts, ponieważ zmiany nie są odzwierciedlane. Chociaż to rozwiązanie jest kruche, może to być najlepszy wybór dla niektórych środowisk.
• Prześlij dalej strefę core.windows.net z lokalnych serwerów DNS do prywatnej strefy DNS Azure. Prywatny host DNS 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 Azure. Aby obejść to ograniczenie, możesz uruchomić dodatkowe serwery DNS w swojej wirtualnej sieci, które przekierowują core.windows.net do prywatnej strefy 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ć przekazywanie DNS, zobacz Konfigurowanie systemu DNS przy użyciu Azure Files.

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

Windows Server 2022 Azure Edition obsługuje protokół transportowy o nazwie QUIC dla serwera SMB udostępnianego przez rolę Serwera Plików. QUIC to zamiennik TCP zbudowany na UDP, oferujący liczne zalety względem TCP, a 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 obsługi protokołu HTTPS. Ta konfiguracja oznacza, że SMB over QUIC oferuje "SMB VPN" do udostępniania plików przez publiczny internet. Windows 11 jest dostarczany z klientem obsługującym SMB przez QUIC.

Obecnie Azure Files nie obsługuje SMB przez QUIC. Jednak możesz uzyskać dostęp do udostępnionych plików Azure przez Azure File Sync działający na Windows Server, jak pokazano na poniższym diagramie. Ta konfiguracja daje również możliwość korzystania z pamięci podręcznej Azure File Sync zarówno lokalnie, jak i w różnych centrach danych Azure, aby zapewnić lokalne pamięci podręczne dla rozproszonej siły roboczej. Aby dowiedzieć się więcej o tej opcji, zobacz dokumentację Windows Server. Szczegóły dotyczące sieci specyficzne dla Azure File Sync znajdziesz w SMB over QUIC.

Zobacz też

• Omówienie Azure Files
• Planowanie wdrożenia usługi Azure Files