Dela via

Diagnostisera konfigurationsproblem för privata länkar i Azure Key Vault

  • Artikel

Introduktion

Den här artikeln hjälper användare att diagnostisera och åtgärda problem som rör Key Vault och funktionen Privata länkar. Den här guiden hjälper till med konfigurationsaspekter, till exempel att få privata länkar att fungera för första gången eller för att åtgärda en situation där privata länkar slutade fungera på grund av vissa ändringar.

Om du är nybörjare på den här funktionen kan du läsa Integrera Key Vault med Azure Private Link.

Problem som beskrivs i den här artikeln

  • Dns-frågorna returnerar fortfarande en offentlig IP-adress för nyckelvalvet i stället för en privat IP-adress som du kan förvänta dig av att använda funktionen privata länkar.
  • Alla begäranden som görs av en viss klient som använder en privat länk misslyckas med tidsgränser eller nätverksfel och problemet är inte tillfälligt.
  • Nyckelvalvet har en privat IP-adress, men begäranden får 403 fortfarande svar med den ForbiddenByFirewall inre felkoden.
  • Du använder privata länkar, men ditt nyckelvalv accepterar fortfarande begäranden från det offentliga Internet.
  • Ditt nyckelvalv har två privata slutpunkter. Begäranden som använder den ena fungerar bra, men begäranden som använder den andra misslyckas.
  • Du har en annan prenumeration, ett nyckelvalv eller ett virtuellt nätverk som använder privata länkar. Du vill skapa en ny liknande distribution, men du kan inte få privata länkar att fungera där.

Problem som INTE omfattas av den här artikeln

  • Det finns ett tillfälligt anslutningsproblem. I en viss klient ser du att vissa begäranden fungerar och att vissa inte fungerar. Tillfälliga problem orsakas vanligtvis inte av ett problem i konfigurationen av privata länkar. de är ett tecken på nätverks- eller klientöverbelastning.
  • Du använder en Azure-produkt som stöder BYOK (Bring Your Own Key), CMK (Kundhanterade nycklar) eller åtkomst till hemligheter som lagras i nyckelvalvet. När du aktiverar brandväggen i key vault-inställningarna kan den produkten inte komma åt ditt nyckelvalv. Titta på produktspecifik dokumentation. Kontrollera att det uttryckligen anger stöd för nyckelvalv med brandväggen aktiverad. Kontakta supporten för den specifika produkten om det behövs.

Så här läser du den här artikeln

Om du är nybörjare på privata länkar eller om du utvärderar en komplex distribution rekommenderar vi att du läser hela artikeln. Annars kan du välja det avsnitt som är mer meningsfullt för det problem du står inför.

Nu sätter vi igång!

1. Bekräfta att du äger klientanslutningen

Bekräfta att klienten körs i det virtuella nätverket

Den här guiden är avsedd att hjälpa dig att åtgärda anslutningar till nyckelvalv som kommer från programkod. Exempel är program och skript som körs i Azure Virtual Machines, Azure Service Fabric-kluster, Azure App Service, Azure Kubernetes Service (AKS) och liknande. Den här guiden gäller även för åtkomst som utförs i azure-portalens webbbasanvändargränssnitt, där webbläsaren kommer åt ditt nyckelvalv direkt.

Per definition av privata länkar måste programmet, skriptet eller portalen köras på en dator, ett kluster eller en miljö som är ansluten till det virtuella nätverk där den privata slutpunktsresursen distribuerades.

Om programmet, skriptet eller portalen körs i ett godtyckligt Internetanslutet nätverk är den här guiden INTE tillämplig och troligen kan inte privata länkar användas. Den här begränsningen gäller även för kommandon som körs i Azure Cloud Shell, eftersom de körs på en fjärransluten Azure-dator som tillhandahålls på begäran i stället för användarens webbläsare.

Om du använder en hanterad lösning kan du läsa specifik dokumentation

Den här guiden gäller INTE för lösningar som hanteras av Microsoft, där nyckelvalvet nås av en Azure-produkt som finns oberoende av kundens virtuella nätverk. Exempel på sådana scenarier är Azure Storage eller Azure SQL som konfigurerats för kryptering i vila, Azure Event Hubs-kryptering av data med kundspecifika nycklar, Azure Data Factory som har åtkomst till tjänstautentiseringsuppgifter som lagras i nyckelvalvet, Azure Pipelines som hämtar hemligheter från nyckelvalv och andra liknande scenarier. I dessa fall måste du kontrollera om produkten stöder nyckelvalv med brandväggen aktiverad. Det här stödet utförs vanligtvis med funktionen Betrodda tjänster i Key Vault-brandväggen. Många produkter ingår dock inte i listan över betrodda tjänster av olika skäl. I så fall kan du nå den produktspecifika supporten.

Några Azure-produkter stöder begreppet vnet-inmatning. Enkelt uttryckt lägger produkten till en nätverksenhet i kundens virtuella nätverk, så att den kan skicka begäranden som om den distribuerades till det virtuella nätverket. Ett anmärkningsvärt exempel är Azure Databricks. Produkter som detta kan göra begäranden till nyckelvalvet med hjälp av privata länkar, och den här felsökningsguiden kan hjälpa.

2. Bekräfta att anslutningen är godkänd och lyckades

Följande steg verifierar att den privata slutpunktsanslutningen har godkänts och slutförts:

  1. Öppna Azure-portalen och öppna nyckelvalvsresursen.
  2. Välj Nätverk på den vänstra menyn.
  3. Välj fliken Privata slutpunktsanslutningar. Då visas alla privata slutpunktsanslutningar och deras respektive tillstånd. Om det inte finns några anslutningar, eller om anslutningen för det virtuella nätverket saknas, måste du skapa en ny privat slutpunkt. Det kommer att tas upp senare.
  4. Leta reda på den som du diagnostiserar i privata slutpunktsanslutningar och bekräfta att "Anslutningstillstånd" är Godkänt och att etableringstillståndet har slutförts.
    • Om anslutningen är i tillståndet "Väntar" kanske du bara kan godkänna den.
    • Om anslutningen "Avvisade", "Misslyckades", "Fel", "Frånkopplad" eller annat tillstånd, då det inte är effektivt alls, måste du skapa en ny privat slutpunktsresurs.

Det är en bra idé att ta bort ineffektiva anslutningar för att hålla saker rena.

3. Bekräfta att nyckelvalvsbrandväggen är korrekt konfigurerad

Viktigt!

Om du ändrar brandväggsinställningarna kan du ta bort åtkomsten från legitima klienter som fortfarande inte använder privata länkar. Se till att du är medveten om konsekvenserna av varje ändring i brandväggskonfigurationen.

En viktig uppfattning är att funktionen för privata länkar endast ger åtkomst till ditt nyckelvalv i ett virtuellt nätverk som är stängt för att förhindra dataexfiltrering. Den tar inte bort någon befintlig åtkomst. För att effektivt blockera åtkomst från det offentliga Internet måste du aktivera brandväggen för nyckelvalvet explicit:

  1. Öppna Azure-portalen och öppna nyckelvalvsresursen.
  2. Välj Nätverk på den vänstra menyn.
  3. Kontrollera att fliken Brandväggar och virtuella nätverk är markerad överst.
  4. Om du hittar Tillåt offentlig åtkomst från alla nätverk som valts förklarar det varför externa klienter fortfarande kan komma åt nyckelvalvet. Om du vill att Key Vault endast ska vara tillgängligt via Private Link väljer du Inaktivera offentlig åtkomst.

Följande instruktioner gäller även för brandväggsinställningar:

  • Funktionen för privata länkar kräver inte att något "virtuellt nätverk" anges i brandväggsinställningarna för nyckelvalvet. Alla begäranden som använder nyckelvalvets privata IP-adress (se nästa avsnitt) måste fungera, även om inget virtuellt nätverk anges i key vault-brandväggsinställningarna.
  • Funktionen för privata länkar kräver inte att du anger någon IP-adress i nyckelvalvets brandväggsinställningar. Återigen måste alla begäranden som använder nyckelvalvets privata IP-adress fungera, även om ingen IP-adress har angetts i brandväggsinställningarna.

Om du använder privata länkar är de enda motiveringarna för att ange virtuella nätverk eller IP-adresser i key vault-brandväggen:

  • Du har ett hybridsystem där vissa klienter använder privata länkar, vissa använder tjänstslutpunkter, vissa använder offentlig IP-adress.
  • Du övergår till privata länkar. I det här fallet bör du ta bort virtuella nätverk och IP-adresser från brandväggsinställningarna för nyckelvalvet när du har bekräftat att alla klienter använder privata länkar.

4. Kontrollera att nyckelvalvet har en privat IP-adress

Skillnad mellan privata och offentliga IP-adresser

En privat IP-adress har alltid något av följande format:

  • 10.x.x.x: Exempel: 10.1.2.3, 10.56.34.12.
  • 172.16.x.x till 172.32.x.x: Exempel: 172.20.1.1, 172.31.67.89.
  • 192.168.x.x: Exempel: 192.168.0.1, 192.168.100.7

Vissa IP-adresser och intervall är reserverade:

  • 224.x.x.x: Multicast
  • 255.255.255.255: Sändning
  • 127.x.x.x: Loopback
  • 169.254.x.x: Link-local
  • 168.63.129.16: Intern DNS

Alla andra IP-adresser är offentliga.

När du bläddrar i portalen eller kör ett kommando som visar IP-adressen kontrollerar du om IP-adressen är privat, offentlig eller reserverad. För att privata länkar ska fungera måste värdnamnet för nyckelvalvet matchas mot en privat IP-adress som tillhör adressutrymmet för det virtuella nätverket.

Hitta den privata IP-adressen för nyckelvalvet i det virtuella nätverket

Du måste diagnostisera värdnamnsmatchning och för det måste du känna till den exakta privata IP-adressen för ditt nyckelvalv med privata länkar aktiverade. Följ den här proceduren för att hitta adressen:

  1. Öppna Azure-portalen och öppna nyckelvalvsresursen.
  2. Välj Nätverk på den vänstra menyn.
  3. Välj fliken Privata slutpunktsanslutningar. Då visas alla privata slutpunktsanslutningar och deras respektive tillstånd.
  4. Leta reda på den som du diagnostiserar och bekräfta att "Anslutningstillstånd" är Godkänt och Etableringstillståndet har slutförts. Om du inte ser detta går du tillbaka till föregående avsnitt i det här dokumentet.
  5. När du hittar rätt objekt klickar du på länken i kolumnen Privat slutpunkt. Då öppnas resursen privat slutpunkt.
  6. Sidan Översikt kan visa ett avsnitt med namnet Anpassade DNS-inställningar. Bekräfta att det bara finns en post som matchar värdnamnet för nyckelvalvet. Posten visar den privata IP-adressen för nyckelvalvet.
  7. Du kan också klicka på länken i nätverksgränssnittet och bekräfta att den privata IP-adressen är samma som i föregående steg. Nätverksgränssnittet är en virtuell enhet som representerar nyckelvalvet.

IP-adressen är den som virtuella datorer och andra enheter som körs i samma virtuella nätverk använder för att ansluta till nyckelvalvet. Anteckna IP-adressen eller håll webbläsarfliken öppen och rör den inte när du gör ytterligare undersökningar.

Kommentar

Om ditt nyckelvalv har flera privata slutpunkter har det flera privata IP-adresser. Detta är bara användbart om du har flera virtuella nätverk som har åtkomst till samma nyckelvalv, var och en via sin egen privata slutpunkt (den privata slutpunkten tillhör ett enda virtuellt nätverk). Kontrollera att du diagnostiserar problemet för rätt virtuellt nätverk och välj rätt privat slutpunktsanslutning i proceduren ovan. Skapa inte heller flera privata slutpunkter för samma nyckelvalv i samma virtuella nätverk. Det behövs inte och kan vara förvirrande.

5. Verifiera DNS-matchningen

DNS-matchning är processen för att översätta nyckelvalvets värdnamn (exempel: fabrikam.vault.azure.net) till en IP-adress (exempel: 10.1.2.3). Följande underavsnitt visar förväntade resultat av DNS-matchning i varje scenario.

Det här avsnittet är avsett för utbildningsändamål. När nyckelvalvet inte har någon privat slutpunktsanslutning i godkänt tillstånd ger matchning av värdnamnet ett resultat som liknar det här:

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

Du kan se att namnet matchar en offentlig IP-adress och att det inte finns något privatelink alias. Aliaset förklaras senare, oroa dig inte för det nu.

Ovanstående resultat förväntas oavsett om datorn är ansluten till det virtuella nätverket eller vara en godtycklig dator med en Internetanslutning. Detta beror på att nyckelvalvet inte har någon privat slutpunktsanslutning i godkänt tillstånd och därför inte behöver nyckelvalvet ha stöd för privata länkar.

När nyckelvalvet har en eller flera privata slutpunktsanslutningar i godkänt tillstånd och du löser värdnamnet från en godtycklig dator som är ansluten till Internet (en dator som inte är ansluten till det virtuella nätverket där den privata slutpunkten finns), ska du hitta följande:

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

Den anmärkningsvärda skillnaden från föregående scenario är att det finns ett nytt alias med värdet {vaultname}.privatelink.vaultcore.azure.net. Det innebär att nyckelvalvets dataplan är redo att ta emot begäranden från privata länkar.

Det betyder inte att begäranden som utförs från datorer utanför det virtuella nätverket (som den du nyss använde) använder privata länkar – det gör de inte. Du kan se det från det faktum att värdnamnet fortfarande matchar en offentlig IP-adress. Endast datorer som är anslutna till det virtuella nätverket kan använda privata länkar. Mer information om detta kommer att följa.

Om du inte ser aliaset privatelink innebär det att nyckelvalvet har noll privata slutpunktsanslutningar i Approved tillståndet. Gå tillbaka till det här avsnittet innan du försöker igen.

När nyckelvalvet har en eller flera privata slutpunktsanslutningar i godkänt tillstånd och du löser värdnamnet från en dator som är ansluten till det virtuella nätverket där den privata slutpunkten skapades, är detta det förväntade svaret:

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

Det finns två anmärkningsvärda skillnader. För det första matchas namnet till en privat IP-adress. Det måste vara den IP-adress som vi hittade i motsvarande avsnitt i den här artikeln. För det andra finns det inga andra alias efter det privatelink . Detta beror på att DNS-servrarna för virtuella nätverk fångar upp kedjan med alias och returnerar den privata IP-adressen direkt från namnet fabrikam.privatelink.vaultcore.azure.net. Posten är faktiskt en A post i en privat DNS-zon. Mer information om detta kommer att följa.

Kommentar

Resultatet ovan sker endast på en virtuell dator som är ansluten till det virtuella nätverket där den privata slutpunkten skapades. Om du inte har en virtuell dator distribuerad i det virtuella nätverket som innehåller den privata slutpunkten distribuerar du en och ansluter via fjärranslutning till den nslookup och kör sedan kommandot (Windows) eller host kommandot (Linux) ovan.

Om du kör dessa kommandon på en virtuell dator som är ansluten till det virtuella nätverk där den privata slutpunkten skapades och de inte visar den privata IP-adressen för nyckelvalvet kan nästa avsnitt hjälpa till att åtgärda problemet.

6. Verifiera den privata DNS-zonen

Om DNS-matchningen inte fungerar enligt beskrivningen i föregående avsnitt kan det finnas ett problem med din privata DNS-zon och det här avsnittet kan vara till hjälp. Om DNS-matchningen visar rätt privat IP-adress för nyckelvalvet är din privata DNS-zon förmodligen korrekt. Du kan hoppa över hela det här avsnittet.

Bekräfta att den nödvändiga privata DNS-zonresursen finns

Din Azure-prenumeration måste ha en privat DNS-zonresurs med det här exakta namnet:

privatelink.vaultcore.azure.net

Du kan söka efter förekomsten av den här resursen genom att gå till prenumerationssidan i portalen och välja "Resurser" på den vänstra menyn. Resursnamnet måste vara privatelink.vaultcore.azure.netoch resurstypen måste vara privat DNS-zon.

Normalt skapas den här resursen automatiskt när du skapar en privat slutpunkt med hjälp av en vanlig procedur. Men det finns fall där den här resursen inte skapas automatiskt och du måste göra det manuellt. Den här resursen kan också ha tagits bort av misstag.

Om du inte har den här resursen skapar du en ny privat DNS-zonresurs i din prenumeration. Kom ihåg att namnet måste vara exakt privatelink.vaultcore.azure.net, utan blanksteg eller ytterligare punkter. Om du anger fel namn fungerar inte namnmatchningen som förklaras i den här artikeln. Mer information om hur du skapar den här resursen finns i Skapa en privat DNS-zon i Azure med hjälp av Azure-portalen. Om du följer den sidan kan du hoppa över skapande av virtuellt nätverk eftersom du i det här läget redan bör ha en. Du kan också hoppa över valideringsprocedurer med virtuella datorer.

Bekräfta att den privata DNS-zonen är länkad till det virtuella nätverket

Det räcker inte att ha en privat DNS-zon. Den måste också vara länkad till det virtuella nätverket som innehåller den privata slutpunkten. Om den privata DNS-zonen inte är länkad till rätt virtuellt nätverk ignorerar dns-matchning från det virtuella nätverket den privata DNS-zonen.

Öppna resursen Privat DNS-zon och klicka på alternativet Länkar till virtuellt nätverk i den vänstra menyn. Då visas en lista med länkar, var och en med namnet på ett virtuellt nätverk i din prenumeration. Det virtuella nätverk som innehåller den privata slutpunktsresursen måste anges här. Om det inte finns där måste du lägga till det. Detaljerade steg finns i Länka det virtuella nätverket. Du kan lämna "Aktivera automatisk registrering" avmarkerad – den funktionen är inte relaterad till privata länkar.

När den privata DNS-zonen är länkad till det virtuella nätverket letar DNS-begäranden från det virtuella nätverket efter namn i den privata DNS-zonen. Detta krävs för korrekt adressmatchning som utförs på virtuella datorer som är anslutna till det virtuella nätverk där den privata slutpunkten skapades.

Kommentar

Om du precis har sparat länken kan det ta lite tid innan den här åtgärden träder i kraft, även efter att portalen har angett att åtgärden är klar. Du kan också behöva starta om den virtuella dator som du använder för att testa DNS-matchning.

Bekräfta att den privata DNS-zonen innehåller rätt A-post

Öppna den privata DNS-zonen med namnet med hjälp privatelink.vaultcore.azure.netav portalen. På sidan Översikt visas alla poster. Som standard kommer det att finnas en post med namn @ och typ SOA, vilket betyder start av auktoritet. Rör inte det.

För att namnmatchningen för nyckelvalvet ska fungera måste det finnas en A post med det enkla valvnamnet utan suffix eller punkter. Om värdnamnet till exempel är fabrikam.vault.azure.netmåste det finnas en A post med namnet fabrikam, utan suffix eller punkter.

Dessutom måste värdet för A posten (IP-adressen) vara den privata IP-adressen för nyckelvalvet. Om du hittar A posten men den innehåller fel IP-adress måste du ta bort fel IP-adress och lägga till en ny. Vi rekommenderar att du tar bort hela A posten och lägger till en ny.

Kommentar

När du tar bort eller ändrar en A post kan datorn fortfarande matchas mot den gamla IP-adressen eftersom TTL-värdet (Time To Live) kanske inte har upphört att gälla ännu. Vi rekommenderar att du alltid anger ett TTL-värde som inte är mindre än 10 sekunder och inte större än 600 sekunder (10 minuter). Om du anger ett värde som är för stort kan det ta för lång tid för klienterna att återställas från avbrott.

DNS-matchning för mer än ett virtuellt nätverk

Om det finns flera virtuella nätverk och var och en har en egen privat slutpunktsresurs som refererar till samma nyckelvalv måste värdnamnet för nyckelvalvet matchas mot en annan privat IP-adress beroende på nätverket. Det innebär att flera privata DNS-zoner också behövs, var och en är länkad till ett annat virtuellt nätverk och använder en annan IP-adress i posten A .

I mer avancerade scenarier kan de virtuella nätverken ha peering aktiverat. I det här fallet behöver bara ett virtuellt nätverk den privata slutpunktsresursen, även om båda kan behöva länkas till resursen för den privata DNS-zonen. Det här scenariot omfattas inte direkt av det här dokumentet.

Förstå att du har kontroll över DNS-matchning

Som beskrivs i föregående avsnitt har ett nyckelvalv med privata länkar aliaset {vaultname}.privatelink.vaultcore.azure.net i sin offentliga registrering. DNS-servern som används av det virtuella nätverket använder den offentliga registreringen, men den kontrollerar varje alias för en privat registrering, och om en hittas slutar den att följa alias som definierats vid offentlig registrering.

Den här logiken innebär att om det virtuella nätverket är länkat till en privat DNS-zon med namnet privatelink.vaultcore.azure.netoch den offentliga DNS-registreringen för nyckelvalvet har aliaset fabrikam.privatelink.vaultcore.azure.net (observera att nyckelvalvets värdnamnssuffix matchar namnet på den privata DNS-zonen exakt), letar DNS-frågan efter en A post med namnet fabrikam i den privata DNS-zonen. Om posten A hittas returneras dess IP-adress i DNS-frågan och ingen ytterligare sökning utförs vid offentlig DNS-registrering.

Som du ser är namnmatchningen under din kontroll. Grunderna för den här designen är:

  • Du kan ha ett komplext scenario som omfattar anpassade DNS-servrar och integrering med lokala nätverk. I så fall måste du styra hur namn översätts till IP-adresser.
  • Du kan behöva komma åt ett nyckelvalv utan privata länkar. I så fall måste matchning av värdnamnet från det virtuella nätverket returnera den offentliga IP-adressen, och detta händer eftersom nyckelvalv utan privata länkar inte har aliaset privatelink i namnregistreringen.

/healthstatus Fråga slutpunkten för nyckelvalvet

Ditt nyckelvalv tillhandahåller /healthstatus slutpunkten, som kan användas för diagnostik. Svarshuvudena innehåller ursprungs-IP-adressen, enligt key vault-tjänsten. Du kan anropa slutpunkten med följande kommando (kom ihåg att använda nyckelvalvets värdnamn):

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 eller en ny version av Windows 10 som innehåller curl:

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

Om du inte får utdata som liknar det, eller om du får ett nätverksfel, innebär det att ditt nyckelvalv inte är tillgängligt via det värdnamn som du angav (fabrikam.vault.azure.net i exemplet). Antingen matchar inte värdnamnet rätt IP-adress eller så har du ett anslutningsproblem på transportlagret. Det kan orsakas av routningsproblem, paketfall och andra orsaker. Du måste undersöka vidare.

Svaret måste innehålla rubriken x-ms-keyvault-network-info:

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

Fältet addr i x-ms-keyvault-network-info rubriken visar IP-adressen för begärans ursprung. Den här IP-adressen kan vara något av följande:

  • Den privata IP-adressen för den dator som gör begäran. Detta anger att begäran använder privata länkar eller tjänstslutpunkter. Detta är det förväntade resultatet för privata länkar.
  • En annan privat IP-adress, inte från datorn som gör begäran. Detta indikerar att viss anpassad routning är effektiv. Det anger fortfarande att begäran använder privata länkar eller tjänstslutpunkter.
  • En offentlig IP-adress. Detta indikerar att begäran dirigeras till Internet via en gatewayenhet (NAT). Detta indikerar att begäran INTE använder privata länkar och att vissa problem måste åtgärdas. De vanligaste orsakerna till detta är 1) den privata slutpunkten är inte i godkänt och lyckades tillstånd; och 2) värdnamnet matchar inte nyckelvalvets privata IP-adress. Den här artikeln innehåller felsökningsåtgärder för båda fallen.

Kommentar

Om begäran om att /healthstatus fungera, men x-ms-keyvault-network-info huvudet saknas, hanteras slutpunkten troligen inte av nyckelvalvet. Eftersom ovanstående kommandon också validerar HTTPS-certifikatet kan det saknade huvudet vara ett tecken på manipulering.

Fråga nyckelvalvets IP-adress direkt

Viktigt!

Det är farligt att komma åt nyckelvalvet utan HTTPS-certifikatverifiering och kan endast användas i utbildningssyfte. Produktionskoden får ALDRIG komma åt nyckelvalvet utan den här valideringen på klientsidan. Även om du bara diagnostiserar problem kan du bli föremål för manipuleringsförsök som inte visas om du ofta inaktiverar HTTPS-certifikatverifiering i dina begäranden till nyckelvalvet.

Om du har installerat en ny version av PowerShell kan du använda -SkipCertificateCheck för att hoppa över HTTPS-certifikatkontroller. Sedan kan du rikta in dig på nyckelvalvets IP-adress direkt:

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

Om du använder curlkan du göra samma sak med -k argumentet:

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

Svaren måste vara samma i föregående avsnitt, vilket innebär att det måste innehålla x-ms-keyvault-network-info huvudet med samma värde. Slutpunkten /healthstatus bryr sig inte om du använder nyckelvalvets värdnamn eller IP-adress.

Om du ser x-ms-keyvault-network-info returnera ett värde för begäran med nyckelvalvets värdnamn och ett annat värde för begäran med hjälp av IP-adressen, riktas varje begäran mot en annan slutpunkt. Se förklaringen av fältet addr från x-ms-keyvault-network-info föregående avsnitt för att avgöra vilket fall som är fel och måste åtgärdas.

8. Andra ändringar och anpassningar som orsakar påverkan

Följande är icke-uttömmande undersökningsåtgärder. De visar var du kan söka efter ytterligare problem, men du måste ha avancerad nätverkskunskap för att åtgärda problem i dessa scenarier.

Diagnostisera anpassade DNS-servrar i virtuellt nätverk

Öppna resursen Virtuellt nätverk i portalen. Öppna DNS-servrar i den vänstra menyn. Om du använder "Anpassad" kanske DNS-matchningen inte är som beskrivs i det här dokumentet. Du måste diagnostisera hur dns-servrarna löser värdnamnet för nyckelvalvet.

Om du använder standard-DNS-servrarna som tillhandahålls av Azure gäller hela dokumentet.

Diagnostisera värdar som överskrider eller anpassade DNS-servrar på virtuell dator

Många operativsystem tillåter inställning av en explicit fast IP-adress per värdnamn, vanligtvis genom att ändra hosts filen. De kan också tillåta åsidosättande av DNS-servrarna. Om du använder något av dessa scenarier fortsätter du med systemspecifika diagnostikalternativ.

Promiskuösa proxyservrar (Fiddler osv.)

Förutom när det uttryckligen anges fungerar diagnostikalternativen i den här artikeln endast om det inte finns någon promiskuös proxy i miljön. Även om dessa proxyservrar ofta installeras exklusivt på den dator som diagnostiseras (Fiddler är det vanligaste exemplet), kan avancerade administratörer skriva över rotcertifikatutfärdare och installera en promiskuös proxy på gatewayenheter som betjänar flera datorer i nätverket. Dessa proxyservrar kan påverka både säkerhet och tillförlitlighet avsevärt. Microsoft stöder inte konfigurationer som använder sådana produkter.

Andra saker som kan påverka anslutningen

Det här är en icke-fullständig lista över objekt som kan hittas i avancerade eller komplexa scenarier:

  • Brandväggsinställningar, antingen Azure Firewall ansluten till det virtuella nätverket eller en anpassad brandväggslösning som distribueras i det virtuella nätverket eller på datorn.
  • Nätverkspeering, vilket kan påverka vilka DNS-servrar som används och hur trafiken dirigeras.
  • NAT-lösningar (Custom Gateway), som kan påverka hur trafiken dirigeras, inklusive trafik från DNS-frågor.