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 service tag API för att få specifika IP-adressintervall för tillåtslistan för brandväggen. 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ödjer servicetaggar publiceras veckovis på 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örhandsgranskning kan service tag discovery API returnera information som är mindre aktuell än informationen från JSON-dokumenten publicerade på Microsoft Download Center. Du kan använda API-ytan baserat på din automatiseringsinställning:
  • REST-API
  • Azure PowerShell
  • Azure CLI

För att lära dig mer om hur du använder service tag API för att hämta adresserna till dina tjänster, se Tillåt-listan för Azure File Sync IP-adresser.

Tunneltrafik över ett virtuellt privat nätverk eller ExpressRoute

Vissa organisationer kräver att kommunikation med Azure går via en nätverkstunnel, såsom en VPN eller ExpressRoute, för ett extra 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 stegen för att koppla lokala klienter till en fildelning via en privat endpoint, se Anslut från lokala miljöer.

• 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

Utöver de standardpublika endpoints som Azure Files och Azure File Sync tillhandahåller via lagringskontot och Storage Sync Service, kan du konfigurera en eller flera privata endpoints för varje 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.

Genom att använda privata endpoints kan du:

• Koppla säkert till dina Azure-resurser från lokala nätverk genom att använda 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 fullt kvalificerade domännamnen för dessa ändpunkter följer normalt namnet på Storage Sync Service, såvida inte namnet innehåller icke-ASCII-tecken. Till exempel, om ditt Storage Sync Service-namn är mysyncservice i West US 2-regionen, är mysyncservicemanagement.westus2.afs.azure.netde motsvarande ändpunkterna , mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net, och mysyncservicemonitoring.westus2.afs.azure.net. Varje privat slutpunkt för en Storage Sync Service 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 detta exempel löses lagringskontot storageaccount.file.core.windows.net till den privata IP-adressen för den privata ändpunkten, som är 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 från den lokala miljön, ser du att samma lagringskontonamn istället matchas mot lagringskontots publika IP-adress; storageaccount.file.core.windows.net är en CNAME-post för storageaccount.privatelink.file.core.windows.net, vilket 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 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:

• Modifiera hosts-filen på dina klienter så att de fullt kvalificerade domännamnen för dina lagringskonton och Storage Sync Services matchar de önskade privata IP-adresserna. Använd inte detta tillvägagångssätt för produktionsmiljöer, eftersom du måste göra dessa ändringar på varje klient som behöver åtkomst till dina privata endpoints. Ändringar av dina privata endpoints eller resurser (raderingar, ändringar och så vidare) 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. Denna metod 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. Du kan nå Azure:s privata DNS-värd via en speciell IP-adress (168.63.129.16) som endast är tillgänglig inom virtuella nätverk som är kopplade till Azure:s 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 Azure File Sync-agenten gör till din Azure-fildelning eller Storage Sync Service är alltid krypterade. Även om Azure-lagringskonton har en inställning som inaktiverar krav på kryptering under överföring för kommunikation till Azure Files (och de andra Azure-lagringstjänster som lagringskontot hanterar), påverkar inte avstängning av denna inställning Azure File Sync:s kryptering när det 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 FileREST-kryptering under överföring.

Se även

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