Azure Files nätverksöverväganden

✔️ Applies to: Alla Azure fildelningar

Du kan komma åt dina Azure filresurser via den offentliga internettillgängliga slutpunkten, över en eller flera privata slutpunkter i nätverket eller genom att cachelagra din Azure filresurs lokalt med Azure File Sync (endast SMB-filresurser). Den här artikeln fokuserar på hur du konfigurerar Azure Files för direkt åtkomst via offentliga och/eller privata slutpunkter. Information om hur du cachelagrar din Azure filresurs lokalt med Azure File Sync finns i Introduction to Azure File Sync.

Läs Planning for a Azure Files deployment innan du läser denna guide.

Direkt åtkomst till en Azure filresurs kräver ofta ytterligare eftertanke när det gäller nätverk:

• SMB-filresurser kommunicerar via port 445, som många organisationer och Internetleverantörer blockerar för utgående trafik (Internet). Den här metoden kommer från äldre säkerhetsvägledning om inaktuella och icke-internetsäkra versioner av SMB-protokollet. Även om SMB 3.x är ett internetsäkert protokoll kanske organisationens eller Internetleverantörens principer inte kan ändras. Därför kräver inmontering av en SMB-filresurs ofta ytterligare nätverkskonfiguration för användning utanför Azure-miljön.

• NFS-filresurser förlitar sig på autentisering på nätverksnivå och är därför endast tillgängliga via begränsade nätverk. Att använda en NFS-fildelning kräver alltid en viss nivå av nätverkskonfiguration.

Du konfigurerar publika och privata endpoints för Azure Files på det övergripande hanteringsobjektet för Azure Files: Azure-lagringskontot. Ett lagringskonto är en hanteringskonstruktion som representerar en delad lagringspool där du kan distribuera flera Azure filresurser samt lagringsresurser för andra Azure lagringstjänster, till exempel blobcontainrar eller köer.

Säker överföring

Som standard kräver Azure lagringskonton säker överföring, oavsett om data nås via den offentliga eller privata slutpunkten. För Azure Files styrs kryptering under överföring på protokollnivå:

Kryptering under överföring för SMB

Inställningen Require Encryption in Transit for SMB styr om kryptering krävs för SMB-åtkomst. För nya lagringskonton som skapats med hjälp av Azure-portalen är den här inställningen aktiverad som standard. Lagringskonton som skapats med hjälp av Azure PowerShell, Azure CLI eller FileREST API anger det här värdet som Not selected för att säkerställa bakåtkompatibilitet. För befintliga lagringskonton fortsätter inställningen Säker överföring som krävs att styra SMB-krypteringsbeteendet tills du uttryckligen konfigurerar SMB-inställningen per protokoll. När SMB-kryptering under överföring krävs kräver alla SMB-filresurser i lagringskontot SMB 3.x-protokollet med AES-128-CCM, AES-128-GCM eller AES-256-GCM-krypteringsalgoritmer. Du kan växla vilka algoritmer som tillåts via SMB-säkerhetsinställningarna. Om du inaktiverar den här inställningen aktiveras SMB 2.1- och SMB 3.x-monteringar utan kryptering.

Kryptering under överföring för NFS

Inställningen Require Encryption in Transit for NFS styr om kryptering krävs för NFS-åtkomst. NFS Azure filresurser använder AZNFS-verktygspaketet för att förenkla krypterade monteringar genom att installera och konfigurera Stunnel (en TLS-omslutning med öppen källkod) på klienten. Se Kryptering under överföring för NFS Azure filresurser. För nya lagringskonton som skapats med hjälp av Azure-portalen är den här inställningen aktiverad som standard. Lagringskonton som skapats med hjälp av Azure PowerShell, Azure CLI eller FileREST API anger det här värdet som Not selected för att säkerställa bakåtkompatibilitet. För befintliga lagringskonton fortsätter inställningen Säker överföring som krävs att styra NFS-krypteringsbeteendet tills du uttryckligen konfigurerar NFS-inställningen per protokoll.

Kryptering under överföring för FileREST

Inställningen Secure transfer required gäller för REST/HTTPS-trafik. När det är aktiverat kan FileREST-protokollet endast användas med HTTPS.

Offentlig slutpunkt

Den offentliga slutpunkten för Azure filresurser i ett lagringskonto är en internetexponerad slutpunkt. Den offentliga slutpunkten är standardslutpunkten för ett lagringskonto, men den kan inaktiveras om du vill.

Protokollen SMB, NFS och FileREST kan alla använda den offentliga slutpunkten. Var och en har dock lite olika regler för åtkomst:

• SMB-filresurser är tillgängliga var som helst i världen via lagringskontots offentliga slutpunkt med SMB 3.x med kryptering. Det innebär att autentiserade begäranden, såsom begäranden auktoriserade av en användares inloggningsuppgifter, kan komma från antingen insidan eller utsidan av Azure-regionen på ett säkert sätt. Om SMB 2.1 eller SMB 3.x utan kryptering önskas måste två villkor uppfyllas:

  1. Inställningen Kräv kryptering under överföring för SMB måste vara inaktiverad (eller för befintliga konton där den här inställningen inte uttryckligen har konfigurerats måste inställningen Säker överföring som krävs inaktiveras).
  2. Begäran måste komma från inom Azure-regionen. Som tidigare nämnts tillåts krypterade SMB-begäranden var som helst, inom eller utanför den Azure regionen.

• NFS-filresurser är tillgängliga från lagringskontots offentliga slutpunkt om och endast om lagringskontots offentliga slutpunkt är begränsad till specifika virtuella nätverk som använder tjänstslutpunkter. Mer information om tjänstslutpunkter finns i Brandväggsinställningar för offentliga slutpunkter.

• FileREST är tillgängligt via den offentliga slutpunkten. Om säker överföring krävs godkänns endast HTTPS-begäranden. Om säker överföring är inaktiverad godkänns HTTP-begäranden av den offentliga slutpunkten oavsett ursprung.

Brandväggsinställningar för offentlig slutpunkt

Brandväggen för lagringskontot begränsar åtkomsten till den offentliga slutpunkten för ett lagringskonto. Du kan begränsa åtkomsten till vissa IP-adresser eller IP-adressintervall, till specifika virtuella nätverk, eller inaktivera den publika ändpunkten helt.

När du begränsar den publika endpointen till ett eller flera nätverk använder du en funktion i det virtuella nätverket som kallas service endpoints. Förfrågningar riktade till Azure Files tjänsteslutpunkt går fortfarande till lagringskontots publika IP-adress. Nätverkslagret utför dock extra verifiering av förfrågan för att verifiera att den kommer från ett auktoriserat virtuellt nätverk. Protokollen SMB, NFS och FileREST stöder alla tjänstslutpunkter. Till skillnad från SMB och FileREST kan dock NFS-fildelningar endast nås genom att använda den publika slutpunkten via en tjänsteändpunkt.

Åtkomst till Azure-portalen och brandväggen för lagringskontot

När du får åtkomst till Azure-filresurser via Azure-portalen sker två separata begäranden:

1. En begäran från webbläsaren till azure-portalens användargränssnitt (https://portal.azure.com).
2. En begäran från webbläsaren direkt till Azure Files dataplansslutpunkt (till exempel https://<storage-account-name>.file.core.windows.net), vanligtvis med hjälp av en SAS-token som utfärdats för portalupplevelsen.

Brandväggen för lagringskontot utvärderar endast den direkta begäran till Azure Files-dataplanets slutpunkt, inte begäran till portal.azure.com. Även om du kan komma åt Azure-portalen utan problem kan du därför få ett 403-fel (förbjudet) när du bläddrar i filresursdata om den offentliga utgående IP-adressen i begäran från webbläsare till lagring inte tillåts av brandväggen. Denna begränsning gäller endast FileREST/HTTPS-trafik, inte SMB eller NFS. För mer information, se Auktorisera åtkomst till fildata i Azure-portalen.

Routning av offentligt slutpunktsnätverk

Azure Files stöder två nätverksroutningsalternativ:

• Microsoft-routing (standard): Trafiken mellan klienten och lagringskontot färdas över Microsoft globala nätverksryggrad så länge som möjligt innan den går ut på internet. Detta alternativ fungerar med alla Azure Files-konfigurationer, inklusive služba Active Directory (AD) domänanslutningsscenarier och Azure File Sync.
• Internetrouting: Trafiken dirigeras över det offentliga internet så tidigt som möjligt. Detta alternativ stöder inte služba Active Directory (AD) domänanslutningsscenarier eller Azure File Sync.

Privata slutpunkter

Förutom den offentliga standardslutpunkten för ett lagringskonto ger Azure Files alternativet att ha en eller flera privata slutpunkter. En privat slutpunkt är en slutpunkt som endast är tillgänglig i ett Azure virtuellt nätverk. När du skapar en privat slutpunkt för ditt lagringskonto får ditt lagringskonto en privat IP-adress inifrån adressutrymmet för det virtuella nätverket, ungefär som hur en lokal filserver eller NAS-enhet tar emot en IP-adress inom det dedikerade adressutrymmet i ditt lokala nätverk.

En enskild privat slutpunkt är associerad med ett specifikt Azure undernät för virtuellt nätverk. Ett lagringskonto kan ha privata slutpunkter i mer än ett virtuellt nätverk.

Med privata slutpunkter med Azure Files kan du:

• Anslut säkert till Azure filresurser från lokala nätverk med hjälp av en VPN- eller ExpressRoute-anslutning med privat peering.
• Skydda dina Azure filresurser genom att konfigurera brandväggen för lagringskontot för att blockera alla anslutningar på den offentliga slutpunkten. Som standard blockerar inte skapandet av en privat slutpunkt anslutningar till den offentliga slutpunkten.
• Öka säkerheten för det virtuella nätverket genom att aktivera att du kan blockera exfiltrering av data från det virtuella nätverket (och peeringgränser).

Information om hur du skapar en privat slutpunkt finns i Konfigurera privata slutpunkter för Azure Files.

Tunneltrafik över ett virtuellt privat nätverk eller ExpressRoute

Om du vill använda privata slutpunkter för att komma åt SMB- eller NFS-filresurser lokalt måste du upprätta en nätverkstunnel mellan ditt lokala nätverk och Azure. Ett virtuellt nätverk liknar ett traditionellt lokalt nätverk. Precis som ett Azure-lagringskonto eller en Azure-VM är ett virtuellt nätverk en Azure-resurs som du distribuerar i en resursgrupp.

Azure Files stöder följande mekanismer för att tunnla trafik mellan dina lokala arbetsstationer och servrar och Azure SMB/NFS-fildelningar:

Punkt-till-plats-VPN

Azure VPN Gateway stöder punkt-till-plats VPN-anslutningar, vilket är VPN-anslutningar mellan Azure och en enskild klient. Den här lösningen är främst användbar för enheter som inte ingår i organisationens lokala nätverk. Ett vanligt användningsfall är för distansarbetare som vill kunna montera sin Azure-filresurs hemifrån, från ett kafé eller hotell när de reser. För att använda en punkt-till-plats VPN-anslutning med Azure Files behöver du konfigurera en punkt-till-plats VPN-anslutning för varje klient som vill ansluta sig. Se Konfigurera ett Point-to-Site VPN på Windows för användning med Azure Files och Konfigurera ett Point-to-Site VPN på Linux för användning med Azure Files.

Plats-till-plats-VPN

Azure VPN Gateway stöder också site-to-site VPN-anslutningar, vilket är VPN-anslutningar mellan Azure och din organisations nätverk. En site-to-site VPN-anslutning gör det möjligt för dig att konfigurera en VPN-anslutning en gång för en VPN-server eller enhet som är värd på din organisations nätverk, istället för att konfigurera en anslutning för varje klientenhet som behöver åtkomst till din Azure-filshare. Se Konfigurera ett Site-to-Site VPN för användning med Azure Files.

ExpressRoute

ExpressRoute gör det möjligt för dig att skapa en definierad rutt mellan Azure och ditt lokala nätverk som inte går över internet. Eftersom ExpressRoute tillhandahåller en dedikerad sökväg mellan ditt lokala datacenter och Azure kan ExpressRoute vara användbart när nätverksprestanda är ett övervägande. ExpressRoute är också ett bra alternativ när organisationens policy- eller regelkrav kräver en deterministisk väg till dina resurser i molnet.

DNS-konfiguration

När du skapar en privat endpoint skapar eller uppdaterar Azure också en privat DNS-zon som motsvarar subdomänenprivatelink. Strikt sett krävs det inte att du skapar en privat DNS-zon för att använda en privat slutpunkt för ditt lagringskonto. Det rekommenderas dock starkt och krävs uttryckligen när du monterar din Azure-filshare med en služba Active Directory-användarprincip eller når den från FileREST API.

I din privata DNS-zon skapar Azure en A-post för storageaccount.privatelink.file.core.windows.net och en CNAME-post för det vanliga namnet på lagringskontot, vilket följer mönstret storageaccount.file.core.windows.net. Eftersom din Azure privata DNS-zon är ansluten till det virtuella nätverket som innehåller den privata slutpunkten kan du observera DNS-konfigurationen genom att anropa cmdleten Resolve-DnsName från PowerShell på en Azure virtuell dator (alternativt nslookup i Windows och Linux):

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

I det här exemplet matchar lagringskontot storageaccount.file.core.windows.net den privata IP-adressen för den privata slutpunkten, som råkar vara 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

Om du kör samma kommando lokalt ser du att samma lagringskontonamn matchar lagringskontots offentliga IP-adress i stället. Till exempel är storageaccount.file.core.windows.net en CNAME-post för storageaccount.privatelink.file.core.windows.net, som i sin tur är en CNAME-post för Azure-lagringsklustret som är värd för lagringskontot:

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

Denna konfiguration speglar att lagringskontot kan exponera både den publika ändpunkten och en eller flera privata ändpunkter. För att säkerställa att lagringskontonamnet matchar den privata slutpunktens privata IP-adress måste du ändra konfigurationen på dina lokala DNS-servrar. Du kan göra detta på flera sätt:

• Ändra värdfilen på dina klienter så att storageaccount.file.core.windows.net pekar till den önskade privata slutpunktens privata IP-adress. Detta rekommenderas inte för produktionsmiljöer eftersom du måste göra dessa ändringar i varje klient som vill montera dina Azure filresurser, och ändringar i lagringskontot eller den privata slutpunkten hanteras inte automatiskt.
• Skapa en A-post för storageaccount.file.core.windows.net på dina lokala DNS-servrar. Detta har fördelen att klienter i din lokala miljö automatiskt kan lösa lagringskontot utan att behöva konfigurera varje klient. Den här lösningen är dock lika skör som att ändra värdfilen eftersom ändringarna inte återspeglas. Även om den här lösningen är skör kan det vara det bästa valet för vissa miljöer.
• Vidarebefordra zonen core.windows.net från dina lokala DNS-servrar till din Azure privata DNS-zon. Den Azure privata DNS-värden kan nås via en särskild IP-adress (168.63.129.16) som endast är tillgänglig i virtuella nätverk som är länkade till den Azure privata DNS-zonen. För att kringgå denna begränsning kan du köra ytterligare DNS-servrar inom ditt virtuella nätverk som vidarebefordrar core.windows.net till Azure:s privata DNS-zon. För att förenkla denna uppsättning tillhandahåller Microsoft PowerShell-cmdlets som automatiskt distribuerar DNS-servrar i ditt virtuella Azure-nätverk och konfigurerar dem som önskat. Information om hur du konfigurerar DNS-vidarebefordran finns i Konfigurera DNS med Azure Files.

SMB över QUIC

Windows Server 2022 Azure Edition stöder ett transportprotokoll kallat QUIC för SMB-servern som tillhandahålls av File Server-rollen. QUIC är en ersättning för TCP som är byggd ovanpå UDP och ger många fördelar jämfört med TCP samtidigt som den erbjuder en pålitlig transportmekanism. En viktig fördel för SMB-protokollet är att i stället för att använda port 445 sker all transport via port 443, som är allmänt öppen utgående för att stödja HTTPS. Denna konfiguration innebär i praktiken att SMB över QUIC erbjuder en "SMB VPN" för fildelning över det publika internet. Windows 11 levereras med en SMB över QUIC-kompatibel klient.

För närvarande stödjer Azure Files inte SMB över QUIC. Du kan dock få tillgång till Azure-fildelningar via Azure File Sync som körs på Windows Server som i diagrammet nedan. Denna konfiguration ger dig också möjlighet att ha Azure File Sync-cacher både lokalt eller i olika Azure-datacenter för att tillhandahålla lokala cacher för en distribuerad arbetsstyrka. För att lära dig mer om detta alternativ, se Windows Server-dokumentationen. För nätverksdetaljer specifikt för Azure File Sync, se SMB över QUIC.

Se även

• Azure Files översikt
• Planera för en Azure Files-distribution