Azure Virtual WAN での Private Link と DNS のガイド

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Azure Private Link を使用すると、クライアントはパブリック IP アドレス指定を使用せずに、プライベート仮想ネットワークから直接 Azure サービスとしてのプラットフォーム (PaaS) サービスにアクセスできます。サービスごとに、ネットワークのプライベート IP アドレスを使用するプライベートエンドポイントを構成します。その後、クライアントはプライベートエンドポイントを使用して、サービスにプライベートに接続できます。

クライアントは引き続き、サービスの完全修飾ドメイン名 (FQDN) を使用して接続します。サービスの FQDN をプライベートエンドポイントのプライベート IP アドレスに解決するように、ネットワーク内の DNS を構成します。

ネットワークの設計と、特に DNS 構成は、サービスへのプライベートエンドポイント接続をサポートする上で重要な要素です。この記事は、Private Link のさまざまなシナリオの実装に関するガイダンスを提供する一連の記事の 1 つです。お客様の状況にどのシナリオも正確に一致しない場合でも、設計を調整してお客様のニーズを満たすことができます。

開始ネットワークトポロジ

開始ネットワークトポロジは、この一連の記事のすべてのシナリオの開始点として機能するネットワークアーキテクチャです。このアーキテクチャは、Azure Virtual WAN を使用する一般的なハブスポークネットワークです。

図 1: すべてのプライベートエンドポイントと DNS シナリオの開始ネットワークトポロジ

このアーキテクチャの Visio ファイルをダウンロードします。 このトポロジには次の特徴があります。

Azure Virtual WAN を使用して実装されるハブスポークネットワークです。
2 つのリージョンがあり、それぞれにリージョンの Azure Firewall によるセキュリティ保護付き仮想ハブがあります。
セキュリティ保護された各リージョン仮想ハブには、Azure Virtual Network 接続のための次のセキュリティ設定があります。
- インターネットトラフィック: Azure Firewall によるセキュリティ保護 - インターネットへのすべてのトラフィックが、リージョンハブファイアウォールを通過します。
- プライベートトラフィック: Azure Firewall によるセキュリティ保護 - スポーク間で転送されるすべてのトラフィックが、リージョンハブファイアウォールを通過します。
それぞれのリージョン仮想ハブは、Azure Firewall でセキュリティ保護されます。リージョンハブファイアウォールには、次の設定があります。
- DNS サーバー: 既定 (Azure 提供) - リージョンハブファイアウォールは、規則コレクション内の FQDN 解決に Azure DNS を明示的に使用します。
- DNS プロキシ: 有効 - リージョンハブファイアウォールはポート 53 の DNS クエリに応答します。キャッシュされていない値については、クエリを Azure DNS に転送します。
- ファイアウォールは、ルールの評価と DNS プロキシ要求を、同じリージョン内の Log Analytics ワークスペースにログします。これらのイベントをログすることは、ネットワークセキュリティログの一般的な要件です。
接続された各仮想ネットワークスポークには、リージョンハブファイアウォールのプライベート IP アドレスとして構成された既定の DNS サーバーがあります。そうでない場合、FQDN ルールの評価が同期されなくなっている可能性があります。

複数リージョンのルーティング

セキュリティで保護された Virtual WAN ハブでは、複数のセキュリティ保護付き仮想ハブがある場合、ハブ間接続のサポートが制限されます。この制限は、マルチハブ、リージョン内、リージョン間のシナリオに影響します。そのため、ネットワークトポロジは、Azure Firewall を介したプライベートなリージョン間トラフィックのフィルター処理を直接促進するわけではありません。この機能のサポートは、Virtual WAN ハブのルーティング意図とルーティングポリシーを使用して提供されます。この機能は現在プレビューの段階です。

この一連の記事では、内部のセキュリティで保護されたトラフィックが複数のハブを通過しないことを前提としています。複数のハブを通過する必要があるトラフィックは、セキュリティ保護付き仮想ハブを介してプライベートトラフィックをフィルター処理せず、そのまま通過できる並列トポロジで行う必要があります。

スポークネットワークの追加

スポークネットワークを追加する場合、スポークネットワークは開始ネットワークトポロジで定義されている制約に従います。具体的には、各スポークネットワークはリージョンハブ内の既定のルーティングテーブルに関連付けられています。ファイアウォールは、インターネットトラフィックとプライベートトラフィックの両方をセキュリティで保護するように構成されています。次のスクリーンショットは、構成の例を示しています。

図 2: 仮想ハブ内の仮想ネットワーク接続のセキュリティ構成

主な課題

開始ネットワークトポロジでは、プライベートエンドポイントの DNS の構成に課題が発生します。

Virtual WAN を使用すると、ハブを管理する機能を入手できますが、その代わり、仮想ハブの構成に影響を与えたり、仮想ハブさらにコンポーネントを追加する機能が制限されます。従来のハブスポークトポロジを使用すると、スポーク内のワークロードを分離しながら、セルフマネージドハブで DNS レコードなどの共通のネットワークサービスを共有できます。通常、Azure DNS がクライアントのプライベートエンドポイント IP アドレスを解決できるように、プライベート DNS ゾーンをハブネットワークにリンクします。

ただし、プライベート DNS ゾーンを Virtual WAN ハブにリンクすることはできません。そのため、ハブ内で発生する DNS 解決でプライベートゾーンは認識されません。具体的に、これは FQDN 解決に DNS を使用しているワークロードスポーク用に構成された DNS プロバイダーである Azure Firewall で問題となります。

Virtual WAN ハブを使用する場合、ワークロードで DNS 解決が想定されているスポーク仮想ネットワークにプライベート DNS ゾーンをリンクするのは直感的に思えるでしょう。ただし、アーキテクチャで説明したように、DNS プロキシはリージョンファイアウォールで有効になっており、すべてのスポークが DNS ソースとしてリージョンファイアウォールを使用することが期待されます。 Azure DNS は、ワークロードのネットワークではなくファイアウォールから呼び出されるため、ワークロードネットワーク上のプライベート DNS ゾーンリンクは解決で使用されません。

Note

リージョンファイアウォールをスポークの DNS プロバイダーとして構成するには、スポーク仮想ネットワーク上のカスタム DNS サーバーを、通常の Azure DNS 値ではなく、ファイアウォールのプライベート IP を指すように設定します。

リージョンファイアウォールで DNS プロキシを有効にした結果として生じる複雑性を踏まえて、それを有効にする理由について確認しましょう。

Azure Firewall ネットワークルールでは、アプリケーションルールが処理しないエグレストラフィックをより正確に制御するために、FQDN ベースの制限がサポートされます。この機能を使用するには、その DNS プロキシが有効になっている必要があります。一般的な用途は、ネットワークタイムプロトコル (NTP) トラフィックを time.windows.comなどの既知のエンドポイントに制限することです。
セキュリティチームは、DNS 要求ログのメリットを得られます。 Azure Firewall には DNS 要求ログのサポートが組み込まれているため、すべてのスポークリソースが Azure Firewall を DNS プロバイダーとして使用するよう要求することで、広範なログ範囲が確保されます。

課題を説明するために、次のセクションでは 2 つの構成について説明します。機能する簡単な例があります。機能しないより複雑な例もあり、失敗例から学ぶことができます。

機能するシナリオ

次の例は、基本的なプライベートエンドポイント構成です。仮想ネットワークには、プライベートエンドポイントによる PAAS サービスの使用を必要とするクライアントが含まれています。仮想ネットワークにリンクされているプライベート DNS ゾーンには、サービスの FQDN をプライベートエンドポイントのプライベート IP アドレスに解決する A レコードがあります。次の図は、このフローを示しています。

図 3: プライベートエンドポイントの基本的な DNS 構成

このアーキテクチャの Visio ファイルをダウンロードします。

クライアントは stgworkload00.blob.core.windows.net に要求を発行します。
仮想ネットワーク用に構成された DNS サーバーである Azure DNS に対して、stgworkload00.blob.core.windows.net の IP アドレスが照会されます。

仮想マシン (VM) から次のコマンドを実行すると、VM が DNS プロバイダーとして Azure DNS (168.63.129.16) を使用するように構成されていることが示されます。
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
プライベート DNS ゾーン privatelink.blob.core.windows.net は Workload VNet にリンクされているため、Azure DNS は Workload VNet からのレコードを応答に組み込みます。
FQDN stgworkload00.privatelink.blob.core.windows.net をプライベートエンドポイントのプライベート IP にマップする A レコードがプライベート DNS ゾーンに存在するため、プライベート IP アドレス 10.1.2.4 が返されます。

VM から次のコマンドを実行すると、ストレージアカウントの FQDN がプライベートエンドポイントのプライベート IP アドレスに解決されます。
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
要求はプライベートエンドポイントのプライベート IP アドレスに発行されます。この場合、10.1.2.4 です。
要求は、Private Link 経由でストレージアカウントにルーティングされます。

この設計は、Azure DNS が以下であるという理由で機能します。

仮想ネットワーク用に構成された DNS サーバーである。
リンクされたプライベート DNS ゾーンを認識している。
ゾーンの値を使用して DNS クエリを解決する。

機能しないシナリオ

次の例は、開始ネットワークトポロジでプライベートエンドポイントを使用する単純な試みです。プライベート DNS ゾーンを Virtual WAN ハブにリンクすることはできません。そのため、クライアントが DNS サーバーとしてファイアウォールを使用するように構成されている場合、DNS 要求は、リンクされたプライベート DNS ゾーンを持たない仮想ハブ内から Azure DNS に転送されます。 Azure DNS では、パブリック IP アドレスである既定値を指定する以外に、クエリを解決する方法が認識されません。

図 4: 開始ネットワークトポロジでプライベートエンドポイントを使用する単純な試み

このアーキテクチャの Visio ファイルをダウンロードします。

クライアントは stgworkload00.blob.core.windows.net に要求を発行します。

VM から次のコマンドを実行すると、VM が DNS プロバイダーとして仮想ハブファイアウォールを使用するように構成されていることが示されます。
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
ファイアウォールでは、要求を Azure DNS に転送するための既定の設定で DNS プロキシが有効になっています。要求は Azure DNS に転送されます。
以下の理由で、Azure DNS は stgworkload00.blob.core.windows.net をプライベートエンドポイントのプライベート IP アドレスに解決できません。
1. プライベート DNS ゾーンを Virtual WAN ハブにリンクすることができない。
2. ワークロード仮想ネットワーク用に構成された DNS サーバーが Azure Firewall であるため、Azure DNS はワークロード仮想ネットワークにリンクされているプライベート DNS ゾーンを認識しない。 Azure DNS は、ストレージアカウントのパブリック IP アドレスで応答します。
VM から次のコマンドを実行すると、ストレージアカウントの FQDN がストレージアカウントのパブリック IP に解決されます。
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Azure Firewall が DNS クエリをプロキシしているため、ログできます。 Azure Firewall DNS プロキシログの例を次に示します。
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
クライアントは、Private Link エンドポイントのプライベート IP アドレスを受信せず、ストレージアカウントへのプライベート接続を確立できません。

上記は予期される動作です。この問題は、シナリオで対処します。

シナリオ

この問題の解決策は似ていますが、一般的なワークロードシナリオを見ると、ソリューションがさまざまな状況の要件にどのように対処するかがわかります。ほとんどのシナリオは、プライベートエンドポイント経由で 1 つ以上の PaaS サービスにアクセスするクライアントで構成されます。これらは開始ネットワークトポロジに準拠していますが、ワークロードの要件は異なります。シナリオは、単に、単一のリージョン PaaS サービスにアクセスするクライアントから始まります。ますます複雑になり、ネットワークの可視性、リージョン、PaaS サービスが追加されます。

ほとんどのシナリオでは、クライアントは VM として実装され、クライアントがアクセスする PaaS サービスはストレージアカウントです。 VM は、仮想ネットワーク上で公開されている NIC (Virtual Machine Scale Sets、Azure Kubernetes Service ノード、同様の方法でルーティングされるその他のサービスなど) を持つ Azure リソースのスタンドインと見なす必要があります。

重要

Azure Storage アカウントの Private Link の実装は、他の PaaS サービスとは微妙な点で異なる場合がありますが、多くの場合に適しています。たとえば、一部のサービスでは、Private Link を介して公開されている間に FQDN レコードが削除されるため、さまざまな動作が発生する可能性がありますが、このような違いは通常、これらのシナリオのソリューションの要因ではありません。

各シナリオは、目的の終了状態から始まり、開始ネットワークトポロジから目的の終了状態に到達するために必要な構成について詳しく説明します。すべてのシナリオに対するソリューションでは、仮想ハブ拡張機能パターンを利用します。このパターンでは、リージョンハブへの概念的拡張として、分離された安全な方法で共有サービスを公開する方法を説明します。次の表に、仮想ハブ拡張機能パターンとシナリオへのリンクを示します。

ガイド	説明
単一リージョン、専用 PaaS	単一リージョン内のワークロードは、1 つの専用 PaaS リソースにアクセスします。

次の手順

単一リージョンの専用 PaaS リソースのシナリオを読む

次の方法で共有

Azure Virtual WAN での Private Link と DNS のガイド