Nätverksöverväganden för Azure File Sync

Den här artikeln behandlar nätverksöverväganden för Azure File Sync, som cachar Azure-fildelningar på lokala Windows-filservrar. För nätverksöverväganden för en direkt Azure Files-distribution, se Azure Files nätverksöverväganden.

Nätverk för Azure File Sync involverar två Azure-objekt: en Storage Sync Service (som hanterar registrerade servrar och synkroniseringsgrupper) och ett Azure-lagringskonto (som är värd för fildelningarna). I de flesta fall behöver du inte någon speciell nätverkskonfiguration utöver en grundläggande internetanslutning, men du kan konfigurera proxyservrar, brandväggar, VPN- eller ExpressRoute-tunnling, privata endpoints och SMB över QUIC.

Ansluta Windows-filservern till Azure med Azure File Sync

För att sätta upp och använda Azure Files och Azure File Sync med en lokal Windows-filserver behöver du inte särskilt nätverk för Azure utöver en grundläggande internetanslutning. För att distribuera Azure File Sync, installera Azure File Sync-agenten på den Windows-filserver du vill synkronisera med Azure. Azure File Sync-agenten uppnår synkronisering med en Azure-fildelning via två kanaler:

• FileREST-protokollet, som är ett HTTPS-baserat protokoll som används för att komma åt din Azure-filresurs. Eftersom FileREST-protokollet använder standard-HTTPS för dataöverföring måste port 443 vara tillgänglig för utgående trafik. Azure File Sync använder inte SMB-protokollet för att överföra data mellan dina lokala Windows-servrar och din Azure-filresurs.
• Synkroniseringsprotokollet för Azure File Sync, som är ett HTTPS-baserat protokoll som används för utbyte av synkroniseringskunskaper, nämligen versionsinformation om filer och mappar mellan slutpunkter i din miljö. Det här protokollet används också för att utbyta metadata om filer och mappar, till exempel tidsstämplar och åtkomstkontrollistor (ACL).

Att montera Azure-fildelningen direkt över SMB för Azure File Sync-agenten är inte nödvändigt och avråds, eftersom direkta ändringar i fildelningen kanske inte upptäcks förrän om upp till 24 timmar. För att använda fildelningen direkt utan Azure File Sync, se Azure Files nätverksöversikt (OVERVIEW).

Även om Azure File Sync inte kräver någon särskild nätverkskonfiguration kanske vissa kunder vill konfigurera avancerade nätverksinställningar för att aktivera följande scenarier:

• Samverka med organisationens proxyserverkonfiguration.
• Öppna organisationens lokala brandvägg för Azure Files- och Azure File Sync-tjänsterna.
• Tunnel Azure Files och Azure File Sync-trafik över en ExpressRoute-anslutning eller ett virtuellt privat nätverk (VPN).

Konfigurera proxyservrar

Azure File Sync kan samarbeta fullt ut med en proxyserver, men du måste manuellt konfigurera proxy-endpoint-inställningarna för din miljö med Azure File Sync. Använd PowerShell och Azure File Sync server cmdletSet-StorageSyncProxyConfiguration.

Mer information om hur du konfigurerar Azure File Sync med en proxyserver finns i Konfigurera Azure File Sync med en proxyserver.

Konfigurera brandväggar och tjänsttaggar

Av säkerhetsskäl isolerar många organisationer sina filservrar från de flesta internetplatser. Om du vill använda Azure File Sync i en sådan miljö måste du konfigurera brandväggen för att tillåta utgående åtkomst för att välja Azure-tjänster. Om din brandvägg stödjer URL- eller domänfiltrering, tillåt port 443 utgående åtkomst till nödvändiga molnendpoints som hostar just dessa Azure-tjänster. Om den inte gör det kan du hämta IP-adressintervallen för dessa Azure-tjänster via tjänsttaggar.

Azure File Sync kräver IP-adressintervallen för följande tjänster, vilket identifieras av deras tjänsttaggar:

Om du använder Azure File Sync i Azure, även om det finns i en annan region, kan du använda namnet på tjänsttaggen direkt i nätverkssäkerhetsgruppen för att tillåta trafik till den tjänsten. Läs mer i Nätverkssäkerhetsgrupper.

Om du använder Azure File Sync lokalt kan du använda api:et för tjänsttaggar för att hämta specifika IP-adressintervall för brandväggens tillåtna lista. Det finns två metoder för att hämta den här informationen:

• Den aktuella listan över IP-adressintervall för alla Azure-tjänster som stöder tjänsttaggar publiceras varje vecka i Microsoft Download Center i form av ett JSON-dokument. Varje Azure-moln har ett eget JSON-dokument med DE IP-adressintervall som är relevanta för molnet:
  • Azure, offentlig molntjänst
  • Azure US Government
  • Microsoft Azure drivs av 21Vianet
  • Azure Tyskland
• API för identifiering av tjänsttaggar (förhandsversion) tillåter programmatisk hämtning av den aktuella listan över tjänsttaggar. I förhandsversionen kan API:et för identifiering av tjänsttaggar returnera information som är mindre aktuell än information som returneras från JSON-dokumenten som publicerats i Microsoft Download Center. Du kan använda API-ytan baserat på din automatiseringsinställning:
  • REST-API
  • Azure PowerShell
  • Azure CLI

Mer information om hur du använder api:et för tjänsttaggar för att hämta adresserna för dina tjänster finns i Tillåtlista för IP-adresser för Azure File Sync.

Tunneltrafik över ett virtuellt privat nätverk eller ExpressRoute

Vissa organisationer kräver kommunikation med Azure för att gå över en nätverkstunnel, till exempel ett VPN eller ExpressRoute, för ytterligare ett säkerhetslager eller för att säkerställa att kommunikationen med Azure följer en deterministisk väg.

Azure Files och Azure File Sync stöder följande mekanismer för att tunneltrafik mellan dina lokala servrar och Azure:

• Azure VPN Gateway: En VPN-gateway är en specifik typ av virtuell nätverksgateway som du använder för att skicka krypterad trafik mellan ett Azure-virtuellt nätverk och en alternativ plats (till exempel lokalt) över internet. En Azure VPN Gateway är en Azure-resurs som du distribuerar i en resursgrupp tillsammans med ett lagringskonto eller andra Azure-resurser. Eftersom Azure File Sync är tänkt att användas med en lokal Windows-filserver, använder du normalt en site-to-site VPN, även om det tekniskt sett är möjligt att använda en point-to-site VPN.

  Site-to-site VPN-anslutningar kopplar ihop ditt virtuella Azure-nätverk med organisationens lokala 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 göra det för varje klientenhet som behöver tillgång till din Azure-fildelning. För att förenkla implementeringen av en site-to-site VPN-anslutning, se Konfigurera en Site-to-Site VPN för användning med Azure Files.

• ExpressRoute, som gör att du kan skapa en definierad väg (privat anslutning) mellan Azure och ditt lokala nätverk som inte passerar 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 en viktig faktor. ExpressRoute är också ett bra alternativ när organisationens policy- eller regelkrav kräver en deterministisk väg till dina resurser i molnet.

SMB över QUIC

Om port 445 är blockerad i din miljö kan du använda SMB istället för QUIC som ett alternativ till VPN eller ExpressRoute. SMB över QUIC använder QUIC-transportprotokollet över port 443, som de flesta organisationer och internetleverantörer (ISP:er) har öppna för att stödja HTTPS-trafik. Denna funktion eliminerar mycket av den nätverkskonfiguration som normalt krävs för att komma åt en fildelning på distans över det offentliga internet.

För att använda SMB över QUIC med Azure File Sync:

• Azure File Sync-serverens endpoint måste köras på en Windows Server Datacenter: Azure Edition virtual machine i Azure.
• Klienterna måste köra Windows 11 eller senare.

För installations- och konfigurationsdetaljer, se SMB över QUIC.

Privata slutpunkter för Azure Files och Azure File Sync

Förutom de offentliga standardslutpunkter som Azure Files och Azure File Sync tillhandahåller via lagringskontot och Storage Sync Service, ger de möjlighet att ha en eller flera privata slutpunkter per resurs. Detta alternativ gör det möjligt att privat och säkert ansluta till Azure-fildelningar från lokal installation med VPN eller ExpressRoute och från ett virtuellt Azure-nätverk. När du skapar en privat slutpunkt för en Azure-resurs hämtar den en privat IP-adress inifrån adressutrymmet för ditt virtuella nätverk, ungefär som hur din lokala Windows-filserver har en IP-adress inom det dedikerade adressutrymmet i ditt lokala nätverk.

En enskild privat slutpunkt är associerad med ett specifikt undernät för ett virtuellt Azure-nätverk. Lagringskonton och Storage Sync Services kan ha privata slutpunkter i mer än ett virtuellt nätverk.

Med privata slutpunkter kan du:

• Anslut på ett säkert sätt till dina Azure-resurser från lokala nätverk med hjälp av en VPN- eller ExpressRoute-anslutning med privat peering.
• Skydda dina Azure-resurser genom att inaktivera de offentliga slutpunkterna för Azure Files och File Sync. 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 File Sync.

Privata slutpunkter och DNS

När du skapar en privat endpoint skapar eller uppdaterar Azure också en privat DNS-zon som motsvarar subdomänenprivatelink. För offentliga molnregioner är privatelink.file.core.windows.net dessa DNS-zoner för Azure Files och privatelink.afs.azure.net för Azure File Sync.

När du skapar privata slutpunkter för ett lagringskonto och för en Storage Sync Service, skapar Azure A-poster för dem i deras respektive privata DNS-zoner. Azure uppdaterar också den publika DNS-posten så att de vanliga fullt kvalificerade domännamnen är CNAME för det relevanta privatelink namnet. Denna konfiguration gör det möjligt för de fullt kvalificerade domännamnen att peka på de privata ändpunktens IP-adresser när begäraren befinner sig inne i det virtuella nätverket och att peka på de publika ändpunktens IP-adresser när begäraren befinner sig utanför det virtuella nätverket.

För Azure Files har varje privat slutpunkt ett enda fullständigt domännamn, enligt mönstret storageaccount.privatelink.file.core.windows.net, mappat till en privat IP-adress för den privata slutpunkten. För Azure File Sync har varje privat slutpunkt fyra fullständigt kvalificerade domännamn för de fyra olika slutpunkter som Azure File Sync exponerar: hantering, synkronisering (primär), synkronisering (sekundär) och övervakning. De fullständigt kvalificerade domännamnen för dessa slutpunkter följer normalt namnet på Tjänsten för synkronisering av lagring såvida inte namnet innehåller icke-ASCII-tecken. Om namnet på din Storage Sync-tjänst till exempel är mysyncservice i regionen Västra USA 2, skulle motsvarande slutpunkter vara mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net, och mysyncservicemonitoring.westus2.afs.azure.net. Varje privat slutpunkt för en lagringssynkroniseringstjänst innehåller fyra distinkta IP-adresser.

Eftersom din privata Dns-zon i Azure ä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 virtuell Azure-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. storageaccount.file.core.windows.net är en CNAME-post för storageaccount.privatelink.file.core.windows.net, som i sin tur är en CNAME-post för Azure Storage-klustret 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 det faktum att Azure Files och Azure File Sync kan exponera både sina publika endpoints och en eller flera privata endpoints per resurs. För att säkerställa att de fullständigt kvalificerade domännamnen för dina resurser pekar på IP-adresserna för den privata slutpunkten måste du konfigurera dina lokala DNS-servrar. Du kan utföra denna uppgift på flera sätt:

• Ändra värdfilen på dina klienter så att de fullständigt kvalificerade domännamnen för dina lagringskonton och Storage Sync Services matchar de önskade privata IP-adresserna. Detta rekommenderas inte för produktionsmiljöer eftersom du måste göra dessa ändringar i varje klient som behöver komma åt dina privata slutpunkter. Ändringar i dina privata slutpunkter/resurser (borttagningar, ändringar osv.) hanteras inte automatiskt.
• Skapa DNS-zoner på dina lokala servrar för privatelink.file.core.windows.net och privatelink.afs.azure.net med A-poster för dina Azure-resurser. Detta har fördelen att klienter i din lokala miljö automatiskt kan lösa Azure-resurser utan att behöva konfigurera varje klient. Den här lösningen är dock lika spröd 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 zonerna core.windows.net och afs.azure.net från dina lokala DNS-servrar till din privata DNS-zon i Azure. Den privata DNS-värdtjänsten i Azure kan nås via en särskild IP-adress (168.63.129.16) som endast är tillgänglig i virtuella nätverk som är kopplade till Azure privata DNS-zon. För att kringgå denna begränsning kan du köra ytterligare DNS-servrar inom ditt virtuella nätverk som vidarebefordrar core.windows.net och afs.azure.net till motsvarande Azure privata DNS-zoner. För att förenkla denna konfiguration tillhandahåller Microsoft PowerShell-cmdlets som automatiskt distribuerar DNS-servrar i ditt virtuella Azure-nätverk och konfigurerar dem som önskat. För att lära dig hur man sätter upp DNS-vidarebefordring, se Konfigurera DNS med Azure Files.

Kryptering vid överföring

Anslutningar som görs från Azure File Sync-agenten till din Azure-filresurs eller Storage Sync Service krypteras alltid. Även om Azure Storage-konton har en inställning för att inaktivera krav på kryptering under överföring för kommunikation till Azure Files (och andra Azure Storage-tjänster som hanteras från lagringskontot), påverkar inte inaktivering av den här inställningen Azure File Syncs kryptering när du kommunicerar med Azure Files. Som standard har alla Azure-lagringskonton kryptering under överföring aktiverat.

För mer information om kryptering under överföring, se kräv säker överföring i Azure-lagring.

Se även

• Planera för en Azure File Sync-distribution
• Distribuera Azure File Sync