Azure File Sync のネットワークに関する考慮事項

この記事では、オンプレミスのWindowsファイルサーバー上でAzureファイル共有をキャッシュするAzure File Syncのネットワークに関する考慮事項について解説します。 直接Azure Files展開のネットワークに関する考慮事項については、Azure Files networkingの考慮事項を参照してください。

Azure File Syncのネットワーキングには、2つのAzureオブジェクトが構成されます。1つは登録サーバーと同期グループを管理するStorage Sync Serviceと、ファイル共有をホストするAzureストレージアカウントです。 ほとんどの場合、基本的なインターネット接続以上の特別なネットワーク設定は必要ありませんが、プロキシサーバー、ファイアウォール、VPNやExpressRouteのトンネリング、プライベートエンドポイント、SMBをQUIC経由で設定できます。

重要

Azure File Sync は、インターネット ルーティングをサポートしていません。 既定のネットワーク ルーティング オプションである Microsoft ルーティングは、Azure File Sync でサポートされています。

Azure File Sync を使用して Windows ファイル サーバーを Azure に接続する

オンプレミスのWindowsファイルサーバーでAzure FilesとAzure File Syncをセットアップ・利用するには、基本的なインターネット接続以上の特別なネットワークAzure必要ありません。 Azure File Syncを展開するには、Azureと同期したいWindowsファイルサーバーにAzure File Syncエージェントをインストールしてください。 Azure File Syncエージェントは、2つのチャネルを通じてAzureファイル共有と同期を実現します。

  • FileREST プロトコル。これは、Azure ファイル共有へのアクセスに使用される HTTPS ベースのプロトコルです。 FileREST プロトコルではデータ転送に標準の HTTPS が使用されるため、ポート 443 のアウトバウンド アクセスを可能にする必要があります。 Azure File Sync では、オンプレミスの Windows サーバーと Azure ファイル共有間のデータ転送に SMB プロトコルは使用されません。
  • Azure File Sync 同期プロトコル。これは、同期ナレッジ (つまり、環境内のエンドポイント間のファイルとフォルダーに関するバージョン情報) を交換するために使用される HTTPS ベースのプロトコルです。 このプロトコルは、タイムスタンプやアクセス制御リスト (ACL) など、ファイルとフォルダーに関するメタデータを交換するためにも使用されます。

Azure File SyncエージェントのためにAzureファイル共有をSMB上で直接マウントすることは必須ではなく、推奨されません。なぜなら、ファイル共有への直接的な変更が最大24時間検出されない可能性があるからです。 Azure File Syncなしでファイル共有を直接使うには、Azure Filesネットワークの概要をご覧ください。

Azure File Sync には特別なネットワーク構成は必要ありませんが、一部のお客様は、次のシナリオを実現するために、ネットワークの詳細設定を構成することを希望する場合があります。

  • 組織のプロキシ サーバー構成と相互運用する。
  • Azure Files および Azure File Sync サービスに対してご自分の組織のオンプレミスのファイアウォールを開く。
  • ExpressRoute または仮想プライベート ネットワーク (VPN) 接続経由で Azure Files と Azure File Sync のトラフィックをトンネリングする。

プロキシ サーバーの構成

Azure File Syncはプロキシサーバーと完全に相互運用可能ですが、Azure File Syncで環境に合ったプロキシエンドポイントの設定は手動で設定する必要があります。PowerShellとAzure File Syncサーバーのcmdlet Set-StorageSyncProxyConfigurationを使いましょう。

プロキシ サーバーを使用する場合の Azure File Sync の構成方法の詳細については、プロキシ サーバーを使用する場合の Azure File Sync の構成に関するページを参照してください。

ファイアウォールとサービス タグを構成する

セキュリティ上の理由から、多くの組織はファイルサーバーをほとんどのインターネット拠点から隔離しています。 このような環境で Azure File Sync を使用するには、ファイアウォールを構成して、選択した Azure サービスに対する送信アクセスを許可する必要があります。 もしファイアウォールがURLやドメインフィルタリングをサポートしているなら、特定のAzureサービスをホストする必要なクラウドエンドポイントへのポート443のアウトバウンドアクセスを許可してください。 そうでない場合は、サービス タグを使用して、これらの Azure サービスの IP アドレス範囲を取得できます。

Azure File Sync には、次のサービスのサービス タグによって識別されるそれぞれの IP アドレス範囲が必要です。

サービス 説明 サービス タグ
Azure File Sync ストレージ同期サービス オブジェクトによって表される Azure File Sync サービスは、Azure ファイル共有と Windows ファイル サーバーとの間でデータを同期するための主要なアクティビティを担当します。 StorageSyncService
Azure Files Azure File Syncを通じて同期されたすべてのデータはAzureファイル共有に保存されます。 ご自分の Windows ファイル サーバー上で変更されたファイルはご使用の Azure ファイル共有にレプリケートされます。オンプレミスのご使用のファイル サーバー上で階層化されたファイルは、ユーザーが要求したときにシームレスにダウンロードされます。 Storage
Azure Resource Manager Azure Resource Manager は、Azure の管理インターフェイスです。 Azure File Sync サーバー登録と同期サーバーの継続的なタスクを含むすべての管理呼び出しは、Azure Resource Manager を通じて行われます。 AzureResourceManager
Microsoft Entra ID Microsoft Entra ID (旧称 Azure AD) には、ストレージ同期サービスに対してサーバーの登録を承認するために必要なユーザー プリンシパルと、ご使用のクラウド リソースへのアクセスを Azure File Sync に許可するために必要なサービス プリンシパルが含まれています。 AzureActiveDirectory

Azure 内で Azure File Sync を使用している場合は、リージョンが異なっていても、ネットワーク セキュリティ グループ内でサービス タグ名を直接使用して、そのサービスに対するトラフィックを許可することができます。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。

オンプレミスの Azure File Sync を使用している場合は、サービス タグ API を使用して、ファイアウォールの許可リスト用の特定の IP アドレス範囲を取得できます。 この情報を取得するには、次の 2 つの方法があります。

  • サービス タグをサポートするすべての Azure サービスの最新の IP アドレス範囲の一覧が、Microsoft ダウンロード センターに JSON ドキュメントの形式で毎週公開されています。 各 Azure クラウドには、そのクラウドに関連する IP アドレス範囲が記載された独自の JSON ドキュメントが存在します。
  • サービス タグ検出 API (プレビュー) を使用すると、サービス タグの現在の一覧をプログラムで取得できます。 プレビューの段階では、サービス タグ検出 API によって返される情報は、Microsoft ダウンロード センターに公開されている JSON ドキュメントから返される情報よりも古い場合があります。 API サーフェスは、ご自分の自動化の設定に基づいて使用できます。

サービス タグ API を利用してご使用のサービスのアドレスを取得する方法の詳細については、「Azure File Sync IP アドレスの許可リスト」を参照してください。

仮想プライベート ネットワークまたは ExpressRoute でトラフィックをトンネリングする

組織によっては、セキュリティ レイヤーを追加したり、Azure との通信が決定的なルートに確実に従うようにしたりするために、VPN や ExpressRoute などのネットワーク トンネル経由で Azure と通信する必要があります。

オンプレミスのご使用のサーバーと Azure の間のトラフィックをトンネリングするために、Azure Files および Azure File Sync では次のメカニズムをサポートしています。

  • Azure VPN Gateway:VPNゲートウェイは、Azureの仮想ネットワークとインターネットを通じて別の場所(オンプレミスなど)との間で暗号化されたトラフィックを送信するための特定の種類の仮想ネットワークゲートウェイです。 Azure VPN Gatewayは、ストレージアカウントやその他のAzureリソースと共にリソースグループにデプロイするAzureリソースです。 Azure File SyncはオンプレミスのWindowsファイルサーバーで使うことを想定しているため、通常はサイトツーサイトVPNを使用しますが、技術的にはポイントツーサイトVPNを使うことも可能です。

    サイト間VPN接続は、Azureの仮想ネットワークと組織のオンプレミスネットワークを接続します。 サイト間VPN接続は、すべてのクライアントデバイスに対してAzureファイル共有にアクセスするのではなく、組織のネットワーク上でホストされているVPNサーバーやデバイスに対して一度だけVPN接続を設定できます。 サイト間VPN接続の展開を簡素化するには、「Azure Filesで使用するためのサイト間VPNの設定」をご覧ください。

  • ExpressRoute。これにより、Azure とインターネットを経由しないオンプレミス ネットワークの間に定義されたルート (プライベート接続) を作成できます。 ExpressRoute はオンプレミスのデータセンターと Azure の間の専用のパスを提供するため、ExpressRoute は、ネットワーク パフォーマンスが重要な考慮事項であるときに役立つことがあります。 ExpressRoute はまた、組織のポリシーまたは規制要件にクラウド内のリソースへの確定的なパスが必要な場合の適切なオプションでもあります。

SMB over QUIC (ネットワークプロトコル)

もし環境でポート445がブロックされている場合、VPNやExpressRouteの代替として SMBをQUIC経由で 利用できます。 SMB over QUIC では、ポート 443 上で QUIC トランスポート プロトコルを使用します。これは、ほとんどの組織やインターネット サービス プロバイダー (ISP) が HTTPS トラフィックをサポートするために開放しているポートです。 この機能により、通常はパブリックインターネット経由でファイル共有にリモートアクセスするために必要な多くのネットワーク構成が不要になります。

Azure File SyncでSMBをQUICより使うには:

  • Azure File Syncサーバーエンドポイントは、AzureのWindows Serverデータセンター:Azureエディション仮想マシン上で動作しなければなりません。
  • クライアントはWindows 11以降のものを使用している必要があります。

設定および設定の詳細については、 SMB over QUICを参照してください。

Azure Files と Azure File Sync のプライベート エンドポイント

Azure Files と Azure File Sync には、ストレージ アカウントとストレージ同期サービスを通じて提供される既定のパブリック エンドポイントに加えて、リソースごとに 1 つ以上のプライベート エンドポイントを設定するオプションが用意されています。 このオプションにより、VPNやExpressRouteを使い、オンプレミスからAzureの仮想ネットワーク内からプライベートかつ安全にAzureファイル共有に接続できます。 Azure リソースのプライベート エンドポイントを作成すると、そのリソースには、ご使用の仮想ネットワークのアドレス空間内からプライベート IP アドレスが与えられます。ちょうど、オンプレミスのご使用の Windows ファイル サーバーに、そのオンプレミス ネットワークの専用アドレス空間から IP アドレスが割り当てられるのと似ています。

個々のプライベート エンドポイントは、Azure 仮想ネットワークの特定のサブネットに関連付けられます。 ストレージ アカウントとストレージ同期サービスには、複数の仮想ネットワーク内のプライベート エンドポイントを使用することができます。

プライベート エンドポイントを使用することにより、次のことが可能となります。

  • オンプレミス ネットワークから、VPN または ExpressRoute 接続によるプライベート ピアリングを利用してご使用の Azure リソースに安全に接続します。
  • Azure Files と File Sync のパブリック エンドポイントを無効にして、ご使用の Azure リソースを保護します。既定では、プライベート エンドポイントを作成しても、パブリック エンドポイントへの接続はブロックされません。
  • 仮想ネットワーク (およびピアリングの境界) からのデータの流出をブロックできるようにすることで、仮想ネットワークのセキュリティを強化します。

プライベートエンドポイントを作成するには、「Azure File Syncのプライベートエンドポイントの設定」をご覧ください。

プライベート エンドポイントと DNS

プライベートエンドポイントを作成すると、Azureprivatelinkサブドメインに対応するプライベートDNSゾーンも作成または更新されます。 パブリック クラウド リージョンでは、これらの DNS ゾーンは、Azure Files の場合は privatelink.file.core.windows.net、Azure File Sync の場合は privatelink.afs.azure.net です。

注

この記事では、Azure パブリック リージョンを対象に、ストレージ アカウントの DNS サフィックス core.windows.net を使用しています。 これは、Azure ソブリン クラウド (Azure 米国政府機関 クラウドや 21Vianet によって運営される Microsoft Azure クラウドなど) にも当てはまります。ご利用の環境の適切なサフィックスに置き換えてください。

ストレージアカウントとストレージ同期サービスのためにプライベートエンドポイントを作成すると、AzureはそれぞれのプライベートDNSゾーンにAレコードを作成します。 Azureまた、公開DNSエントリを更新し、通常の完全修飾ドメイン名が関連するprivatelink名のCNAMEになるようにします。 この構成により、リクエスターが仮想ネットワーク内にいる場合は完全に限定されたドメイン名がプライベートエンドポイントのIPアドレスを指し、リクエスターが仮想ネットワーク外にいる場合はパブリックエンドポイントのIPアドレスを指すことができます。

Azure Files の場合、各プライベート エンドポイントには、storageaccount.privatelink.file.core.windows.net というパターンに従った 1 つの完全修飾ドメイン名が割り当てられ、プライベート エンドポイントの 1 つのプライベート IP アドレスにマップされます。 Azure File Sync の場合、各プライベート エンドポイントには、Azure File Sync が公開する 4 つの異なるエンドポイント (管理、同期 (プライマリ)、同期 (セカンダリ)、監視) の 4 つの完全修飾ドメイン名があります。 これらのエンドポイントの完全修飾ドメイン名は、通常、名前に ASCII 以外の文字が含まれている場合を除き、ストレージ同期サービスの名前に従います。 たとえば、ストレージ同期サービス名が米国西部 2 リージョン内で mysyncservice である場合、対応するエンドポイントは mysyncservicemanagement.westus2.afs.azure.net、mysyncservicesyncp.westus2.afs.azure.net、mysyncservicesyncs.westus2.afs.azure.net、mysyncservicemonitoring.westus2.afs.azure.net になります。 ストレージ同期サービスの各プライベート エンドポイントには、4 つの異なる IP アドレスが含まれます。

Azure プライベート DNS ゾーンはプライベート エンドポイントを含む仮想ネットワークに接続されているため、Azure VM の PowerShell から Resolve-DnsName コマンドレットを呼び出すことによって、DNS 構成を確認できます (または、Windows と Linux で nslookup )。

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

この例では、ストレージ アカウント storageaccount.file.core.windows.net が、プライベート エンドポイントのプライベート IP アドレス (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

同じコマンドをオンプレミスから実行した場合、同じストレージ アカウント名が、ストレージ アカウントのパブリック IP アドレスに解決されることがわかります。storageaccount.file.core.windows.net は storageaccount.privatelink.file.core.windows.net の CNAME レコードで、さらにそれが、ストレージ アカウントをホストする Azure ストレージ クラスターの CNAME レコードになっています。

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

この構成は、Azure FilesとAzure File Syncがそれぞれのリソースごとに公開エンドポイントと1つ以上のプライベートエンドポイントの両方を公開できることを反映しています。 リソースの完全適格ドメイン名がプライベートエンドポイントのIPアドレスに解決されるようにするには、オンプレミスのDNSサーバーを設定する必要があります。 この作業はいくつかの方法で達成できます。

  • ご使用のクライアント上の hosts ファイルを変更して、ご自分のストレージ アカウントとストレージ同期サービスの完全修飾ドメイン名が目的のプライベート IP アドレスに解決されるようにします。 この方法は、プライベート エンドポイントにアクセスする必要があるすべてのクライアントに対してこれらの変更を行う必要が生じるため、運用環境では実行しないことを強くお勧めします。 ご使用のプライベート エンドポイントやリソースに対する変更 (削除や変更など) は、自動的には処理されません。
  • オンプレミスのご使用のサーバー上に privatelink.file.core.windows.net および privatelink.afs.azure.net の DNS ゾーンと、ご使用の Azure リソースの A レコードを作成します。 この方法の利点は、オンプレミス環境内のクライアントを個別に構成しなくても、クライアントが自動的に Azure リソースを解決できるようになることです。 ただし、このソリューションは、変更が反映されないため、hosts ファイルの変更に対しても同様に脆弱です。 この解決策は完璧ではありませんが、環境によっては最適な選択肢となりえます。
  • core.windows.net と afs.azure.net ゾーンをオンプレミスのご使用の DNS サーバーから Azure のご自分のプライベート DNS ゾーンに転送します。 Azure のプライベート DNS ホストには、特殊な IP アドレス (168.63.129.16) でアクセスできますが、このアドレスには、Azure のプライベート DNS ゾーンにリンクされた仮想ネットワーク内からしかアクセスできません。 この制限を回避するには、仮想ネットワーク内で追加の DNS サーバーを実行し、core.windows.net と afs.azure.net を対応する Azure プライベート DNS ゾーンに転送できます。 この設定を簡素化するために、MicrosoftはPowerShellコマンドレットを提供しており、Azure仮想ネットワーク内のDNSサーバーを自動展開し、必要に応じて設定します。 DNS転送の設定方法については、「Azure FilesでDNSの設定」をご覧ください。

転送中の暗号化

Azure File Sync エージェントからご使用の Azure ファイル共有またはストレージ同期サービスへの接続は、常に暗号化されます。 Azure ストレージ アカウントには、Azure Files (およびストレージ アカウント外で管理されているその他の Azure ストレージ サービス) への通信に対する転送中の暗号化の要求を無効にする設定がありますが、この設定を無効にしても、Azure Files と通信する際の Azure File Sync の暗号化には影響しません。 既定では、すべての Azure ストレージ アカウントで転送中の暗号化が有効になっています。

暗号化の伝達に関する詳細は、「Azureストレージでの安全な転送が必要」をご覧ください。

関連項目

  • Last updated on