共用方式為

診斷 Azure Key Vault 上的私人連結設定問題

  • 發行項

簡介

本文協助使用者診斷並解決 Key Vault 和私人連結功能的相關問題。 本指南提供設定方面的協助，例如讓私人連結第一次運作，或修正私人連結因某些變更而停止運作的情況。

如果您不熟悉此功能，請參閱整合 Key Vault 與 Azure Private Link。

本文涵蓋的問題

  • DNS 查詢仍傳回金鑰保存庫的公用 IP 位址，而不是使用私人連結功能時理應傳回的私人 IP 位址。
  • 由某個使用私人連結的用戶端提出的所有要求，因為逾時或網路錯誤而失敗，而且這不是間歇性問題。
  • 金鑰保存庫有私人 IP 位址，但要求仍收到 403 回應，內部錯誤碼為 ForbiddenByFirewall。
  • 您使用私人連結，但金鑰保存庫仍接受來自公用網際網路的要求。
  • 金鑰保存庫有兩個私人端點。 使用其中一個端點的要求正常運作，但使用另一個端點的其他要求卻失敗。
  • 您有另一個訂用帳戶、金鑰保存庫或虛擬網路使用私人連結。 您想要展開新的類似部署，但在這方面無法運用私人連結。

本文「未」涵蓋的問題

  • 發生間歇性連線問題。 在已知用戶端，有些要求很正常，而有些卻不正常。 間歇性問題通常不是起因於私人連結設定中的問題，而是網路或用戶端超載的徵兆。
  • 您使用的 Azure 產品支援 BYOK (攜帶您自己的金鑰)、CMK (客戶自控金鑰)，或存取金鑰保存庫中儲存的秘密。 當您在金鑰保存庫設定中啟用防火牆時，該產品無法存取金鑰保存庫。 請參閱產品特有的文件。 請確定文件中明確指出支援已啟用防火牆的金鑰保存庫。 如有需要，請連絡該特定產品的支援。

如何閱讀這篇文章

如果您不熟悉私人連結或正在評估複雜的部署，建議閱讀整篇文章。 否則，請根據您遇到的問題，自行選擇較有關的章節。

現在就開始吧！

1.確認您擁有用戶端連線

確認用戶端在虛擬網路上執行

本指南旨在協助您修正從應用程式程式碼到金鑰保存庫的連線。 例如，在 Azure 虛擬機器、Azure Service Fabric 叢集、Azure App Service、Azure Kubernetes Service (AKS) 及其他類似環境中執行的應用程式和指令碼。 本指南也適用於 Azure 入口網站 Web 使用者介面中執行的存取，此時由瀏覽器直接存取金鑰保存庫。

根據私人連結的定義，執行應用程式、指令碼或入口網站的電腦、叢集或環境，必須連線至已部署私人端點資源的虛擬網路。

如果應用程式、指令碼或入口網站在與網際網路相連的任意網路上執行，則本指南「不」適用，有可能無法使用私人連結。 Azure Cloud Shell 中執行的命令是在隨需提供的遠端 Azure 電腦中執行，而不是使用者瀏覽器，所以也受此限制。

如果您使用受控解決方案，請參閱特定文件

本指南「不」適用於 Microsoft 管理的解決方案，因為是由獨立於客戶虛擬網路的 Azure 產品存取金鑰保存庫。 這種情況的例子包括 Azure 儲存體或 Azure SQL 設定為待用加密、Azure 事件中樞以客戶提供的金鑰來加密資料、Azure Data Factory 存取金鑰保存庫中儲存的服務認證、Azure Pipelines 從金鑰保存庫擷取秘密，以及其他類似的情況。 在這些情況下，「您必須檢查產品是否支援已啟用防火牆的金鑰保存庫」。 通常是以 Key Vault 防火牆的信任的服務功能來執行此支援。 不過，基於各種原因，許多產品未列入信任的服務清單中。 在此情況下，請連絡產品專屬的支援。

一些 Azure 產品支援「vnet 插入」的概念。 簡言之，產品將網路裝置新增至客戶虛擬網路，而能夠像部署至虛擬網路一樣傳送要求。 Azure Databricks 是很明顯的例子。 這類產品可以使用私人連結對金鑰保存庫提出要求，本疑難排解指南可能有所幫助。

2.確認連線已獲核准且成功

下列步驟驗證私人端點連線是否獲核准且成功：

  1. 開啟 Azure 入口網站，然後開啟金鑰保存庫資源。
  2. 在左側功能表中，選取 [網路]。
  3. 選取 [私人端點連線] 索引標籤。這將會顯示所有私人端點連線及其各自的狀態。 如果沒有連線或虛擬網路的連線中斷，則您必須建立新的私人端點。 稍後再討論這點。
  4. 仍在 [私人端點連線] 中，找出您要診斷的連線，並確認 [線上狀態] 為已核准，且 [佈建狀態] 為成功。
    • 如果連線處於「擱置中」狀態，您可能只要核准即可。
    • 如果連線處於「已拒絕」、「失敗」、「錯誤」、「已中斷連線」或其他狀態，則完全無用，您必須建立新的私人端點資源。

最好刪除無用的連線，以保持情況單純。

3.確認金鑰保存庫防火牆已正確設定

重要

對於仍未使用私人連結的合法用戶端，變更防火牆設定可能會移除其存取權。 請務必了解防火牆設定中各項變更的影響。

私人連結功能只在封閉的虛擬網路中「授權」存取金鑰保存庫，以防止資料外流，這點很重要。 不會「移除」任何現有的存取權。 若要有效禁止從公用網際網路存取，您必須明確啟用金鑰保存庫防火牆：

  1. 開啟 Azure 入口網站，然後開啟金鑰保存庫資源。
  2. 在左側功能表中，選取 [網路]。
  3. 確定已選取頂端的 [防火牆與虛擬網路] 索引標籤。
  4. 如果您發現已選取 [允許來自所有網路的公用存取]，就明白外部用戶端為何還能存取金鑰保存庫。 如果您想要僅透過 Private Link 存取 Key Vault，請選取 [停用公用存取]。

下列敘述也適用於防火牆設定：

  • 私人連結功能未規定在金鑰保存庫防火牆設定中指定任何「虛擬網路」。 即使金鑰保存庫防火牆設定中未指定任何虛擬網路，也一定能使用金鑰保存庫的私人 IP 位址來提出所有要求 (請參閱下一節)。
  • 私人連結功能未規定在金鑰保存庫防火牆設定中指定任何 IP 位址。 同樣地，即使防火牆設定中未指定任何 IP 位址，也一定能使用金鑰保存庫的私人 IP 位址來提出所有要求。

如果您使用私人連結，則只有基於下列原因，才需要在金鑰保存庫防火牆中指定虛擬網路或 IP 位址：

  • 您有混合式系統，其中有些用戶端使用私人連結、有些使用服務端點、有些使用公用 IP 位址。
  • 您要轉換至私人連結。 在此情況下，一旦確認所有用戶端都使用私人連結，就應該從金鑰保存庫防火牆設定中移除虛擬網路和 IP 位址。

4.確定金鑰保存庫具有私人 IP 位址

私人和公用 IP 位址之間的差異

私人 IP 位址一律為下列其中一種格式：

  • 10.x.x.x：範例：10.1.2.3、10.56.34.12。
  • 172.16.x.x 至 172.32.x.x：範例：172.20.1.1、172.31.67.89。
  • 192.168.x.x：範例：192.168.0.1、192.168.100.7

已保留某些 IP 位址和範圍：

  • 224.x.x.x：多點傳送
  • 255.255.255.255：廣播
  • 127.x.x.x：回送
  • 169.254.x.x：連結-本機
  • 168.63.129.16：內部 DNS

所有其他 IP 位址都是公用。

當您瀏覽入口網站或執行命令時，如果出現 IP 位址，請確定您可以識別該 IP 位址是私人、公用或已保留。 金鑰保存庫主機名稱必須解析為屬於虛擬網路位址空間的私人 IP 位址，私人連結才能運作。

在虛擬網路中尋找金鑰保存庫的私人 IP 位址

您需要診斷主機名稱解析，為此，對於已啟用私人連結的金鑰保存庫，您必須知道其確切私人 IP 位址。 為了尋找該位址，請遵循下列程序：

  1. 開啟 Azure 入口網站，然後開啟金鑰保存庫資源。
  2. 在左側功能表中，選取 [網路]。
  3. 選取 [私人端點連線] 索引標籤。這將會顯示所有私人端點連線及其各自的狀態。
  4. 找出您要診斷的連線，並確認 [線上狀態] 為已核准，且 [佈建狀態] 為成功。 若非如此，請返回本文的上一節。
  5. 找到正確的項目時，按一下 [私人端點] 欄中的連結。 將會開啟私人端點資源。
  6. [概觀] 頁面上可能出現 [自訂 DNS 設定] 區段。 確認只有一個項目符合金鑰保存庫主機名稱。 該項目顯示金鑰保存庫私人 IP 位址。
  7. 您也可以按一下 [網路介面] 上的連結，並確認私人 IP 位址同於上一個步驟所示。 網路介面是代表金鑰保存庫的虛擬裝置。

IP 位址供「在相同虛擬網路中執行」的 VM 和其他裝置用於連線至金鑰保存庫。 請記下 IP 位址，或保持開啟瀏覽器索引標籤，在進一步調查時別觸碰索引標籤。

注意

如果金鑰保存庫有多個私人端點，則會有多個私人 IP 位址。 只有在多個虛擬網路透過各自私人端點 (私人端點屬於單一虛擬網路) 存取相同的金鑰保存庫時，這才有用。 務必挑對虛擬網路來診斷問題，並在上述程序中選對私人端點連線。 此外，請勿在相同虛擬網路中為相同金鑰保存庫建立多個私人端點。 這沒必要，還會造成混淆。

5.驗證 DNS 解析

DNS 解析是指將金鑰保存庫主機名稱 (範例：fabrikam.vault.azure.net) 轉譯為 IP 位址 (範例：10.1.2.3) 過程。 下列小節顯示各種情節下 DNS 解析的預期結果。

本節僅供學習。 當金鑰保存庫沒有已核准狀態的私人端點連線時，解析主機名稱會產生類似下面的結果：

Windows：

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux：

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

您可以看到名稱解析為公用 IP 位址，但沒有 privatelink 別名。 現在不用擔心別名，稍後會解釋。

無論是已連線至虛擬網路的機器，還是具有網際網路連線的任意機器，上述結果都在意料中。 這是因為金鑰保存庫沒有已核准狀態的私人端點連線，因此金鑰保存庫不需要支援私人連結。

當金鑰保存庫有一或多個私人端點連線為已核准狀態時，如果您從連線至網際網路的任意機器解析主機名稱 (「不是」連線至私人端點所在虛擬網路的機器)，您會看到下列結果：

Windows：

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux：

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

明顯有別於上一個節情之處是出現值為 {vaultname}.privatelink.vaultcore.azure.net 的新別名。 這表示金鑰保存庫資料平面可以接受來自私人連結的要求。

但不表示從虛擬網路「外部」的機器 (就像您剛才使用的機器) 執行的要求會使用私人連結，其實不會。 實際上，您可以看到主機名稱仍然解析為公用 IP 位址。 只有「連線至虛擬網路」的機器才可以使用私人連結。 後續還有說明。

如果您沒看到 privatelink 別名，表示金鑰保存庫沒有私人端點連線處於 Approved 狀態。 重試之前請返回這一節。

當金鑰保存庫有一或多個私人端點連線處於已核准狀態時，如果您從機器解析主機名稱，而機器連線至已建立私人端點的虛擬網路，則預期有下列回應：

Windows：

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  10.1.2.3
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net

Linux：

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net has address 10.1.2.3

有兩個值得注意的差異。 首先，名稱解析為私人 IP 位址。 這必須是我們在本文的對應小節中看到的 IP 位址。 其次，privatelink 別名後面沒有其他別名。 這是因為虛擬網路 DNS 伺服器「攔截」別名鏈，而直接從名稱 fabrikam.privatelink.vaultcore.azure.net 傳回私人 IP 位址。 該項目實際上是私人 DNS 區域中的一筆 A 記錄。 後續還有說明。

注意

只有當虛擬機器連線至已建立私人端點的虛擬網路時，才會有上述結果。 如果您沒有 VM 部署在包含私人端點的虛擬網路中，請部署 VM 並從遠端連線至 VM，然後執行上述 nslookup 命令 (Windows) 或 host 命令 (Linux)。

如果您在虛擬機器上執行這些命令，而虛擬機器連線至已建立私人端點的虛擬網路，但命令未顯示金鑰保存庫私人 IP 位址，下一節可能有助於解決問題。

6.驗證私人 DNS 區域

如果 DNS 解析未如上一節所述運作，表示私人 DNS 區域可能有問題，本節可能有所幫助。 如果 DNS 解析顯示正確的金鑰保存庫私人 IP 位址，表示私人 DNS 區域應該正確。 您可以完全跳過本節。

確認必要的私人 DNS 區域資源存在

Azure 訂用帳戶必須有如下確切名稱的私人 DNS 區域資源：

privatelink.vaultcore.azure.net

您可以前往入口網站中的訂用帳戶頁面，然後選取左側功能表上的 [資源]，以檢查此資源是否存在。 資源名稱必須是 privatelink.vaultcore.azure.net，而資源類型必須是私人 DNS 區域。

當您使用一般程序建立私人端點時，通常會自動建立此資源。 但在某些情況下不會自動建立此資源，此時您必須手動建立。 也有可能是意外刪除此資源。

如果您沒有此資源，請在訂用帳戶中建立新的私人 DNS 區域資源。 請記住，此名稱必須與 privatelink.vaultcore.azure.net 一模一樣，不含空格或多餘的點。 如果您指定錯誤的名稱，則本文所述的名稱解析無法運作。 如需有關如何建立此資源的詳細資訊，請參閱使用 Azure 入口網站建立 Azure 私人 DNS 區域。 如果您循此頁面進行，則可以跳過建立虛擬網路的步驟，因為此時您應該已經有虛擬網路。 您也可以跳過虛擬機器的驗證程序。

確認私人 DNS 區域已連結至虛擬網路

光有私人 DNS 區域還不夠。 還必須連結至包含私人端點的虛擬網路。 如果私人 DNS 區域未連結至正確的虛擬網路，則源自該虛擬網路的任何 DNS 解析會忽略私人 DNS 區域。

開啟私人 DNS 區域資源，然後按一下左側功能表中的 [虛擬網路連結] 選項。 將會顯示連結清單，且各有訂用帳戶中的虛擬網路名稱。 其中必須列出包含私人端點資源的虛擬網路。 如果不存在，請加以新增。 如需詳細步驟，請參閱連結虛擬網路。 您可以保持不勾選 [啟用自動註冊]，此功能與私人連結無關。

私人 DNS 區域連結至虛擬網路之後，來自虛擬網路的 DNS 要求會在私人 DNS 區域中尋找名稱。 必須如此，當虛擬機器連線至已建立私人端點的虛擬網路時，才能正確執行位址解析。

注意

如果您剛儲存連結，即使入口網站指出作業已完成，可能還是需要一些時間才會生效。 您用來測試 DNS 解析的 VM 也可能需要重新開機。

確認私人 DNS 區域包含正確的 A 記錄

使用入口網站，開啟名稱為 privatelink.vaultcore.azure.net 的私人 DNS 區域。 [概觀] 頁面顯示所有記錄。 預設有一筆記錄的名稱為 @，類型為 SOA (表示「起始點授權」)。 別碰這筆記錄。

必須有一筆 A 記錄只帶有簡單保存庫名稱，不含尾碼或點，金鑰保存庫名稱解析才能運作。 例如，如果主機名稱是 fabrikam.vault.azure.net，則必須有一筆 A 記錄的名稱為 fabrikam，不含任何尾碼或點。

此外，A 記錄 (IP 位址) 的值必須是金鑰保存庫私人 IP 位址。 如果您找到 A 記錄，但包含錯誤 IP 位址，則您必須移除錯誤 IP 位址，然後新增 IP 位址。 建議移除整筆 A 記錄，再新增一筆記錄。

注意

每當您移除或修改 A 記錄時，因為 TTL (存留時間) 值可能尚未過期，機器仍可能解析為舊的 IP 位址。 建議 TTL 值一律指定為不小於 10 秒且不大於 600 秒 (10 分鐘)。 如果指定的值太大，用戶端可能要很久才能從中斷情況復原。

一個以上虛擬網路的 DNS 解析

如果有多個虛擬網路，且各自的私人端點資源參考相同的金鑰保存庫，則金鑰保存庫主機名稱需要解析為不同的私人 IP 位址，視網路而定。 這表示也需要多個私人 DNS 區域，各連結至不同的虛擬網路，且在記錄中 A 使用不同的 IP 位址。

在更進階的情節中，虛擬網路可能啟用對等互連。 在此情況下，只有一個虛擬網路需要私人端點資源，但兩者可能都需要連結至私人 DNS 區域資源。 本文未直接涵蓋此情節。

了解您可以掌控 DNS 解析

如上一節所述，具有私人連結的金鑰保存庫在其「公用」註冊中有別名 {vaultname}.privatelink.vaultcore.azure.net。 虛擬網路所使用的 DNS 伺服器使用公用註冊，但會檢查每個別名是否有「私人」註冊，如果找到，則停止追蹤公用註冊上定義的別名。

此邏輯表示如果虛擬網路連結至名稱為 privatelink.vaultcore.azure.net 的私人 DNS 區域，且金鑰保存庫的公用 DNS 註冊有別名 fabrikam.privatelink.vaultcore.azure.net (請注意，金鑰保存庫主機名稱尾碼與私人 DNS 區域名稱完全相符)，則 DNS 查詢會「在私人 DNS 區域中」尋找名稱為 fabrikam 的 A 記錄。 如果找到 A 記錄，則會在 DNS 查詢中傳回其 IP 位址，而在公用 DNS 註冊上就不再進一步查閱。

如您所見，您可以掌控名稱解析。 此設計的原理如下：

  • 您的情節可能較複雜，涉及自訂 DNS 伺服器，以及與內部部署網路整合。 在此情況下，您需要控制名稱如何轉譯為 IP 位址。
  • 您可能需要存取沒有私人連結的金鑰保存庫。 在此情況下，從虛擬網路解析主機名稱必須傳回公用 IP 位址，這是因為沒有私人連結的金鑰保存庫在名稱註冊中沒有 privatelink 別名。

查詢金鑰保存庫的 /healthstatus 端點

金鑰保存庫提供 /healthstatus 端點，可用於診斷。 回應標頭包含來源 IP 位址，如金鑰保存庫服務所見。 您可以使用下列命令來呼叫該端點 (記得使用您的金鑰保存庫主機名稱)：

Windows (PowerShell)：

PS C:\> $(Invoke-WebRequest -UseBasicParsing -Uri https://fabrikam.vault.azure.net/healthstatus).Headers

Key                           Value
---                           -----
Pragma                        no-cache
x-ms-request-id               3729ddde-eb6d-4060-af2b-aac08661d2ec
x-ms-keyvault-service-version 1.2.27.0
x-ms-keyvault-network-info    addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security     max-age=31536000;includeSubDomains
Content-Length                4
Cache-Control                 no-cache
Content-Type                  application/json; charset=utf-8

Linux 或包含 curl 的較新版 Windows 10：

joe@MyUbuntu:~$ curl -i https://fabrikam.vault.azure.net/healthstatus

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
x-ms-request-id: 6c090c46-0a1c-48ab-b740-3442ce17e75e
x-ms-keyvault-service-version: 1.2.27.0
x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security: max-age=31536000;includeSubDomains
Content-Length: 4

如果未產生類似如上的輸出，或發生網路錯誤，則表示無法透過您指定的主機名稱 (範例中的 fabrikam.vault.azure.net) 來存取金鑰保存庫。 可能是主機名稱未解析為正確的 IP 位址，或傳輸層有連線問題。 這可能是起因於路由問題、封裝捨棄及其他原因所致。 必須進一步調查。

回應必須包含標頭 x-ms-keyvault-network-info：

x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;

x-ms-keyvault-network-info 標頭中 addr 欄位顯示要求出處的 IP 位址。 此 IP 位址可以是下列其中一個：

  • 提出要求的機器的私人 IP 位址。 這表示要求使用私人連結或服務端點。 這是私人連結的預期結果。
  • 另外的私人 IP 位址，「不是」來自提出要求的機器。 這表示某種自訂路由生效。 這仍表示要求使用私人連結或服務端點。
  • 某個公用 IP 位址。 這表示要求透過閘道 (NAT) 裝置路由傳送至網際網路。 這表示要求「不」使用私人連結，還需要修正某個問題。 常見原因包括 1) 私人端點未處於已核准和成功狀態；2) 主機名稱未解析為金鑰保存庫的私人 IP 位址。 本文包含這兩種情況的疑難排解動作。

注意

如果對 /healthstatus 的要求正常運作，但遺漏 x-ms-keyvault-network-info 標頭，表示金鑰保存庫可能不負責端點。 因為上述命令也驗證 HTTPS 憑證，遺漏標頭可能表示遭竄改。

直接查詢金鑰保存庫 IP 位址

重要

未經 HTTPS 憑證驗證而存取金鑰保存庫很危險，僅限學習用途。 實際程式碼「絕不能」未經此用戶端驗證就存取金鑰保存庫。 即使只是診斷問題，也可能遭受篡改攻擊，如果您對金鑰保存庫提出要求時經常停用 HTTPS 憑證驗證，則難以察覺。

如果您已安裝新近版本的 PowerShell，則可以使用 -SkipCertificateCheck 來跳過 HTTPS 憑證檢查，然後直接以金鑰保存庫 IP 位址為目標：

PS C:\> $(Invoke-WebRequest -SkipCertificateCheck -Uri https://10.1.2.3/healthstatus).Headers

如果您使用 curl，則利用 -k 引數也一樣能做到：

joe@MyUbuntu:~$ curl -i -k https://10.1.2.3/healthstatus

回應必須與上一節相同，這表示包含的標頭 x-ms-keyvault-network-info 必須有相同的值。 /healthstatus 端點不在乎您使用金鑰保存庫主機名稱還是 IP 位址。

如果您看到 x-ms-keyvault-network-info 使用金鑰保存庫主機名稱傳回要求的一個值，並使用 IP 位址傳回要求的另一個值，則表示各個要求以不同的端點為目標。 請參閱上一節對於 x-ms-keyvault-network-info 中的 addr 欄位所做的說明，以判斷何種情況錯誤而需要修正。

8.造成影響的其他變更和自訂

下列各項不是全面的調查動作。 只是告知往何處探尋其他問題，您必須具備高深的網路知識，才能在這些情況下解決問題。

在虛擬網路上診斷自訂 DNS 伺服器

在入口網站中，開啟虛擬網路資源。 在左側功能表中，開啟 [DNS 伺服器]。 如果您使用「自訂」，則 DNS 解析可能不會如本文所述。 您必須診斷 DNS 伺服器解析金鑰保存庫主機名稱的方式。

如果您使用 Azure 提供的預設 DNS 伺服器，則本文通篇適用。

在虛擬機器上診斷主機覆寫或自訂 DNS 伺服器

許多作業系統允許為每個主機名稱設定明確的固定 IP 位址，通常是透過變更 hosts 檔案。 也可能允許覆寫 DNS 伺服器。 如果您運用上述其中一種情節，請繼續執行系統專屬的診斷選項。

混合 Proxy (Fiddler 等)

除非明確指出，否則只有當環境中沒有任何混合 Proxy 時，本文中的診斷選項才有用。 雖然這些 Proxy 通常只安裝在要診斷的機器上 (Fiddler 是最常見的例子)，但高階管理員可以覆寫根憑證授權單位 (CA)，並在負責網路中多部機器的閘道裝置上安裝混合 Proxy。 這些 Proxy 嚴重影響安全性和可靠性。 Microsoft 不支援使用這類產品的設定。

可能影響連線能力的其他事物

以下未詳盡列舉進階或複雜情節中可能出現的項目：

  • 防火牆設定，可能是連線至虛擬網路的 Azure 防火牆，或部署於虛擬網路或機器中的自訂防火牆解決方案。
  • 網路對等互連，可能影響使用哪些 DNS 伺服器及流量的路由方式。
  • 自訂閘道 (NAT) 解決方案，可能影響流量的路由方式，包括來自 DNS 查詢的流量。