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

Azure Private Link

Azure DNS

Azure Firewall

Azure バーチャル 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 ゾーンリンクは解決には使用されません。

注

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

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

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

課題を説明するために、次のセクションでは 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 はワークロード VNet にリンクされているため、Azure DNS にはワークロード VNet からのレコードが応答に組み込まれます。
FQDN ( stgworkload00.privatelink.blob.core.windows.net) をプライベートエンドポイントのプライベート IP にマップするプライベート DNS ゾーンに A レコードが存在するため、プライベート 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 から次のコマンドを実行すると、仮想ハブファイアウォールを DNS プロバイダーとして使用するように VM が構成されていることが示されています。
```
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 サービスはストレージアカウントです。仮想マシンスケールセット、Azure Kubernetes Service ノード、同様の方法でルーティングされるその他のサービスなど、仮想ネットワーク上に公開されている NIC を持つ Azure リソースのスタンドインとして VM を検討する必要があります。

重要

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

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

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

次のステップ

単一リージョンの専用 PaaS リソースシナリオの読み取り

次の方法で共有

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

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