Share via

Diagnosticare i problemi di configurazione dei collegamenti privati in Azure Key Vault

  • Articolo

Introduzione

Questo articolo consente agli utenti di diagnosticare e risolvere i problemi relativi a Key Vault e alla funzionalità Collegamenti privati. Questa guida illustra gli aspetti di configurazione, ad esempio il recupero di collegamenti privati per la prima volta o la correzione di una situazione in cui i collegamenti privati hanno smesso di funzionare a causa di alcune modifiche.

Se non si ha familiarità con questa funzionalità, vedere Integrare Key Vault con collegamento privato di Azure.

Problemi trattati in questo articolo

  • Le query DNS restituiscono comunque un indirizzo IP pubblico per l'insieme di credenziali delle chiavi, anziché un indirizzo IP privato che ci si aspetterebbe dall'uso della funzione di collegamenti privati.
  • Tutte le richieste effettuate da un determinato client che usa un collegamento privato, hanno esito negativo con timeout o errori di rete e il problema non è intermittente.
  • L'insieme di credenziali delle chiavi ha un indirizzo IP privato, ma le richieste ricevono comunque una risposta 403 con il codice di errore interno ForbiddenByFirewall.
  • Si usano collegamenti privati, ma l'insieme di credenziali delle chiavi accetta ancora le richieste da Internet pubblico.
  • L'insieme di credenziali delle chiavi ha due endpoint privati. Le richieste che ne usano uno funzionano correttamente, ma le richieste che usano l'altro hanno esito negativo.
  • È disponibile un'altra sottoscrizione, un insieme di credenziali delle chiavi o una rete virtuale che usa collegamenti privati. Si vuole creare una nuova distribuzione simile, ma non è possibile ottenere collegamenti privati da usare.

Problemi NON trattati in questo articolo

  • Si è verificato un problema di connettività intermittente. In un determinato client vengono visualizzate alcune richieste funzionanti e alcune non funzionanti. I problemi intermittenti non sono in genere causati da un problema nella configurazione dei collegamenti privati; sono un segno di overload della rete o del client.
  • Si usa un prodotto Azure che supporta BYOK (Bring Your Own Key), CMK (chiavi gestite dal cliente) o l'accesso ai segreti archiviati nell'insieme di credenziali delle chiavi. Quando si abilita il firewall nelle impostazioni dell'insieme di credenziali delle chiavi, tale prodotto non può accedere all'insieme di credenziali delle chiavi. Esaminare la documentazione specifica del prodotto. Assicurarsi che indichi in modo esplicito il supporto per gli insiemi di credenziali delle chiavi con il firewall abilitato. Se necessario, contattare il supporto tecnico per quel prodotto specifico.

Come leggere questo articolo

Se non si ha familiarità con i collegamenti privati o si sta valutando una distribuzione complessa, è consigliabile leggere l'intero articolo. In caso contrario, è possibile scegliere la sezione più appropriata per il problema riscontrato.

È ora di iniziare.

1. Verificare di essere proprietari della connessione client

Verificare che il client venga eseguito nella rete virtuale

Questa guida consente di correggere le connessioni all'insieme di credenziali delle chiavi originato dal codice dell'applicazione. Alcuni esempi sono applicazioni e script eseguiti in macchine virtuali di Azure, cluster di Azure Service Fabric, Servizio app di Azure, servizio Azure Kubernetes e altri simili. Questa guida è applicabile anche agli accessi eseguiti nell'interfaccia utente basata sul Web del portale di Azure, in cui il browser accede direttamente all'insieme di credenziali delle chiavi.

Per definizione dei collegamenti privati, l'applicazione, lo script o il portale devono essere in esecuzione su computer, cluster o ambienti connessi alla rete virtuale in cui è stata distribuita la risorsa Endpoint privato.

Se l'applicazione, lo script o il portale è in esecuzione in una rete connessa a Internet arbitraria, questa guida non è applicabile e probabilmente non è possibile usare collegamenti privati. Questa limitazione è applicabile anche ai comandi eseguiti in Azure Cloud Shell, perché vengono eseguiti in un computer di Azure remoto fornito su richiesta anziché nel browser utente.

Se si usa una soluzione gestita, vedere la documentazione specifica

Questa guida NON è applicabile alle soluzioni gestite da Microsoft, in cui l'insieme di credenziali delle chiavi è accessibile da un prodotto Azure esistente indipendentemente dalla rete virtuale del cliente. Esempi di questi scenari sono Archiviazione di Azure o Azure SQL configurato per la crittografia dei dati inattivi, Hub eventi di Azure che crittografa i dati con chiavi fornite dal cliente, Azure Data Factory che accede alle credenziali del servizio archiviate nell'insieme di credenziali delle chiavi, Azure Pipelines che recupera i segreti dall'insieme di credenziali delle chiavi e altri scenari simili. In questi casi, è necessario verificare se il prodotto supporta insiemi di credenziali delle chiavi con il firewall abilitato. Questo supporto viene in genere eseguito con la funzionalità Servizi attendibili del firewall di Key Vault. Tuttavia, molti prodotti non sono inclusi nell'elenco dei servizi attendibili, per vari motivi. In tal caso, contattare il supporto specifico del prodotto.

Alcuni prodotti Azure supportano il concetto di inserimento di reti virtuali. In termini semplici, il prodotto aggiunge un dispositivo di rete alla rete virtuale del cliente, consentendo l'invio di richieste come se fosse stato distribuito nella rete virtuale. Un esempio rilevante è Azure Databricks. I prodotti come questo possono effettuare richieste all'insieme di credenziali delle chiavi usando i collegamenti privati e questa guida alla risoluzione dei problemi può essere utile.

2. Verificare che la connessione sia approvata e abbia avuto esito positivo

I passaggi seguenti convalidano che la connessione dell'endpoint privato sia approvata e abbia avuto esito positivo:

  1. Aprire il portale di Azure e la risorsa dell'insieme di credenziali delle chiavi.
  2. Nel menu a sinistra selezionare Rete.
  3. Selezionare la scheda Connessioni endpoint privato. In questo modo verranno visualizzate tutte le connessioni a endpoint privati e i rispettivi stati. Se non sono presenti connessioni o se manca la connessione per la rete virtuale, è necessario creare un nuovo endpoint privato. Questa operazione verrà illustrata in seguito.
  4. Sempre in Connessioni endpoint privato individuare quella su cui si sta eseguendo la diagnosi e verificare che "Stato connessione" sia Approvato e "Stato di provisioning" sia Completato.
    • Se la connessione è in stato "In sospeso", potrebbe essere possibile approvarla.
    • Se la connessione ha lo stato "Rifiutata", "Non riuscita", "Errore", "Disconnessione completata" o un altro stato, non è affatto efficace ed è necessario creare una nuova risorsa Endpoint privato.

È consigliabile eliminare le connessioni inefficaci per mantenere l'ordine.

3. Verificare che il firewall dell'insieme di credenziali delle chiavi sia configurato correttamente

Importante

La modifica delle impostazioni del firewall può rimuovere l'accesso dai client legittimi che non usano ancora collegamenti privati. Assicurarsi di conoscere le implicazioni di ogni modifica nella configurazione del firewall.

Un concetto importante è che la funzionalità Collegamenti privati consente l'accesso solo all'insieme di credenziali delle chiavi in una rete virtuale chiusa per impedire l'esfiltrazione dei dati. Non rimuove alcun accesso esistente. Per bloccare efficacemente gli accessi da Internet pubblico, è necessario abilitare il firewall dell'insieme di credenziali delle chiavi in modo esplicito:

  1. Aprire il portale di Azure e la risorsa dell'insieme di credenziali delle chiavi.
  2. Nel menu a sinistra selezionare Rete.
  3. Assicurarsi che nella parte superiore sia selezionata la scheda Firewall e reti virtuali.
  4. Se l'opzione Consenti l'accesso pubblico da tutte le reti è selezionata, questo spiega perché i client esterni sono ancora in grado di accedere all'insieme di credenziali delle chiavi. Se si vuole che l'insieme di credenziali delle chiavi sia accessibile solo tramite collegamento privato, selezionare Disabilita accesso pubblico.

Le istruzioni seguenti si applicano anche alle impostazioni del firewall:

  • La funzionalità Collegamenti privati non richiede l'impostazione di alcuna "rete virtuale" nelle impostazioni del firewall dell'insieme di credenziali delle chiavi. Tutte le richieste che usano l'indirizzo IP privato dell'insieme di credenziali delle chiavi (vedere la sezione successiva) devono funzionare, anche se non è specificata alcuna rete virtuale nelle impostazioni del firewall dell'insieme di credenziali delle chiavi.
  • La funzionalità Collegamenti privati non richiede di specificare alcun indirizzo IP nelle impostazioni del firewall dell'insieme di credenziali delle chiavi. Anche in questo caso, tutte le richieste che usano l'indirizzo IP privato dell'insieme di credenziali delle chiavi devono funzionare, anche se non è stato specificato alcun indirizzo IP nelle impostazioni del firewall.

Se si usano collegamenti privati, le uniche motivazioni per specificare la rete virtuale o l'indirizzo IP nel firewall dell'insieme di credenziali delle chiavi sono:

  • Si dispone di un sistema ibrido in cui alcuni client usano collegamenti privati, alcuni usano endpoint di servizio, alcuni usano l'indirizzo IP pubblico.
  • Si sta eseguendo la transizione a collegamenti privati. In questo caso, dopo aver verificato che tutti i client usino collegamenti privati, è necessario rimuovere le reti virtuali e gli indirizzi IP dalle impostazioni del firewall dell'insieme di credenziali delle chiavi.

4. Assicurarsi che l'insieme di credenziali delle chiavi abbia un indirizzo IP privato

Differenza tra indirizzi IP privati e pubblici

Un indirizzo IP privato ha sempre uno dei formati seguenti:

  • 10.x.x.x: Esempi: 10.1.2.3, 10.56.34.12.
  • Da 172.16.x.x a 172.32.x.x: Esempi: 172.20.1.1, 172.31.67.89.
  • 192.168.x.x: Esempi: 192.168.0.1, 192.168.100.7

Alcuni indirizzi IP e intervalli sono riservati:

  • 224.x.x.x: multicast
  • 255.255.255.255: broadcast
  • 127.x.x.x: Loopback
  • 169.254.x.x: Locale rispetto al collegamento
  • 168.63.129.16: DNS interno

Tutti gli altri indirizzi IP sono pubblici.

Quando si esplora il portale o si esegue un comando che mostra l'indirizzo IP, assicurarsi di poter identificare se l'indirizzo IP è privato, pubblico o riservato. Per il funzionamento dei collegamenti privati, il nome host dell'insieme di credenziali delle chiavi deve essere risolto in un indirizzo IP privato appartenente allo spazio indirizzi della rete virtuale.

Trovare l'indirizzo IP privato dell'insieme di credenziali delle chiavi nella rete virtuale

Sarà necessario diagnosticare la risoluzione dei nomi host e per tale scopo è necessario conoscere l'indirizzo IP privato esatto dell'insieme di credenziali delle chiavi con collegamenti privati abilitati. Per trovare tale indirizzo, seguire questa procedura:

  1. Aprire il portale di Azure e la risorsa dell'insieme di credenziali delle chiavi.
  2. Nel menu a sinistra selezionare Rete.
  3. Selezionare la scheda Connessioni endpoint privato. In questo modo verranno visualizzate tutte le connessioni a endpoint privati e i rispettivi stati.
  4. Individuare quella su cui si sta eseguendo la diagnosi e verificare che "Stato connessione" sia Approvato e lo Stato di provisioning sia Completato. Se non vengono visualizzati questi stati, tornare alle sezioni precedenti di questo documento.
  5. Quando si trova l'elemento corretto, fare clic sul collegamento nella colonna Endpoint privato. In questo modo verrà aperta la risorsa endpoint privato.
  6. La pagina Panoramica può visualizzare una sezione denominata Impostazioni DNS personalizzate. Verificare che sia presente una sola voce corrispondente al nome host dell'insieme di credenziali delle chiavi. Tale voce mostra l'indirizzo IP privato dell'insieme di credenziali delle chiavi.
  7. È anche possibile fare clic sul collegamento nell'interfaccia di rete e verificare che l'indirizzo IP privato sia lo stesso visualizzato nel passaggio precedente. L'interfaccia di rete è un dispositivo virtuale che rappresenta l'insieme di credenziali delle chiavi.

L'indirizzo IP è quello che le macchine virtuali e gli altri dispositivi in esecuzione nella stessa rete virtuale useranno per connettersi all'insieme di credenziali delle chiavi. Prendere nota dell'indirizzo IP o mantenere aperta la scheda del browser e non toccarla mentre si eseguono ulteriori indagini.

Nota

Se l'insieme di credenziali delle chiavi ha più endpoint privati, include più indirizzi IP privati. Questo è utile solo se più reti virtuali accedono allo stesso insieme di credenziali delle chiavi, ognuna tramite il suo endpoint privato (l'endpoint privato appartiene a una singola rete virtuale). Assicurarsi di diagnosticare il problema per la rete virtuale corretta e selezionare la connessione dell'endpoint privato corretta nella procedura precedente. Inoltre, non creare più endpoint privati per lo stesso insieme di credenziali delle chiavi nella stessa rete virtuale. Non è necessario ed è fonte di confusione.

5. Convalidare la risoluzione DNS

La risoluzione DNS è il processo di conversione del nome host dell'insieme di credenziali delle chiavi (esempio: fabrikam.vault.azure.net) in un indirizzo IP (esempio: 10.1.2.3). Le sottosezioni seguenti mostrano i risultati previsti della risoluzione DNS in ogni scenario.

Questa sezione è destinata a scopi di apprendimento. Quando l'insieme di credenziali delle chiavi non dispone di una connessione all'endpoint privato in stato approvato, la risoluzione del nome host restituisce un risultato simile al seguente:

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

È possibile notare che il nome viene risolto in un indirizzo IP pubblico e che non è presente alcun alias privatelink. L'alias verrà spiegato più avanti.

Il risultato precedente è previsto indipendentemente dal fatto che il computer sia connesso alla rete virtuale o sia un computer arbitrario con una connessione Internet. Ciò si verifica perché l'insieme di credenziali delle chiavi non dispone di alcuna connessione all'endpoint privato nello stato approvato e pertanto non è necessario che l'insieme di credenziali delle chiavi supporti i collegamenti privati.

Quando l'insieme di credenziali delle chiavi ha una o più connessioni endpoint private in stato approvato e si risolve il nome host da un computer arbitrario connesso a Internet (un computer che non è connesso alla rete virtuale in cui si trova l'endpoint privato), si troverà quanto segue:

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

La differenza notevole rispetto allo scenario precedente è che è presente un nuovo alias con il valore {vaultname}.privatelink.vaultcore.azure.net. Ciò significa che il piano dati dell'insieme di credenziali delle chiavi è pronto per accettare richieste da collegamenti privati.

Non significa che le richieste eseguite da computer esterni alla rete virtuale (come quella appena usata) useranno collegamenti privati: non lo faranno. Ciò si può notare dal fatto che il nome host si risolve ancora in un indirizzo IP pubblico. Solo i computer connessi alla rete virtuale possono usare collegamenti privati. Altre informazioni su questo argomento saranno illustrate successivamente.

Se l'alias di privatelink non viene visualizzato, significa che l'insieme di credenziali delle chiavi ha zero connessioni endpoint private nello stato Approved. Tornare a questa sezione prima di riprovare.

Quando l'insieme di credenziali delle chiavi ha una o più connessioni all'endpoint privato in stato approvato e si risolve il nome host da una macchina connessa alla rete virtuale in cui è stato creato l'endpoint privato, questa è la risposta prevista:

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

Esistono due differenze significative. Prima di tutto, il nome viene risolto in un indirizzo IP privato. Deve trattarsi dell'indirizzo IP trovato nella sezione corrispondente di questo articolo. In secondo luogo, non ci sono altri alias dopo quello privatelink. Ciò si verifica perché i server DNS della rete virtuale intercettano la catena di alias e restituiscono l'indirizzo IP privato direttamente dal nome fabrikam.privatelink.vaultcore.azure.net. Questa voce è in realtà un record A in una zona DNS privato. Altre informazioni su questo argomento saranno illustrate successivamente.

Nota

Il risultato precedente si verifica solo in una macchina virtuale connessa alla rete virtuale in cui è stato creato l'endpoint privato. Se non è stata distribuita una macchina virtuale nella rete virtuale che contiene l'endpoint privato, distribuirne una e connettersi in remoto, eseguire il comando nslookup (Windows) o il comando host (Linux) di cui sopra.

Se si eseguono questi comandi in una macchina virtuale connessa alla rete virtuale in cui è stato creato l'endpoint privato e non vengono visualizzati l'indirizzo IP privato dell'insieme di credenziali delle chiavi, la sezione successiva può contribuire a risolvere il problema.

6. Convalidare la zona DNS privato

Se la risoluzione DNS non funziona come descritto nella sezione precedente, potrebbe essere presente un problema con la zona DNS privato e questa sezione può risultare utile. Se la risoluzione DNS mostra l'indirizzo IP privato dell'insieme di credenziali delle chiavi corretto, la zona DNS privato è probabilmente corretta. È possibile ignorare questa sezione.

Verificare che la risorsa Zona DNS privato richiesta esista

La sottoscrizione di Azure deve avere una risorsa Zona DNS privato con questo nome esatto:

privatelink.vaultcore.azure.net

Per verificare la presenza di questa risorsa, passare alla pagina della sottoscrizione nel portale e selezionare "Risorse" nel menu a sinistra. Il nome della risorsa deve essere privatelink.vaultcore.azure.net e il tipo di risorsa deve essere Zona DNS privato.

In genere questa risorsa viene creata automaticamente quando si crea un Endpoint privato usando una procedura comune. Tuttavia, in alcuni casi questa risorsa non viene creata automaticamente ed è necessario farlo manualmente. Questa risorsa potrebbe essere stata eliminata accidentalmente.

Se questa risorsa non è disponibile, creare una nuova risorsa Zona DNS privato nella sottoscrizione. Tenere presente che il nome deve essere esattamente privatelink.vaultcore.azure.net, senza spazi o punti aggiuntivi. Se si specifica il nome errato, la risoluzione dei nomi illustrata in questo articolo non funzionerà. Per altre informazioni su come creare questa risorsa, vedere Creare una zona DNS privato di Azure usando il portale di Azure. Se si segue questa pagina, è possibile ignorare la creazione della rete virtuale perché a questo punto dovrebbe essere già disponibile. È anche possibile ignorare le procedure di convalida con macchine virtuali.

Verificare che la rete virtuale sia collegata alla Zona DNS privato sia collegata alla rete virtuale

Non è sufficiente avere una Zona DNS privato. Deve anche essere collegata alla rete virtuale che contiene l'Endpoint privato. Se la Zona DNS privato non è collegata alla rete virtuale corretta, qualsiasi risoluzione DNS da tale rete virtuale ignorerà la Zona DNS privato.

Aprire la risorsa Zona DNS privato e fare clic sull'opzione Collegamenti di rete virtuale nel menu a sinistra. Verrà visualizzato un elenco di collegamenti, ognuno con il nome di una rete virtuale nella sottoscrizione. La rete virtuale che contiene la risorsa Endpoint privato deve essere elencata qui. Se non lo è, aggiungerla. Per i passaggi dettagliati, vedere Collegare la rete virtuale. È possibile lasciare deselezionata l'opzione "Abilita registrazione automatica". Questa funzionalità non è correlata ai collegamenti privati.

Dopo che la Zona DNS privato è collegata alla rete virtuale, le richieste DNS provenienti dalla rete virtuale cercheranno i nomi nella Zona DNS privato. Questa operazione è necessaria per la risoluzione degli indirizzi corretta eseguita nelle macchine virtuali connesse alla rete virtuale in cui è stato creato l'Endpoint privato.

Nota

Se il collegamento è stato appena salvato, l'operazione potrebbe richiedere del tempo, anche dopo il completamento dell'operazione nel portale. Potrebbe anche essere necessario riavviare la macchina virtuale usata per testare la risoluzione DNS.

Verificare che la Zona DNS privato contenga il record A corretto

Usando il portale, aprire la Zona DNS privato con il nome privatelink.vaultcore.azure.net. La pagina Panoramica mostra tutti i record. Per impostazione predefinita, sarà presente un record con nome @ e tipo SOA, ovvero Start of Authority. Non toccarlo.

Per il corretto funzionamento della risoluzione dei nomi dell'insieme di credenziali delle chiavi, è necessario che sia presente un record A con il nome dell'insieme di credenziali semplice senza suffisso o punti. Ad esempio, se il nome host è fabrikam.vault.azure.net, deve essere presente un record A con il nome fabrikam, senza suffisso o punti.

Inoltre, il valore del record A (l'indirizzo IP) deve essere l'indirizzo IP privato dell'insieme di credenziali delle chiavi. Se si trova il record A ma contiene l'indirizzo IP errato, è necessario rimuovere l'indirizzo IP errato e aggiungerne uno nuovo. È consigliabile rimuovere l'intero record A e aggiungerne uno nuovo.

Nota

Ogni volta che si rimuove o si modifica un record A, il computer potrebbe comunque risolversi nell'indirizzo IP precedente perché il valore Durata (TTL) potrebbe non essere ancora scaduto. È consigliabile specificare sempre un valore TTL non inferiore a 10 secondi e non superiore a 600 secondi (10 minuti). Se si specifica un valore troppo grande, i client potrebbero richiedere troppo tempo per il ripristino dalle interruzioni.

Risoluzione DNS per più reti virtuali

Se sono presenti più reti virtuali e ognuna ha una propria risorsa Endpoint privato che fa riferimento allo stesso insieme di credenziali delle chiavi, il nome host dell'insieme di credenziali delle chiavi deve essere risolto in un indirizzo IP privato diverso a seconda della rete. Ciò significa che sono necessarie anche più Zone DNS privato, ognuna collegata a una rete virtuale diversa e usando un indirizzo IP diverso nel record A.

In scenari più avanzati, è possibile che il peering delle reti virtuali sia abilitato. In questo caso, è necessaria solo una rete virtuale per la risorsa Endpoint privato, anche se entrambi possono essere collegati alla risorsa Zona DNS privato. Questo scenario non è trattato direttamente nel presente documento.

Comprendere che si ha il controllo della risoluzione DNS

Come illustrato nella sezione precedente, un insieme di credenziali delle chiavi con collegamenti privati ha l'alias {vaultname}.privatelink.vaultcore.azure.net nella registrazione pubblica. Il server DNS usato dalla rete virtuale usa la registrazione pubblica, ma controlla ogni alias per una registrazione privata e, se ne viene trovata una, smetterà di seguire gli alias definiti durante la registrazione pubblica.

Questa logica significa che se la rete virtuale è collegata a una Zona DNS privato con nome privatelink.vaultcore.azure.net e la registrazione del DNS pubblico per l'insieme di credenziali delle chiavi ha l'alias fabrikam.privatelink.vaultcore.azure.net (si noti che il suffisso del nome host dell'insieme di credenziali delle chiavi corrisponde esattamente al nome della Zona DNS privato), la query DNS cercherà un record A con nome fabrikamnella Zona DNS privato. Se il record A viene trovato, il relativo indirizzo IP viene restituito nella query DNS e non viene eseguita alcuna ulteriore ricerca nella registrazione del DNS pubblico.

Come si può notare, la risoluzione dei nomi è sotto il controllo dell'utente. I motivi per questa progettazione sono:

  • Potrebbe essere disponibile uno scenario complesso che coinvolge server DNS personalizzati e l'integrazione con reti locali. In tal caso, è necessario controllare la modalità di conversione dei nomi in indirizzi IP.
  • Potrebbe essere necessario accedere a un insieme di credenziali delle chiavi senza collegamenti privati. In tal caso, la risoluzione del nome host dalla rete virtuale deve restituire l'indirizzo IP pubblico e ciò avviene perché gli insiemi di credenziali delle chiavi senza collegamenti privati non hanno l'alias privatelink nella registrazione del nome.

Eseguire una query sull'endpoint /healthstatus dell'insieme di credenziali delle chiavi

L'insieme di credenziali delle chiavi fornisce l'endpoint /healthstatus, che può essere usato per la diagnostica. Le intestazioni della risposta includono l'indirizzo IP di origine, come illustrato dal servizio dell'insieme di credenziali delle chiavi. È possibile chiamare tale endpoint con il comando seguente (ricordarsi di usare il nome host dell'insieme di credenziali delle chiavi):

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 o una versione recente di Windows 10 che include 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

Se non si riceve un output simile a quello o se viene visualizzato un errore di rete, significa che l'insieme di credenziali delle chiavi non è accessibile tramite il nome host specificato (fabrikam.vault.azure.net nell'esempio). Il nome host non risolve l'indirizzo IP corretto oppure si verifica un problema di connettività a livello di trasporto. Può essere causato da problemi di routing, eliminazione del pacchetto e altri motivi. È necessario indagare ulteriormente.

La risposta deve includere l'intestazione x-ms-keyvault-network-info:

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

Il campo addr nell'intestazione x-ms-keyvault-network-info mostra l'indirizzo IP dell'origine della richiesta. Questo indirizzo IP può essere uno dei seguenti:

  • Indirizzo IP privato del computer che esegue la richiesta. Ciò indica che la richiesta usa collegamenti privati o endpoint di servizio. Si tratta del risultato previsto per i collegamenti privati.
  • Un altro indirizzo IP privato, non dal computer che esegue la richiesta. Ciò indica che il routing personalizzato è efficace. Indica comunque che la richiesta usa collegamenti privati o endpoint di servizio.
  • Un indirizzo IP pubblico. Ciò indica che la richiesta viene instradata a Internet tramite un dispositivo gateway (NAT). Ciò indica che la richiesta NON usa collegamenti privati e che è necessario risolvere alcuni problemi. I motivi comuni per cui accade sono 1) l'endpoint privato non è in stato approvato e riuscito; e 2) il nome host non risolve l'indirizzo IP privato dell'insieme di credenziali delle chiavi. Questo articolo include le azioni di risoluzione dei problemi per entrambi i casi.

Nota

Se la richiesta a /healthstatus funziona, ma l'intestazione x-ms-keyvault-network-info non è presente, è probabile che l'endpoint non venga gestito dall'insieme di credenziali delle chiavi. Poiché i comandi precedenti convalidano anche il certificato HTTPS, l'intestazione mancante potrebbe essere un segno di manomissione.

Eseguire direttamente query sull'indirizzo IP dell'insieme di credenziali delle chiavi

Importante

L'accesso all'insieme di credenziali delle chiavi senza convalida del certificato HTTPS è pericoloso e può essere usato solo a scopo di apprendimento. Il codice di produzione non deve MAI accedere all'insieme di credenziali delle chiavi senza questa convalida lato client. Anche se si stanno solo diagnosticando i problemi, è possibile che si verifichino tentativi di manomissione che non verranno rivelati se si disabilita spesso la convalida del certificato HTTPS nelle richieste all'insieme di credenziali delle chiavi.

Se è stata installata una versione recente di PowerShell, è possibile usare -SkipCertificateCheck per ignorare i controlli dei certificati HTTPS, è possibile impostare come destinazione direttamente l'indirizzo IP dell'insieme di credenziali delle chiavi:

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

Se si usa curl, è possibile eseguire la stessa operazione con l'argomento -k:

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

Le risposte devono corrispondere alla sezione precedente, il che significa che deve includere l'intestazione x-ms-keyvault-network-info con lo stesso valore. Per l'endpoint /healthstatus non è importante se si usa il nome host o l'indirizzo IP dell'insieme di credenziali delle chiavi.

Se si vede che x-ms-keyvault-network-info restituisce un valore per la richiesta usando il nome host dell'insieme di credenziali delle chiavi e un altro valore per la richiesta usando l'indirizzo IP, ogni richiesta è destinata a un endpoint diverso. Fare riferimento alla spiegazione del campo addr di x-ms-keyvault-network-info nella sezione precedente per decidere quale caso è errato e deve essere corretto.

8. Altre modifiche e personalizzazioni che causano un impatto

Gli elementi seguenti sono azioni di indagine non esaustive. Indicano dove cercare altri problemi, ma è necessario avere conoscenze di rete avanzate per risolvere i problemi in questi scenari.

Diagnosticare i server DNS personalizzati nella rete virtuale

Nel portale aprire la risorsa Rete virtuale. Nel menu a sinistra aprire Server DNS. Se si usa "Personalizzato", la risoluzione DNS potrebbe non essere come descritto in questo documento. È necessario diagnosticare il modo in cui i server DNS risolvono il nome host dell'insieme di credenziali delle chiavi.

Se si usano i server DNS predefiniti forniti da Azure, questo intero documento è applicabile.

Diagnosticare gli host che eseguono l'override o i server DNS personalizzati nella macchina virtuale

Molti sistemi operativi consentono di impostare un indirizzo IP fisso esplicito per ogni nome host, in genere modificando il file hosts. Possono anche consentire l'override dei server DNS. Se si usa uno di questi scenari, procedere con opzioni di diagnostica specifiche del sistema.

Proxy promiscui (Fiddler e così via)

Tranne quando indicato in modo esplicito, le opzioni di diagnostica in questo articolo funzionano solo se non è presente alcun proxy promiscuo nell'ambiente. Anche se questi proxy vengono spesso installati esclusivamente nel computer che viene sottoposto a diagnosi (Fiddler è l'esempio più comune), gli amministratori avanzati possono sovrascrivere le autorità di certificazione radice (CA) e installare un proxy promiscuo nei dispositivi gateway che servono più computer nella rete. Questi proxy possono influire in modo sostanziale sulla sicurezza e sull'affidabilità. Microsoft non supporta le configurazioni che usano tali prodotti.

Altri elementi che possono influire sulla connettività

Questo è un elenco non esaustivo di elementi disponibili in scenari avanzati o complessi:

  • Impostazioni del firewall, Firewall di Azure connesso alla rete virtuale o una soluzione firewall personalizzata che distribuisce nella rete virtuale o nel computer.
  • Peering di rete, che può influire su quali server DNS vengono usati e su come viene instradato il traffico.
  • Soluzioni di gateway personalizzato (NAT), che possono influire sul modo in cui viene instradato il traffico, incluso il traffico dalle query DNS.