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 構成は、サービスへのプライベートエンドポイント接続をサポートする上で重要な要素です。この記事は、Virtual WAN環境でのPrivate Link動作の理解に関するガイダンスを提供する一連の記事の 1 つです。一般的な DNS とルーティングの課題を示すために使用される意図的に制約された例など、いくつかのシナリオが示されています。どのシナリオも状況に正確に一致しない場合でも、ニーズに合わせて設計を調整できる必要があります。

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

開始ネットワークトポロジは、このシリーズのすべてのシナリオの基本アーキテクチャです。これは、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デプロイでは、inter-hub プライベートトラフィックは Azure Firewall を通過しません。代わりに、Azureは、組み込みのVirtual WANマネージドハブ間接続を使用します。これは、各ハブ内のセキュリティで保護されたトラフィックパスと並行して実行されます。つまり、ハブ間を移動するプライベートトラフィックは 自動的には検査されません。

ハブ間プライベートトラフィックを検査するAzure Firewallが必要な場合は、Private Traffic ルーティングポリシーを構成し、inter-hub 検査を有効にすることで、この動作を有効にすることができます。これにより、ハブ間のプライベートトラフィックが検査のためにAzure Firewall経由で転送されます。

この構成はより高度であり、 このシリーズの範囲外です。

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

スポークネットワークを追加するときは、開始ネットワークトポロジで定義されている制約を適用します。各スポークはリージョンハブの既定のルートテーブルに関連付け、Azure Firewallはインターネットトラフィックとプライベートトラフィックの両方をセキュリティで保護します。次のスクリーンショットは、構成例を示しています。

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

主な課題

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

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

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

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

Virtual WAN ハブはプライベート DNS ゾーンにリンクできないため、Private Linkシナリオでの DNS 解決の推奨されるアプローチは、ハブ拡張機能仮想ネットワークにデプロイされたプライベートリゾルバー Azure DNSです。これにより、Virtual WAN ハブに接続されているワークロードに対して、スケーラブルでゾーン対応のプライベート 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 レコードが削除されるため、動作が異なる可能性がありますが、このような違いは通常、これらのシナリオのソリューションの要因ではありません。

各シナリオは、目的の終了状態から始まり、開始ネットワークトポロジから目的の終了状態に取得するために必要な構成について詳しく説明します。このソリューションでは、仮想ハブ拡張機能パターンを使用します。このパターンでは、リージョンハブのセキュリティで保護された拡張機能として共有サービスを公開し、Virtual WAN環境のプライベートエンドポイントの DNS 解決用に Azure DNS Private Resolver を使用します。次の表に、仮想ハブ拡張機能パターンとシナリオへのリンクを示します。

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

次のステップ

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

フィードバック

このページはお役に立ちましたか?