✔️ 適用対象:Microsoft.Storage リソース プロバイダーで作成されたクラシック SMB および NFS ファイル共有
✖️ :Microsoft.FileShares リソース プロバイダーで作成されたファイル共有は適用されません
Azure Files を使用すると、ファイル共有を含むストレージ アカウントのプライベート エンドポイントを作成できます。 多くの異なるアプリケーションに便利ですが、プライベート エンドポイントは、プライベート ピアリングを使用した VPN または ExpressRoute 接続を使用してオンプレミス ネットワークから Azure ファイル共有に接続する場合に特に便利です。
ストレージアカウントへの接続をネットワークトンネル経由で行うには、ストレージアカウントの完全限定ドメイン名(FQDN)がプライベートエンドポイントのプライベートIPアドレスに解決される必要があります。 この解決を実現するには、ストレージエンドポイントのサフィックス(パブリッククラウド地域ではcore.windows.net)を仮想ネットワーク内からアクセス可能なAzureプライベートDNSサービスに転送する必要があります。 この記事では、ストレージアカウントのプライベートエンドポイントIPアドレスに正しく解決するためのDNS転送の設定と設定方法を紹介しています。
始める前に、「Azure Filesのデプロイメント計画」と「Azure Filesネットワークの考慮事項」をご覧ください。
Azure FilesでのDNS転送の仕組み
Azure Files には、Azure ファイル共有にアクセスするための次の種類のエンドポイントが用意されています。
- パブリック エンドポイント。パブリック IP アドレスを持ち、世界中のどこからでもアクセスできます。
- プライベート エンドポイント。仮想ネットワーク内に存在し、その仮想ネットワークのアドレス空間内からのプライベート IP アドレスを持ちます。
- サービス エンドポイント。パブリック エンドポイントへのアクセスを特定の仮想ネットワークに制限します。 引き続きパブリック IP アドレスを使用してストレージ アカウントにアクセスしますが、アクセスできるのは、構成で指定した場所からのみ可能です。
パブリックおよびプライベート エンドポイントは、Azure ストレージ アカウントに存在します。 ストレージ アカウントは、複数のファイル共有だけでなく、BLOB コンテナーやキューなどのその他のストレージ リソースをデプロイできるストレージの共有プールを表す管理構造です。
すべてのストレージ アカウントには完全修飾ドメイン名 (FQDN) があります。 パブリック クラウド リージョンの場合、この FQDN は、storageaccount.file.core.windows.netがストレージ アカウントの名前であるパターン storageaccountに従います。 ワークステーションに共有をマウントするなど、この名前に対して要求を行うと、オペレーティング システムでは DNS 参照を実行し、完全修飾ドメイン名を、IP アドレスに解決させます。
既定では、 storageaccount.file.core.windows.net はパブリック エンドポイントの IP アドレスに解決されます。 ストレージ アカウントのパブリック エンドポイントは、他の多くのストレージ アカウントのパブリック エンドポイントをホストする Azure ストレージ クラスターでホストされます。 プライベート エンドポイントを作成すると、プライベート DNS ゾーンが追加された仮想ネットワークにリンクされ、CNAME レコードがストレージ アカウントのプライベート エンドポイントのプライベート IP アドレスの A レコード エントリに storageaccount.file.core.windows.net マッピングされます。 これにより、仮想ネットワーク内で storageaccount.file.core.windows.net FQDN を使用して、プライベート エンドポイントの IP アドレスに解決させることができます。
最終的な目的は、VPN や ExpressRoute 接続などのネットワーク トンネルを使用してオンプレミスからストレージ アカウント内でホストされている Azure ファイル共有にアクセスすることです。そのため、Azure Files サービスに対して行われた要求を Azure プライベート DNS サービスに転送するようにオンプレミスの DNS サーバーを構成する必要があります。
DNS 転送は、次の 2 つの方法のいずれかを構成できます。
DNS サーバー VM を使用する:azure 仮想ネットワーク内でホストされている DNS サーバー仮想マシンへの (または米国政府、ドイツ、または中国の国内クラウド用の適切なストレージ エンドポイント サフィックス) の
*.core.windows.netを設定します。 その後、この DNS サーバーは Azure のプライベート DNS サービスに要求を再帰的に転送します。これにより、ストレージ アカウントの FQDN が適切なプライベート IP アドレスに解決されます。 これは、仮想ネットワーク内でホストされているすべての Azure ファイル共有に対する 1 回限りの手順です。Azure DNS プライベート リゾルバーを使用する: VM ベースの DNS サーバーをデプロイしない場合は、Azure DNS プライベート リゾルバーを使用して同じタスクを実行できます。
Azure Files に加えて、他の Azure ストレージ サービス (Azure Blob Storage、Azure Table Storage、Azure Queue Storage など) に対する DNS 名前解決要求は、Azure のプライベート DNS サービスに転送されます。 必要に応じて、他の Azure サービスのエンドポイントを追加できます。
[前提条件]
Azure Files への DNS 転送を設定する前に、次のものが必要です。
- マウントするための Azure ファイル共有を含むストレージ アカウント。 ストレージ アカウントと Azure ファイル共有を作成する方法については、「 Azure ファイル共有の作成」を参照してください。
- ストレージ アカウントのプライベート エンドポイント。 プライベート エンドポイントの作成を参照してください。
- Azure PowerShell モジュールの 最新バージョン 。
VM を使用して DNS 転送を構成する
Azure 仮想ネットワーク内に DNS サーバーが既に配置されている場合、または組織が使用する方法によって独自の DNS サーバー VM をデプロイする場合は、組み込みの DNS サーバー PowerShell コマンドレットを使用して DNS を構成できます。
Important
この記事は、オンプレミス環境でWindows Server内のDNSサーバーを使用していることを前提としています。 ここで説明したすべての手順は、WindowsのDNSサーバーだけでなく、どのDNSサーバーでも実行できます。
オンプレミスの DNS サーバーで、 Add-DnsServerConditionalForwarderZoneを使用して条件付きフォワーダーを作成します。 この条件付きフォワーダーは、トラフィックを Azure に適切に転送する際に有効にするために、オンプレミスのすべての DNS サーバーにデプロイする必要があります。
<azure-dns-server-ip>エントリは、環境に適した IP アドレスに置き換えてください。
$vnetDnsServers = "<azure-dns-server-ip>", "<azure-dns-server-ip>"
$storageAccountEndpoint = Get-AzContext | `
Select-Object -ExpandProperty Environment | `
Select-Object -ExpandProperty StorageEndpointSuffix
Add-DnsServerConditionalForwarderZone `
-Name $storageAccountEndpoint `
-MasterServers $vnetDnsServers
Azure 仮想ネットワーク内の DNS サーバーでは、ストレージ アカウントの DNS ゾーンに対する要求が Azure プライベート DNS サービスに送信されるようにフォワーダーを配置する必要もあります。このサービスは、予約済みの IP アドレス 168.63.129.16によって前面に配置されます。 (別の PowerShell セッション内でコマンドを実行している場合は、必ず $storageAccountEndpoint を入力してください)。
Add-DnsServerConditionalForwarderZone `
-Name $storageAccountEndpoint `
-MasterServers "168.63.129.16"
Azure DNS プライベート リゾルバーを使用して DNS 転送を構成する
DNS サーバー VM をデプロイしない場合は、Azure DNS プライベート リゾルバーを使用して同じタスクを実行できます。 Azure portal を使用した Azure DNS プライベート リゾルバーの作成に関するページを参照してください。
オンプレミスの DNS サーバーを構成する方法に違いはありません。ただし、Azure の DNS サーバーの IP アドレスをポイントする代わりに、リゾルバーの受信エンドポイント IP アドレスをポイントする点が異なります。 リゾルバーは既定で Azure プライベート DNS サーバーにクエリを転送するため、構成は必要ありません。 プライベート DNS ゾーンがリゾルバーがデプロイされている VNet にリンクされている場合、リゾルバーはその DNS ゾーンのレコードに応答できます。
Warnung
core.windows.net ゾーンのフォワーダーを構成すると、このパブリック ドメインのすべてのクエリが Azure DNS インフラストラクチャに転送されます。 これにより、プライベート エンドポイントで構成されている別のテナントのストレージ アカウントにアクセスしようとすると、Azure DNS がプライベート DNS ゾーンに存在しない CNAME を持つストレージ アカウントのパブリック名のクエリに応答するため、問題が発生します。 この問題の回避策は、環境内にテナント間のプライベート エンドポイントを作成して、そのストレージ アカウントに接続することです。
Azure DNS プライベート リゾルバーを使用して DNS 転送を構成するには、オンプレミスの DNS サーバーでこのスクリプトを実行します。
<resolver-ip>をリゾルバーの受信エンドポイント IP アドレスに置き換えます。
$privateResolver = "<resolver-ip>"
$storageAccountEndpoint = Get-AzContext | `
Select-Object -ExpandProperty Environment | `
Select-Object -ExpandProperty StorageEndpointSuffix
Add-DnsServerConditionalForwarderZone `
-Name $storageAccountEndpoint `
-MasterServers $privateResolver
DNS転送が正常に動作しているか確認してください
DNSフォウワーダーが動作しているかどうかをテストする前に、ローカルワークステーションのDNSキャッシュを Clear-DnsClientCacheでクリアしてください。 ストレージ アカウントの FQDN を正常に解決できるかどうかをテストするには、 Resolve-DnsName または nslookupを使用します。
# Replace storageaccount.file.core.windows.net with the appropriate FQDN for your storage account.
# Note that the proper suffix (core.windows.net) depends on the cloud you're deployed in.
Resolve-DnsName -Name storageaccount.file.core.windows.net
名前解決が成功すれば、解決されたIPアドレスはストレージアカウントのプライベートエンドポイントのプライベートIPアドレスと一致します。
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
SMB ファイル共有をマウントする場合は、 Test-NetConnection コマンドを使用して、ストレージ アカウントへの TCP 接続が正常に確立できることを確認することもできます。
Test-NetConnection -ComputerName storageaccount.file.core.windows.net -CommonTCPPort SMB