Configuratieproblemen met privékoppelingen vaststellen in Azure Key Vault

Introductie

Dit artikel helpt gebruikers bij het diagnosticeren en oplossen van problemen met betrekking tot Key Vault en de functie Privékoppelingen. Deze handleiding helpt bij het configureren van aspecten, zoals het voor de eerste keer laten werken van privékoppelingen, of voor het oplossen van een situatie waarin privékoppelingen niet meer werken vanwege een bepaalde wijziging.

Zie Integratie van Key Vault met Azure Private Link als u nieuw bent met deze functie.

Problemen die in dit artikel worden behandeld

  • Uw DNS-query's retourneren nog steeds een openbaar IP-adres voor de sleutelkluis, in plaats van een privé-IP-adres dat u zou verwachten van het gebruik van de functie privékoppelingen.
  • Alle aanvragen van een bepaalde client die private link gebruiken, mislukken met time-outs of netwerkfouten en het probleem is niet onregelmatig.
  • De sleutelkluis heeft een privé-IP-adres, maar aanvragen krijgen 403 nog steeds antwoord met de ForbiddenByFirewall interne foutcode.
  • U gebruikt privékoppelingen, maar uw sleutelkluis accepteert nog steeds aanvragen van het openbare internet.
  • Uw sleutelkluis heeft twee privé-eindpunten. Aanvragen die één gebruiken, werken prima, maar aanvragen die de ander gebruiken, mislukken.
  • U hebt een ander abonnement, een sleutelkluis of een virtueel netwerk dat gebruikmaakt van privékoppelingen. U wilt een nieuwe vergelijkbare implementatie maken, maar u kunt geen privékoppelingen krijgen om daar te werken.

Problemen die NIET in dit artikel worden behandeld

  • Er is een onregelmatig verbindingsprobleem. In een bepaalde client ziet u dat sommige aanvragen werken en sommige niet werken. Onregelmatige problemen worden zelden veroorzaakt door een probleem in de configuratie van privékoppelingen; ze zijn een teken van netwerk- of clientoverbelasting.
  • U gebruikt een Azure product dat BYOK (Bring Your Own Key), CMK (Door klant beheerde sleutels) ondersteunt of toegang heeft tot geheimen die zijn opgeslagen in de sleutelkluis. Wanneer u de firewall inschakelt in de sleutelkluisinstellingen, heeft dat product geen toegang tot uw sleutelkluis. Bekijk productspecifieke documentatie. Zorg ervoor dat er expliciet ondersteuning wordt vermeld voor sleutelkluizen waarvoor de firewall is ingeschakeld. Neem indien nodig contact op met de ondersteuning voor dat specifieke product.

Lees dit artikel

Als u geen toegang hebt tot privékoppelingen of als u een complexe implementatie evalueert, wordt u aangeraden het hele artikel te lezen. Anders kunt u de sectie kiezen die logischer is voor het probleem dat u ondervindt.

Laten we aan de slag gaan.

1. Bevestig dat u de eigenaar bent van de clientverbinding

Controleer of uw client draait op het virtuele netwerk

Deze handleiding is bedoeld om u te helpen verbindingen met de sleutelkluis op te lossen die afkomstig zijn van applicatiecode. Voorbeelden zijn toepassingen en scripts die worden uitgevoerd in Azure Virtuele Machines, Azure Service Fabric clusters, Azure App Service, Azure Kubernetes Service (AKS) en vergelijkbare andere. Deze handleiding is ook van toepassing op toegang die wordt uitgevoerd in de webinterface van de Azure-portal, waar de browser rechtstreeks toegang heeft tot uw sleutelkluis.

Op basis van de definitie van privékoppelingen moet de toepassing, het script of de portal worden uitgevoerd op computers, clusters of omgevingen die zijn verbonden met de Virtual Network waar de resource Private-eindpunt is geïmplementeerd.

Als de toepassing, het script of de portal wordt uitgevoerd op een willekeurig netwerk dat is verbonden met internet, is deze handleiding NIET van toepassing en kunnen waarschijnlijk geen privékoppelingen worden gebruikt. Deze beperking is ook van toepassing op opdrachten die worden uitgevoerd in de Azure Cloud Shell, omdat deze worden uitgevoerd op een externe Azure machine die op aanvraag wordt geleverd in plaats van de browser van de gebruiker.

Als u een beheerde oplossing gebruikt, raadpleegt u specifieke documentatie

Voor beheerde Azure-services is een andere configuratie vereist

Deze handleiding is niet van toepassing op Microsoft beheerde services die toegang hebben tot uw Key Vault van buiten uw Virtual Network. Dergelijke scenario's zijn onder andere:

  • Azure Storage geconfigureerd met versleuteling-at-rest
  • Azure SQL met door de klant beheerde sleutels
  • Azure Event Hubs gegevens versleutelen met uw sleutels
  • Azure Data Factory toegang tot referenties die zijn opgeslagen in Key Vault
  • Azure-pipelines geheimen ophalen uit Key Vault

Voor deze scenario's moet u controleren of de specifieke Azure-service ondersteuning biedt voor toegang tot Key Vaults waarvoor firewalls zijn ingeschakeld. Veel services gebruiken de functie Trusted Services om veilig toegang te krijgen tot uw Key Vault ondanks firewallbeperkingen. Niet alle Azure services worden echter weergegeven in de lijst met vertrouwde services vanwege verschillende architecturale redenen.

Als u problemen ondervindt met een specifieke Azure service die toegang heeft tot uw Key Vault, raadpleegt u de documentatie van die service of neemt u contact op met het ondersteuningsteam voor specifieke richtlijnen.

Enkele Azure producten ondersteunen het concept van vnetinjectie. In eenvoudige termen voegt het product een netwerkapparaat toe aan de klant Virtual Network, zodat het aanvragen kan verzenden alsof het is geïmplementeerd in de Virtual Network. Een opmerkelijk voorbeeld is Azure Databricks. Producten zoals deze kunnen aanvragen indienen bij de sleutelkluis met behulp van de privékoppelingen. Deze handleiding voor probleemoplossing kan hierbij helpen.

2. Controleer of de verbinding is goedgekeurd en geslaagd

Met de volgende stappen wordt gecontroleerd of de verbinding met het privé-eindpunt is goedgekeurd en geslaagd:

  1. Open de Azure Portal en open uw sleutelkluisbron.
  2. Selecteer Networking in het menu aan de linkerkant.
  3. Selecteer het tabblad Privé-eindpuntverbindingen om alle privé-eindpuntverbindingen en de bijbehorende statussen weer te geven. Als er geen verbindingen zijn of als de verbinding voor uw Virtual Network ontbreekt, moet u een nieuw privé-eindpunt maken. Dit wordt later behandeld.
  4. Nog steeds in privé-eindpuntverbindingen zoekt u de verbinding die u wilt diagnosticeren en bevestigt u dat de verbindingsstatus is goedgekeurd en dat de inrichtingsstatus is geslaagd.
    • Als de verbinding de status In behandeling heeft, kunt u deze mogelijk gewoon goedkeuren.
    • Als de verbinding 'Geweigerd', 'Mislukt', 'Fout', 'Verbroken' of een andere status is, is deze helemaal niet effectief, moet u een nieuwe privé-eindpuntresource maken.

Het is een goed idee om ineffectieve verbindingen te verwijderen om dingen schoon te houden.

3. Controleer of de sleutelkluisfirewall juist is geconfigureerd

Belangrijk

Als u firewallinstellingen wijzigt, wordt de toegang mogelijk verwijderd van legitieme clients die nog steeds geen privékoppelingen gebruiken. Zorg ervoor dat u op de hoogte bent van de gevolgen van elke wijziging in de firewallconfiguratie.

Een belangrijk concept is dat de privékoppelingen alleen toegang verlenen tot uw sleutelkluis in een Virtual Network dat is gesloten om gegevensexfiltratie te voorkomen. Bestaande toegang wordt niet verwijderd . Als u de toegang van het openbare internet effectief wilt blokkeren, moet u de firewall van de sleutelkluis expliciet inschakelen:

  1. Open de Azure-portal en open uw Key Vault-resource.
  2. Selecteer Networking in het menu aan de linkerkant.
  3. Zorg ervoor dat het tabblad Firewalls en virtuele netwerken is geselecteerd.
  4. Als u Openbare toegang toestaan vindt vanuit alle geselecteerde netwerken , wordt uitgelegd waarom externe clients nog steeds toegang hebben tot de sleutelkluis. Als u wilt dat de Key Vault alleen toegankelijk is via Private Link, selecteert u Disable Public Access.

De volgende instructies zijn ook van toepassing op firewallinstellingen:

  • Voor de functie privékoppelingen hoeft geen 'virtueel netwerk' te worden opgegeven in de firewallinstellingen van de sleutelkluis. Alle aanvragen die gebruikmaken van het privé-IP-adres van de sleutelkluis (zie volgende sectie), moeten werken, zelfs als er geen virtueel netwerk is opgegeven in de firewallinstellingen van de sleutelkluis.
  • Voor de functie privékoppelingen hoeft u geen IP-adres op te geven in de firewallinstellingen van de sleutelkluis. Opnieuw moeten alle aanvragen die gebruikmaken van het privé-IP-adres van de sleutelkluis, werken, zelfs als er geen IP-adres is opgegeven in de firewallinstellingen.

Als u privékoppelingen gebruikt, zijn de enige redenen voor het opgeven van een virtueel netwerk of IP-adres in de key vault-firewall:

  • U hebt een hybride systeem waarbij sommige clients privékoppelingen gebruiken, sommige service-eindpunten gebruiken, sommige openbare IP-adressen gebruiken.
  • U gaat over op privékoppelingen. Zodra u hebt bevestigd dat alle clients privékoppelingen gebruiken, moet u virtuele netwerken en IP-adressen verwijderen uit de firewallinstellingen van de sleutelkluis.

4. Zorg ervoor dat de sleutelkluis een privé-IP-adres heeft

Verschil tussen privé- en openbare IP-adressen

Een privé-IP-adres heeft altijd een van de volgende indelingen:

  • 10.x.x.x: Voorbeelden: 10.1.2.3, 10.56.34.12.
  • 172.16.x.x tot 172.32.x.x: Voorbeelden: 172.20.1.1, 172.31.67.89.
  • 192.168.x.x: Voorbeelden: 192.168.0.1, 192.168.100.7

Bepaalde IP-adressen en bereiken zijn gereserveerd:

  • 224.x.x.x: Multicast
  • 255.255.255.255: Uitzending
  • 127.x.x.x: Loopback
  • 169.254.x.x: Link-local
  • 168.63.129.16: Interne DNS

Alle andere IP-adressen zijn openbaar.

Wanneer u door de portal bladert of een opdracht uitvoert die het IP-adres weergeeft, controleert u of dat IP-adres privé, openbaar of gereserveerd is. Privékoppelingen werken alleen als de hostnaam van de sleutelkluis wordt omgezet in een privé-IP-adres dat hoort bij de Virtual Network-adresruimte.

Het privé-IP-adres van de sleutelkluis zoeken in het virtuele netwerk

U moet een diagnose stellen van hostname-resolutie. Hiervoor moet u het exacte privé-IP-adres weten van uw sleutelkluis waarin privékoppelingen zijn geactiveerd. Volg deze stappen om dat adres te vinden:

  1. Open de Azure portal en open je sleutelkluis.
  2. Selecteer Networking in het menu aan de linkerkant.
  3. Selecteer het tabblad Privé-eindpuntverbindingen . In de resulterende weergave worden alle privé-eindpuntverbindingen en hun respectieve statussen weergegeven.
  4. Zoek de verbinding die u diagnosticeert en bevestig dat de verbindingsstatus is goedgekeurd en de inrichtingsstatus is geslaagd. Als de status verschilt, gaat u terug naar de vorige secties van het document.
  5. Wanneer u het juiste item vindt, selecteert u de koppeling in de kolom Privé-eindpunt . Met de actie wordt de privé-eindpuntresource geopend.
  6. Op de pagina Overzicht wordt mogelijk een sectie met de naam Aangepaste DNS-instellingen weergegeven. Controleer of er slechts één vermelding is die overeenkomt met de hostnaam van de sleutelkluis. Deze vermelding toont het privé-IP-adres van de sleutelkluis.
  7. U kunt ook de koppeling op de netwerkinterface selecteren en bevestigen dat het privé-IP-adres hetzelfde is dat in de vorige stap wordt weergegeven. De netwerkinterface is een virtueel apparaat dat de sleutelkluis representeert.

Het IP-adres is het adres dat vm's en andere apparaten die in hetzelfde virtuele netwerk draaien gebruiken om te verbinden met de sleutelkluis. Noteer het IP-adres of houd het browsertabblad open en raak het niet aan terwijl u verder onderzoek doet.

Opmerking

Als uw sleutelkluis meerdere privé-eindpunten heeft, heeft deze meerdere privé-IP-adressen. Dit is alleen handig als u meerdere virtuele netwerken hebt die toegang hebben tot dezelfde sleutelkluis, elk via een eigen privé-eindpunt (het privé-eindpunt behoort tot één Virtual Network). Zorg ervoor dat u het probleem voor de juiste Virtual Network diagnosticeert en selecteer de juiste privé-eindpuntverbinding in de bovenstaande procedure. Bovendien, maak geen meerdere privé-eindpunten voor dezelfde Key Vault in hetzelfde Virtuele Netwerk. Dit is niet nodig en is een bron van verwarring.

De validatie van de DNS-oplossing.

DNS-resolutie is het proces van het omzetten van de hostnaam van de sleutelkluis (bijvoorbeeld: fabrikam.vault.azure.net) naar een IP-adres (bijvoorbeeld: 10.1.2.3). In de volgende subsecties worden de verwachte resultaten van DNS-omzetting in elk scenario weergegeven.

Deze sectie is bedoeld voor leerdoeleinden. Wanneer de sleutelkluis geen privé-eindpuntverbinding in goedgekeurde status heeft, geeft het omzetten van de hostnaam een resultaat dat vergelijkbaar is met dit:

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

U kunt zien dat de naam wordt omgezet in een openbaar IP-adres en dat er geen privatelink alias is. De alias wordt later uitgelegd, maak u er nu geen zorgen over.

Dit resultaat ziet er hetzelfde uit, ongeacht of u de query uitvoert vanaf een computer die is verbonden met de Virtual Network of vanaf een computer met een internetverbinding. Het resultaat treedt op omdat de sleutelkluis geen privé-eindpuntverbindingen met een goedgekeurde status heeft, zodat de sleutelkluis geen ondersteuning biedt voor privékoppelingen.

Wanneer de sleutelkluis een of meer privé-eindpuntverbindingen heeft met de goedgekeurde status en u de hostnaam oplost van een willekeurige computer die is verbonden met internet (een computer die is niet verbonden met de Virtual Network waar het privé-eindpunt zich bevindt), ontvangt u een resultaat dat vergelijkbaar is met deze:

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

Het opmerkelijke verschil met het vorige scenario is dat er een nieuwe alias met de waarde {vaultname}.privatelink.vaultcore.azure.netis. Het dataplatform van de sleutelkluis is gereed om verzoeken van privéverbindingen te accepteren.

Dit betekent niet dat aanvragen die worden uitgevoerd vanaf computers buiten het virtuele netwerk (zoals het virtuele netwerk dat u net heeft gebruikt) privékoppelingen gebruiken. U kunt zien dat de hostnaam nog steeds wordt omgezet in een openbaar IP-adres. Alleen machines verbonden met de Virtual Network kunnen privékoppelingen gebruiken.

Als u de privatelink alias niet ziet, betekent dit dat de sleutelkluis geen privé-eindpuntverbindingen heeft in de status Approved. Ga terug naar deze sectie voordat u het opnieuw probeert.

Wanneer de sleutelkluis een of meer privé-eindpuntverbindingen heeft met de goedgekeurde status en u de hostnaam oplost van een computer die is verbonden met de Virtual Network waar het privé-eindpunt is gemaakt, is dit het verwachte antwoord:

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

Er zijn twee belangrijke verschillen. Eerst wordt de naam omgezet in een privé-IP-adres. Dat moet het IP-adres zijn dat we hebben gevonden in de bijbehorende sectie van dit artikel. Ten tweede zijn er geen andere aliassen achter de privatelink aliassen. Dit gebeurt omdat de Virtual Network DNS-servers de keten van aliassen onderscheppen en het privé-IP-adres rechtstreeks op basis van de naam retourneren. Deze vermelding is eigenlijk een A record in een Privé-DNS Zone.

Opmerking

Dit resultaat gebeurt alleen op een virtuele machine die is verbonden met de Virtual Network waar het privé-eindpunt is gemaakt. Als u geen VM hebt geïmplementeerd in de Virtual Network die het privé-eindpunt bevat, implementeert u er een en maakt u er extern verbinding mee, voert u de opdracht nslookup (Windows) of de opdracht host (Linux) uit.

Als u deze opdrachten uitvoert op een virtuele machine die is verbonden met het virtuele netwerk waar het privé-eindpunt is gemaakt, en ze niet het privé-IP-adres van de sleutelkluis laten zien, kan de volgende sectie u helpen het probleem op te lossen.

6. Valideer de privé DNS-zone

Als de DNS-omzetting niet werkt zoals beschreven in de vorige sectie, is er mogelijk een probleem met uw Privé-DNS zone en kan deze sectie u helpen. Als de DNS-resolutie het juiste privé-IP-adres van de Key Vault weergeeft, klopt uw Privé-DNS-zone waarschijnlijk. U kunt deze hele sectie overslaan.

Controleer of de vereiste Privé-DNS zoneresource bestaat

Uw Azure-abonnement moet een Privé-DNS Zone-resource hebben met deze exacte naam:

privatelink.vaultcore.azure.net

U kunt controleren op de aanwezigheid van deze resource door naar de abonnementspagina in de portal te gaan en in het linkermenu Resources te selecteren. De resourcenaam moet privatelink.vaultcore.azure.net zijn en het resourcetype moet Privé-DNS zone zijn.

Normaal gesproken wordt deze resource automatisch gemaakt wanneer u een privé-eindpunt maakt met behulp van een algemene procedure. Maar er zijn gevallen waarin deze resource niet automatisch wordt gemaakt en u dit handmatig moet doen. Deze resource is mogelijk ook per ongeluk verwijderd.

Als u deze resource niet hebt, maakt u een nieuwe Privé-DNS Zone-resource in uw abonnement. Houd er rekening mee dat de naam precies privatelink.vaultcore.azure.netmoet zijn, zonder spaties of extra punten. Als u de verkeerde naam opgeeft, mislukt de naamomzetting die in dit artikel wordt uitgelegd. Zie Create an Azure private DNS zone using the Azure portal voor meer informatie over het maken van deze resource. Als u deze pagina volgt, kunt u Virtual Network maken overslaan, omdat u op dit moment er al een hebt. U kunt validatieprocedures ook overslaan met Virtual Machines.

Controleer of de Privé-DNS-zone is gekoppeld aan de Virtual Network

Het is niet genoeg om een Privé-DNS zone te hebben. Deze moet ook worden gekoppeld aan de Virtual Network die het privé-eindpunt bevat. Als de Privé-DNS-zone niet is gekoppeld aan de juiste Virtual Network, negeert elke DNS-omzetting van die Virtual Network de Privé-DNS zone.

Open de resource voor de Privé-DNS-zone en selecteer de optie Virtual-netwerkkoppelingen aan de linkerkant in het menu. U ziet een lijst met koppelingen, elk met de naam van een Virtual Network in uw abonnement. De Virtual Network die de privé-eindpuntresource bevat, moet hier worden vermeld. Als het er niet is, voeg het toe. Zie Het virtuele netwerk koppelen voor gedetailleerde stappen. U kunt 'Automatische registratie inschakelen' uitgeschakeld laten. Deze functie is niet gerelateerd aan privékoppelingen.

Nadat de private DNS-zone is gekoppeld aan het Virtueel Netwerk, worden DNS-aanvragen die afkomstig zijn van binnen dat netwerk automatisch gecontroleerd op naamomzetting. Deze koppeling is essentieel voor Virtual Machines in hetzelfde Virtueel Netwerk als het privé-eindpunt, zodat de hostnaam van de sleutelkluis correct kan worden omgezet naar het privé-IP-adres in plaats van naar het openbare adres.

Opmerking

Als u de koppeling zojuist hebt opgeslagen, kan het enige tijd duren voordat de bewerking is doorgevoerd, zelfs nadat de portal heeft opgegeven dat de bewerking is voltooid. Mogelijk moet u ook de virtuele machine die u gebruikt, opnieuw opstarten om DNS-omzetting te testen.

Controleer of de Privé-DNS Zone de juiste A-record bevat

Open met behulp van de portal de Privé-DNS Zone met de naam privatelink.vaultcore.azure.net. Op de pagina Overzicht worden alle records weergegeven. Standaard is er één record met naam @ en type SOA, wat Start of Authority betekent. Raak dat niet aan.

De naamomzetting van de sleutelkluis werkt alleen als er een A record is met de eenvoudige naam van de kluis zonder achtervoegsel of punt. Als de hostnaam bijvoorbeeld is fabrikam.vault.azure.net, moet er een A record met de naam fabrikamzijn, zonder achtervoegsel of puntjes.

De waarde van de A record (het IP-adres) moet ook het privé-IP-adres van de sleutelkluis zijn. Als u de A record vindt maar het verkeerde IP-adres bevat, moet u het verkeerde IP-adres verwijderen en een nieuw IP-adres toevoegen. U wordt aangeraden de hele A record te verwijderen en een nieuwe record toe te voegen.

Opmerking

Wanneer u een A record verwijdert of wijzigt, kan de machine nog steeds worden omgezet in het oude IP-adres omdat de TTL-waarde (Time To Live) mogelijk nog niet is verlopen. Het wordt aanbevolen om altijd een TTL-waarde op te geven die niet kleiner is dan 10 seconden en niet groter is dan 600 seconden (10 minuten). Als u een waarde opgeeft die te groot is, kunnen uw clients te lang nodig hebben om te herstellen van storingen.

DNS-resolutie voor meer dan één Virtual Network

Als er meerdere virtuele netwerken zijn en elk een eigen privé-eindpuntresource heeft die verwijst naar dezelfde sleutelkluis, moet de hostnaam van de sleutelkluis worden omgezet naar een ander privé-IP-adres, afhankelijk van het netwerk. Dit betekent dat er ook meerdere Privé-DNS zones nodig zijn, elk gekoppeld aan een andere Virtual Network en een ander IP-adres gebruiken in de A-record.

In meer geavanceerde scenario's is peering mogelijk ingeschakeld voor de virtuele netwerken. In dit geval heeft slechts één Virtual Network de privé-eindpuntresource nodig, hoewel beide mogelijk moeten worden gekoppeld aan de Privé-DNS Zone-resource. Dit is een scenario dat niet rechtstreeks wordt gedekt door dit document.

Begrijp dat u controle hebt over DNS-resolutie

Zoals uitgelegd in de vorige sectie, heeft een sleutelkluis met privékoppelingen de alias {vaultname}.privatelink.vaultcore.azure.net in de openbare registratie. De DNS-server die door de Virtual Network wordt gebruikt, maakt gebruik van de openbare registratie, maar controleert elke alias voor een private registratie, en als er een wordt gevonden, stopt het volgen van aliassen die zijn gedefinieerd bij openbare registratie.

Deze logica betekent dat als de Virtual Network is gekoppeld aan een Privé-DNS Zone met de naam privatelink.vaultcore.azure.net, en de openbare DNS-registratie voor de sleutelkluis heeft de alias fabrikam.privatelink.vaultcore.azure.net (houd er rekening mee dat het hostnaamachtervoegsel van de sleutelkluis exact overeenkomt met de Privé-DNS zonenaam), zoekt de DNS-query naar een A record met de naam fabrikamin de Privé-DNS Zone. Als de A record wordt gevonden, wordt het IP-adres geretourneerd in de DNS-query en wordt er geen verdere zoekactie uitgevoerd bij openbare DNS-registratie.

Zoals u kunt zien, is de naamomzetting onder uw controle. De logica voor dit ontwerp is:

  • Mogelijk hebt u een complex scenario met aangepaste DNS-servers en integratie met on-premises netwerken. In dat geval moet u bepalen hoe namen worden vertaald naar IP-adressen.
  • Mogelijk moet u toegang krijgen tot een sleutelkluis zonder persoonlijke koppelingen. In dat geval moet het oplossen van de hostnaam uit het Virtueel netwerk het openbare IP-adres teruggeven, omdat sleutelkluizen zonder privékoppelingen geen alias privatelink hebben in de naamregistratie.

Het eindpunt van de sleutelkluis /healthstatus opvragen

Uw sleutelkluis biedt het /healthstatus eindpunt, dat kan worden gebruikt voor diagnostische gegevens. De antwoordheaders bevatten het oorspronkelijke IP-adres, zoals wordt gezien door de Key Vault-service. U kunt dat eindpunt aanroepen met de volgende opdracht (vergeet niet om de hostnaam van uw sleutelkluis te gebruiken):

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 of een recente versie van Windows 10 met 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

Als u geen uitvoer krijgt die er ongeveer als volgt uit ziet, of als er een netwerkfout optreedt, betekent dit dat uw sleutelkluis niet toegankelijk is via de hostnaam die u hebt opgegeven (fabrikam.vault.azure.net in het voorbeeld). De hostnaam wordt niet omgezet in het juiste IP-adres of u hebt een verbindingsprobleem op de transportlaag. Dit kan worden veroorzaakt door routeringsproblemen, pakketuitval en andere redenen. Je moet verder onderzoeken.

Het antwoord moet header x-ms-keyvault-network-infobevatten:

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

Het addr veld in de x-ms-keyvault-network-info header toont het IP-adres van de oorsprong van de aanvraag. Dit IP-adres kan een van de volgende zijn:

  • Het privé-IP-adres van de machine die de aanvraag uitvoert. Dit geeft aan dat de aanvraag gebruikmaakt van privékoppelingen of service-eindpunten. Dit is het verwachte resultaat voor privékoppelingen.
  • Een ander privé-IP-adres, niet van de computer die de aanvraag uitvoert. Dit geeft aan dat een aangepaste routering effectief is. Er wordt nog steeds aangegeven dat de aanvraag gebruikmaakt van privékoppelingen of service-eindpunten.
  • Een openbaar IP-adres. Dit geeft aan dat de aanvraag wordt doorgestuurd naar internet via een gatewayapparaat (NAT). Dit geeft aan dat de aanvraag geen gebruik maakt van privékoppelingen en dat er een probleem moet worden opgelost. De gebruikelijke redenen hiervoor zijn 1) het privé-eindpunt is niet in een goedgekeurde en geslaagde staat; en 2) de hostnaam resulteert niet in het privé-IP-adres van de sleutelkluis. Dit artikel bevat probleemoplossingsacties voor beide gevallen.

Opmerking

Als het verzoek naar /healthstatus succesvol is, maar de x-ms-keyvault-network-info-header ontbreekt, wordt het eindpunt waarschijnlijk niet bediend door de sleutelkluis. Omdat de bovenstaande opdrachten ook https-certificaat valideren, kan de ontbrekende header een teken zijn van manipulatie.

Voer rechtstreeks een query uit op het IP-adres van de sleutelkluis.

Belangrijk

Toegang tot de sleutelkluis zonder HTTPS-certificaatvalidatie is gevaarlijk en kan alleen worden gebruikt voor leerdoeleinden. Productiecode moet NOOIT toegang hebben tot de sleutelkluis zonder deze validatie aan de clientzijde. Zelfs als u alleen problemen diagnosticeert, is het mogelijk dat u te maken hebt met manipulatiepogingen die niet worden weergegeven als u https-certificaatvalidatie vaak uitschakelt in uw aanvragen naar de sleutelkluis.

Als u een recente versie van PowerShell hebt geïnstalleerd, kunt u met -SkipCertificateCheck HTTPS-certificaatcontroles overslaan. Vervolgens kunt u rechtstreeks op het IP-adres van de sleutelkluis richten.

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

Als u curl gebruikt, kunt u hetzelfde doen met het -k-argument.

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

De antwoorden moeten hetzelfde zijn als in de vorige sectie, wat betekent dat de x-ms-keyvault-network-info header met dezelfde waarde moet worden opgenomen. Het /healthstatus eindpunt maakt niet uit of u de hostnaam of het IP-adres van de sleutelkluis gebruikt.

Als u ziet dat x-ms-keyvault-network-info één waarde retourneert voor de aanvraag bij gebruik van de hostnaam van de sleutelkluis, en een andere waarde voor de aanvraag bij gebruik van het IP-adres, dan richt elke aanvraag zich op een ander eindpunt. Raadpleeg de uitleg van het addr veld uit x-ms-keyvault-network-info de vorige sectie om te bepalen welke zaak onjuist is en moet worden opgelost.

8. Andere wijzigingen en aanpassingen die invloed hebben

De volgende items zijn niet-volledige onderzoeksacties. Ze vertellen u waar u naar aanvullende problemen moet zoeken, maar u moet geavanceerde netwerkkennis hebben om problemen in deze scenario's op te lossen.

Aangepaste DNS-servers diagnosticeren op Virtual Network

Open de Virtual Network-resource in de portal. Open DNS-servers in het linkermenu. Als u 'Aangepast' gebruikt, is DNS-omzetting mogelijk niet zoals beschreven in dit document. U moet analyseren hoe uw DNS-servers de hostnaam van de sleutelkluis oplossen.

Als u de door Azure verstrekte standaard DNS-servers gebruikt, is dit hele document van toepassing.

Het diagnosticeren van hosts met overschrijvende of aangepaste DNS-servers op een virtuele machine

Veel besturingssystemen staan het instellen van een expliciet vast IP-adres per hostnaam toe, meestal door het hosts bestand te wijzigen. Ze kunnen ook toestaan dat de DNS-servers worden overschreven. Als u een van deze scenario's gebruikt, gaat u verder met systeemspecifieke diagnostische opties.

Promiscuous proxies (Fiddler, enz.)

Tenzij expliciet vermeld, werken de diagnostische opties in dit artikel alleen als er geen promiscueuze proxy aanwezig is in de omgeving. Hoewel deze proxy's vaak uitsluitend worden geïnstalleerd op de computer die wordt aangegeven (Fiddler is het meest voorkomende voorbeeld), kunnen geavanceerde beheerders basiscertificeringsinstanties (CA's) overschrijven en een promiscueuze proxy installeren in gatewayapparaten die meerdere machines in het netwerk bedienen. Deze proxy's kunnen van invloed zijn op zowel beveiliging als betrouwbaarheid. Microsoft biedt geen ondersteuning voor configuraties die dergelijke producten gebruiken.

Andere dingen die van invloed kunnen zijn op de connectiviteit

Dit is een niet-volledige lijst met items die te vinden zijn in geavanceerde of complexe scenario's:

  • Firewallinstellingen, de Azure Firewall verbonden met de Virtual Network of een aangepaste firewalloplossing die wordt geïmplementeerd in de Virtual Network of op de computer.
  • Netwerkpeering, wat van invloed kan zijn op de GEBRUIKTE DNS-servers en hoe verkeer wordt gerouteerd.
  • Aangepaste gatewayoplossingen (NAT) die van invloed kunnen zijn op hoe verkeer wordt gerouteerd, inclusief verkeer van DNS-query's.

Volgende stappen