Nätverksöverväganden för Azure File Sync
Du kan ansluta till en Azure-filresurs på två sätt:
- Få åtkomst till resursen direkt via SMB- eller FileREST-protokollen. Det här åtkomstmönstret används främst för att eliminera så många lokala servrar som möjligt.
- Skapa en cache för Azure-filresursen på en lokal server (eller en virtuell Azure-dator) med Azure File Sync och få åtkomst till filresursens data från den lokala servern med ditt valfritt protokoll (SMB, NFS, FTPS osv.). Det här åtkomstmönstret är praktiskt eftersom det kombinerar det bästa av både lokal prestanda och molnskala med mervärdestjänster som Azure Backup.
Den här artikeln fokuserar på det andra scenariot: hur du konfigurerar nätverk när ditt användningsfall anropar för att använda Azure File Sync för att cachelagras filer lokalt i stället för att montera Azure-filresursen direkt via SMB. Mer information om nätverksöverväganden för en Azure Files-distribution finns i Nätverksöverväganden för Azure Files.
Nätverkskonfigurationen för Azure File Sync omfattar två olika Azure-objekt: en Tjänst för synkronisering av lagring och ett Azure-lagringskonto. Ett lagringskonto är en hanteringskonstruktion som representerar en delad lagringspool där du kan distribuera flera filresurser samt andra lagringsresurser, till exempel blobar eller köer. En tjänst för synkronisering av lagring är en hanteringskonstruktion som representerar registrerade servrar, som är Windows-filservrar med en etablerad förtroenderelation med Azure File Sync, och synkroniseringsgrupper som definierar topologin för synkroniseringsrelationen.
Viktigt!
Azure File Sync stöder inte Internetroutning. Standardalternativet för nätverksroutning, Microsoft-routning, stöds av Azure File Sync.
Ansluta Windows-filservern till Azure med Azure File Sync
För att konfigurera och använda Azure Files och Azure File Sync med en lokal Windows-filserver krävs inga särskilda nätverk till Azure utöver en grundläggande Internetanslutning. Om du vill distribuera Azure File Sync installerar du Azure File Sync-agenten på den Windows-filserver som du vill synkronisera med Azure. Azure File Sync-agenten uppnår synkronisering med en Azure-filresurs 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).
Eftersom Azure Files erbjuder direkt SMB-protokollåtkomst på Azure-filresurser undrar kunderna ofta om de behöver konfigurera särskilda nätverk för att montera Azure-filresurserna med hjälp av SMB för att Azure File Sync-agenten ska få åtkomst. Detta krävs inte och rekommenderas inte förutom i administratörsscenarier, på grund av bristen på snabb ändringsidentifiering för ändringar som görs direkt i Azure-filresursen. Ändringar kanske inte identifieras på mer än 24 timmar beroende på storlek och antal objekt i Azure-filresursen. Om du vill använda Azure-filresursen direkt i stället för att använda Azure File Sync för att cachelagrar lokalt kan du läsa Översikt över Azure Files-nätverk.
Ä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- eller ett virtuellt privat nätverk (VPN).
Konfigurera proxyservrar
Många organisationer använder en proxyserver som mellanhand mellan resurser i sitt lokala nätverk och resurser utanför nätverket, till exempel i Azure. Proxyservrar är användbara för många program, till exempel nätverksisolering och säkerhet, övervakning och loggning. Azure File Sync kan samverka helt med en proxyserver, men du måste manuellt konfigurera proxyslutpunktsinställningarna för din miljö med Azure File Sync. Detta måste göras via PowerShell med hjälp av Azure File Sync-server-cmdleten Set-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
Många organisationer isolerar sina filservrar från de flesta Internetplatser i säkerhetssyfte. 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. Du kan göra detta genom att tillåta utgående port 443-åtkomst till nödvändiga molnslutpunkter som är värdar för dessa specifika Azure-tjänster om brandväggen stöder URL/domäner. 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:
Tjänst | beskrivning | Tjänsttagg |
---|---|---|
Azure File Sync | Azure File Sync-tjänsten, som representeras av objektet Storage Sync Service, ansvarar för kärnaktiviteten med att synkronisera data mellan en Azure-filresurs och en Windows-filserver. | StorageSyncService |
Azure Files | Alla data som synkroniseras via Azure File Sync lagras i Azure-filresursen. Filer som har ändrats på dina Windows-filservrar replikeras till din Azure-filresurs och filer som är nivåindelade på den lokala filservern laddas sömlöst ned när en användare begär dem. | Storage |
Azure Resource Manager | Azure Resource Manager är hanteringsgränssnittet för Azure. Alla hanteringsanrop, inklusive Azure File Sync-serverregistrering och pågående synkroniseringsserveruppgifter, görs via Azure Resource Manager. | AzureResourceManager |
Microsoft Entra ID | Microsoft Entra-ID (tidigare Azure AD) innehåller de användarhuvudnamn som krävs för att auktorisera serverregistrering mot en Tjänst för synkronisering av lagring och de tjänsthuvudnamn som krävs för att Azure File Sync ska ha behörighet att komma åt dina molnresurser. | AzureActiveDirectory |
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:
- 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:
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.
När du upprättar en nätverkstunnel mellan ditt lokala nätverk och Azure peerkopplar du ditt lokala nätverk med ett eller flera virtuella nätverk i Azure. Ett virtuellt nätverk, eller ett virtuellt nätverk, liknar ett traditionellt nätverk som du använder lokalt. Precis som ett Azure Storage-konto eller en virtuell Azure-dator är ett virtuellt nätverk en Azure-resurs som distribueras i en resursgrupp.
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 används för att skicka krypterad trafik mellan ett virtuellt Azure-nätverk och en alternativ plats (till exempel lokalt) via Internet. En Azure VPN Gateway är en Azure-resurs som kan distribueras i en resursgrupp längs sidan av ett lagringskonto eller andra Azure-resurser. Eftersom Azure File Sync är avsett att användas med en lokal Windows-filserver använder du normalt ett VPN för plats-till-plats (S2S), även om det är tekniskt möjligt att använda ett punkt-till-plats-VPN (P2S).
Vpn-anslutningar från plats till plats (S2S) ansluter ditt virtuella Azure-nätverk och organisationens lokala nätverk. Med en S2S VPN-anslutning kan du konfigurera en VPN-anslutning en gång, för en VPN-server eller enhet som finns i organisationens nätverk, i stället för att göra det för varje klientenhet som behöver komma åt din Azure-filresurs. Information om hur du förenklar distributionen av en S2S VPN-anslutning finns i Konfigurera en plats-till-plats-VPN (S2S) 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.
Privata slutpunkter
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. På så sätt kan du privat och säkert ansluta till Azure-filresurser lokalt med hjälp av VPN eller ExpressRoute och inifrå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.
Viktigt!
För att kunna använda privata slutpunkter på Storage Sync Service-resursen måste du använda Azure File Sync-agent version 10.1 eller senare. Agentversioner före 10.1 stöder inte privata slutpunkter i Tjänsten för synkronisering av lagring. Alla tidigare agentversioner stöder privata slutpunkter på lagringskontoresursen.
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 slutpunkt skapar vi som standard också (eller uppdaterar en befintlig) privat DNS-zon som motsvarar underdomänen privatelink
. 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.
Kommentar
Den här artikeln använder DNS-suffixet för lagringskontot för de offentliga Azure-regionerna, core.windows.net
. Detta gäller även för Azure Sovereign-moln som Azure US Government-molnet och Microsoft Azure som drivs av 21Vianet-molnet – ersätt bara lämpliga suffix för din miljö.
När du skapar privata slutpunkter för ett lagringskonto och en tjänst för synkronisering av lagring skapar vi A-poster för dem i deras respektive privata DNS-zoner. Vi uppdaterar också den offentliga DNS-posten så att de vanliga fullständigt kvalificerade domännamnen är CNAMEs för det relevanta privatelink
namnet. Detta gör att de fullständigt kvalificerade domännamnen kan peka på den privata slutpunktens IP-adress(es) när beställaren är inne i det virtuella nätverket och peka på den offentliga slutpunktens IP-adress (es) när beställaren är 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å tjänsten för lagringssynkronisering till exempel finns mysyncservice
i regionen USA, västra 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 när du anropar 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 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
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
Detta återspeglar det faktum att Azure Files och Azure File Sync kan exponera både sina offentliga slutpunkter och en eller flera privata slutpunkter per resurs. För att säkerställa att de fullständigt kvalificerade domännamnen för dina resurser matchar privata IP-adresser för privata slutpunkter måste du ändra konfigurationen på dina lokala DNS-servrar. Detta kan göras 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
ochprivatelink.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
ochafs.azure.net
från dina lokala DNS-servrar till din privata DNS-zon i Azure. Den privata DNS-värden 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 länkade till den privata DNS-zonen i Azure. För att kringgå den här begränsningen kan du köra ytterligare DNS-servrar i ditt virtuella nätverk som vidarebefordrarcore.windows.net
ochafs.azure.net
till motsvarande privata DNS-zoner i Azure. För att förenkla den här konfigurationen har vi tillhandahållit PowerShell-cmdletar som automatiskt distribuerar DNS-servrar i ditt virtuella Azure-nätverk och konfigurerar dem efter behov. Information om hur du konfigurerar DNS-vidarebefordran finns i 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.
Mer information om kryptering under överföring finns i krav på säker överföring i Azure Storage.