Azure Files の DNS 転送の構成

  • [アーティクル]

Azure Files では、ファイル共有を含むストレージ アカウントのプライベート エンドポイントを作成することができます。 プライベート エンドポイントは、多くの異なるアプリケーションで役立ちますが、プライベート ピアリングを使用する VPN または ExpressRoute 接続を使って、オンプレミス ネットワークから Azure ファイル共有に接続する場合に特に便利です。

ストレージ アカウントへの接続がネットワーク トンネルを経由するようにするには、ストレージ アカウントの完全修飾ドメイン名 (FQDN) がプライベート エンドポイントのプライベート IP アドレスに解決される必要があります。 これを実現するには、ストレージ エンドポイント サフィックス (パブリック クラウド リージョンのcore.windows.net) を、仮想ネットワーク内からアクセスできる Azure プライベート DNS サービスに転送する必要があります。 このガイドでは、ストレージ アカウントのプライベート エンドポイント IP アドレスに適切に解決されるように、DNS 転送を設定して構成する方法を示します。

この記事で説明されている手順を行う前に、「Azure Files のデプロイの計画」および「Azure Files のネットワークに関する考慮事項」をお読みいただくよう強くお勧めします。

適用対象

ファイル共有の種類 SMB NFS
Standard ファイル共有 (GPv2)、LRS/ZRS はい いいえ
Standard ファイル共有 (GPv2)、GRS/GZRS はい いいえ
Premium ファイル共有 (FileStorage)、LRS/ZRS はい はい

概要

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 ゾーンは、追加された仮想ネットワークにリンクされます。その場合、ストレージ アカウントのプライベート エンドポイントのプライベート IP アドレス用の A レコード エントリに storageaccount.file.core.windows.net をマップする CNAME レコードを使用します。 これにより、仮想ネットワーク内で 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 Private Resolver の使用: VM ベースの DNS サーバーをデプロイしない場合は、Azure DNS Private Resolver を使用して同じタスクを実行できます。

Azure Files だけでなく、他の Azure ストレージ サービス (Azure Blob storage、Azure Table storage、Azure Queue storage など) に対する DNS 名前解決要求が、Azure のプライベート DNS サービスに転送されます。 必要に応じて、他の Azure サービスのエンドポイントをさらに追加できます。

前提条件

Azure Files への DNS 転送を設定する前に、次が必要です。

VM を使用して DNS 転送を構成する

Azure 仮想ネットワーク内に DNS サーバーが既に配置されている場合、または組織で使用される任意の方法で独自の DNS サーバー VM に単にデプロイする場合、組み込みの DNS サーバーの PowerShell コマンドレットを使用して、DNS を構成できます。

Azure で仮想マシンを使用して DNS 転送を構成するためのネットワーク トポロジを示す図。

重要

このガイドでは、オンプレミス環境の Windows Server 内で DNS サーバーを使用することを前提としています。 ここで説明されているすべての手順は、Windows DNS Server だけでなく、どの 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 Private Resolver を使用して DNS 転送を構成する

DNS サーバー VM をデプロイしない場合は、Azure DNS Private Resolver を使用して同じタスクを実行できます。 「Azure portal を使用して Azure DNS Private Resolver を作成する」を参照してください。

Azure DNS Private Resolver を使用して DNS 転送を構成するためのネットワーク トポロジを示す図。

Azure の DNS サーバーの IP アドレスを指す代わりに、リゾルバーの受信エンドポイント IP アドレスを指す点が異なることを除いて、オンプレミスの DNS サーバーの構成方法に違いはありません。 リゾルバーは、既定で Azure プライベート DNS サーバーにクエリを転送するため、構成は必要ありません。 リゾルバーがデプロイされている VNet にプライベート DNS ゾーンがリンクされている場合、リゾルバーはその DNS ゾーンのレコードで応答できます。

警告

core.windows.net ゾーンのフォワーダーを構成すると、このパブリック ドメインのすべてのクエリが Azure DNS インフラストラクチャに転送されます。 これにより、プライベート エンドポイントで構成されている別のテナントのストレージ アカウントにアクセスしようとすると、Azure DNS がプライベート DNS ゾーンに存在しない CNAME を持つストレージ アカウントのパブリック名のクエリに応答してしまう問題が発生します。 この問題の回避策は、環境内にテナント間プライベート エンドポイントを作成して、そのストレージ アカウントに接続することです。

Azure DNS Private Resolver を使用して 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 フォワーダーが正しく適用されているかどうかをテストする前に、Clear-DnsClientCache を使用して、ローカル ワークステーションの DNS キャッシュをクリアすることをお勧めします。 ストレージ アカウントの完全修飾ドメイン名 (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     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

SMB ファイル共有をマウントする場合、Test-NetConnection コマンドを使用して、ストレージ アカウントへの TCP 接続が正常に確立されたことを確認することもできます。

Test-NetConnection -ComputerName storageaccount.file.core.windows.net -CommonTCPPort SMB

関連項目