Azure 虛擬 WAN 中的 Private Link 和 DNS 指南

Azure Private Link

Azure DNS

Azure 防火牆

Azure 虛擬 WAN

Azure Private Link 可讓用戶端直接從私人虛擬網路存取 Azure 平臺即服務（PaaS）服務，而不需使用公用 IP 位址。針對每個服務，您會設定使用來自您網路的私人IP位址的私人端點。用戶端接著可以使用私人端點私下連線至服務。

用戶端會繼續使用服務的完整功能變數名稱（FQDN）來與其連線。您可以在網路中設定 DNS，將服務的 FQDN 解析為私人端點的私人 IP 位址。

您的網路設計，特別是 DNS 設定，是支援服務私人端點連線的關鍵因素。本文是一系列文章之一，提供實作各種 Private Link 案例的指引。即使沒有任何案例完全符合您的情況，您也應該能夠調整設計以符合您的需求。

啟動網路拓撲

起始網路拓撲是一種網路架構，可作為這一系列文章中所有案例的起點。此架構是使用 Azure 虛擬 WAN 的典型中樞輪輻網路。

圖 1：針對所有私人端點和 DNS 案例啟動網路拓撲

下載此架構的 Visio 檔案。 此拓撲具有下列特性：

它是使用 Azure 虛擬 WAN 實作的中樞輪輻網路。
有兩個區域，每個區域都有一個區域 Azure 防火牆安全的虛擬中樞。
每個安全的區域虛擬中樞都有下列 Azure 虛擬網絡連線的安全性設定：
- 因特網流量：受 Azure 防火牆 保護 - 流向因特網的所有流量都會流經區域中樞防火牆。
- 私人流量：受 Azure 防火牆 保護 - 從輪輻傳輸至輪輻的所有流量都會流經區域中樞防火牆。
每個區域虛擬中樞都會受到 Azure 防火牆保護。區域中樞防火牆具有下列設定：
- DNS 伺服器： 預設（Azure 提供） - 區域中樞防火牆會在規則集合中明確使用 Azure DNS 進行 FQDN 解析。
- DNS Proxy： 已啟用 - 區域中樞防火牆會回應埠 53 上的 DNS 查詢。它會將查詢轉送至 Azure DNS 以取得未快取的值。
- 防火牆會將規則評估與 DNS Proxy 要求記錄至相同區域中的 Log Analytics 工作區。記錄這些事件是常見的網路安全性記錄需求。
每個連線的虛擬網路輪輻都會將其預設 DNS 伺服器設定為區域中樞防火牆的私人IP位址。否則，FQDN 規則評估可能會不同步。

多重區域路由

當有多個安全的虛擬中樞時，安全虛擬 WAN 中樞對中樞間連線的支援有限。這項限制會影響多中樞、區域內和跨區域案例。因此，網路拓撲不會直接協助篩選透過 Azure 防火牆的私人跨區域流量。這項功能的支援是使用虛擬 WAN 中樞路由意圖和路由原則來提供。本功能目前為預覽狀態。

針對這一系列文章，假設內部安全流量不會周遊多個中樞。必須周遊多個中樞的流量，必須在不會透過安全虛擬中樞篩選私人流量的平行拓撲上執行此動作，但讓它改為通過。

新增輪輻網路

當您新增輪輻網路時，它們會遵循起始網路拓撲中定義的條件約束。具體而言，每個輪輻網路都會與其區域中樞的預設路由表相關聯，且防火牆會設定為保護因特網和私人流量。下列螢幕快照顯示組態範例：

圖 2：虛擬中樞中虛擬網路連線的安全性設定

關鍵挑戰

起始的網路拓撲會為私人端點設定 DNS 建立挑戰。

雖然虛擬 WAN 的使用提供受控中樞體驗，但取捨是，影響虛擬中樞的設定或將更多元件新增至其中的能力有限。傳統的中樞輪輻拓撲可讓您隔離輪輻中的工作負載，同時在自我管理中樞共用常見的網路服務，例如 DNS 記錄。您通常會將私人 DNS 區域連結至中樞網路，讓 Azure DNS 可以解析用戶端的私人端點 IP 位址。

不過，無法將私人 DNS 區域連結至虛擬 WAN 中樞，因此在中樞內發生的任何 DNS 解析都不知道私人區域。具體來說，這是 Azure 防火牆的問題，工作負載輪輻的已設定 DNS 提供者，其使用 DNS 進行 FQDN 解析。

當您使用虛擬 WAN 中樞時，將私人 DNS 區域連結至工作負載預期 DNS 解析的輪輻虛擬網路似乎直覺。不過，如架構所述，DNS Proxy 會在區域防火牆上啟用，而且預期所有支點都會使用其區域防火牆作為 DNS 來源。 Azure DNS 會從防火牆呼叫，而不是從工作負載的網路呼叫，因此工作負載網路上的任何私人 DNS 區域連結都不會用於解析中。

注意

若要將區域防火牆設定為輪輻的 DNS 提供者，請將輪輻虛擬網路上的自定義 DNS 伺服器設定為指向防火牆的私人 IP，而不是指向一般的 Azure DNS 值。

鑒於在區域防火牆上啟用 DNS Proxy 所產生的複雜度，讓我們來檢閱啟用 DNS Proxy 的原因。

Azure 防火牆網路規則支援 FQDN 型限制，以便更精確地控制應用程式規則無法處理的輸出流量。此功能需要啟用 DNS Proxy。常見的用法是將網路時間通訊協定（NTP）流量限制為已知的端點，例如 time.windows.com。
安全性小組可以受益於 DNS 要求記錄。 Azure 防火牆具有 DNS 要求記錄的內建支援，因此要求所有輪輻資源都使用 Azure 防火牆作為其 DNS 提供者，可確保廣泛的記錄涵蓋範圍。

為了說明挑戰，下列各節將說明兩個組態。有一個簡單的範例可以運作，而且更複雜的範例，但失敗是有啟發性的。

工作案例

下列範例是基本的私人端點組態。虛擬網路包含用戶端，該用戶端需要透過私人端點使用PAAS服務。連結至虛擬網路的私人 DNS 區域有 A 記錄，會將服務的 FQDN 解析為私人端點的私人 IP 位址。下圖說明流程。

圖 3：私人端點的基本 DNS 組態

下載此架構的 Visio 檔案。

用戶端發出要求來 stgworkload00.blob.core.windows.net。
Azure DNS 是虛擬網路的已設定 DNS 伺服器，會針對 stgworkload00.blob.core.windows.net 的 IP 位址進行查詢。

從虛擬機執行下列命令說明 VM 已設定為使用 Azure DNS（168.63.129.16）作為 DNS 提供者。
```
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 的記錄。
由於 A 記錄存在於對應 FQDN 的私人 DNS 區域中， stgworkload00.privatelink.blob.core.windows.net因此會傳回私人 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 區域連結至虛擬 WAN 中樞。因此，當用戶端設定為使用防火牆作為其 DNS 伺服器時，DNS 要求會從虛擬中樞內轉送至 Azure DNS，而虛擬中樞沒有連結的私人 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    
```
防火牆已啟用 DNS Proxy，並具有將要求轉送至 Azure DNS 的預設設定。要求會轉送至 Azure DNS。
Azure DNS 無法解析 stgworkload00.blob.core.windows.net 為私人端點的私人 IP 位址，因為：
1. 私人 DNS 區域無法連結至虛擬 WAN 中樞。
2. Azure DNS 不知道連結至工作負載虛擬網路的私人 DNS 區域，因為工作負載虛擬網路的已設定 DNS 伺服器 Azure 防火牆。 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 防火牆 Proxy 處理 DNS 查詢，因此我們可以記錄這些查詢。以下是 #DD2CD545C18984CBC90549CC7B8390828 DNS Proxy 記錄的範例。
```
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 位址，而且無法建立記憶體帳戶的私人連線。

預期會有上述行為。案例所解決的問題。

案例

雖然此問題的解決方案很類似，但逐步解說常見的工作負載案例會顯示解決方案如何解決各種情況的需求。大部分案例是由透過私人端點存取一或多個 PaaS 服務的用戶端所組成。它們會遵循起始的網路拓撲，但有不同的工作負載需求。案例只會從存取單一區域 PaaS 服務的客戶端開始。它們會以累加方式變得更複雜，並新增更多網路可見度、區域和 PaaS 服務。

在大部分情況下，用戶端會實作為 VM，而用戶端存取的 PaaS 服務則是記憶體帳戶。您應該將 VM 視為任何在虛擬網路上公開 NIC 的 VM，例如虛擬機器擴展集、Azure Kubernetes Service 節點，或任何其他以類似方式路由傳送的服務。

重要

Azure 儲存體帳戶的 Private Link 實作可能會與其他 PaaS 服務以微妙的方式不同，但對許多人來說，它確實符合一致。例如，某些服務會在透過 Private Link 公開時移除 FQDN 記錄，這可能會導致不同的行為，但這類差異通常不是這些案例解決方案的一個因素。

每個案例都會以所需的結束狀態開始，並詳細說明從起始網路拓撲到所需結束狀態所需的設定。每個案例的解決方案都會利用虛擬中樞擴充模式。此模式說明如何以隔離且安全的方式公開共用服務，做為區域中樞的概念延伸模組。下表包含虛擬中樞延伸模組模式和案例的連結。

指南	描述
單一區域，專用 PaaS	單一區域中的工作負載會存取一個專用的 PaaS 資源。

下一步

讀取單一區域、專用的 PaaS 資源案例

共用方式為

Azure 虛擬 WAN 中的 Private Link 和 DNS 指南