Risolvere i problemi di rete virtuale

Questo articolo fornisce indicazioni per la risoluzione dei problemi relativi agli scenari comuni per le reti virtuali in Microsoft Power Platform. L'articolo è incentrato su come usare il modulo Di PowerShell Microsoft.PowerPlatform.EnterprisePolicies per identificare e risolvere i problemi relativi alle configurazioni di rete virtuale.

Usare il modulo powerShell di diagnostica

Il Microsoft.PowerPlatform.EnterprisePolicies modulo PowerShell consente di diagnosticare e risolvere i problemi relativi alle configurazioni di rete virtuale in Power Platform. È possibile usare lo strumento per controllare la connettività tra l'ambiente Power Platform e la rete virtuale. È anche possibile usarlo per identificare eventuali configurazioni errate che potrebbero causare problemi. Il modulo di diagnostica di PowerShell è disponibile da PowerShell Gallery e dal relativo repository GitHub, PowerPlatform-EnterprisePolicies.

Installare il modulo

Per installare il modulo Di PowerShell di diagnostica, eseguire il comando di PowerShell seguente:

Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies

Eseguire le funzioni di diagnostica

Dopo aver installato il modulo, importarlo nella sessione di PowerShell eseguendo il comando seguente:

Import-Module Microsoft.PowerPlatform.EnterprisePolicies

Il modulo include diverse funzioni per diagnosticare e risolvere i problemi relativi alle configurazioni di rete virtuale. Alcune delle funzioni chiave sono:

• Get-EnvironmentRegion: recupera l'area dell'ambiente Power Platform specificato.
• Get-EnvironmentUsage: fornisce informazioni sull'utilizzo dell'ambiente Power Platform specificato.
• Test-DnsResolution: testa la risoluzione DNS per il nome di dominio specificato.
• Test-NetworkConnectivity: verifica la connettività di rete tra l'ambiente Power Platform e la risorsa di destinazione.
• Test-TLSHandshake: verifica se un handshake TLS può essere stabilito tra l'ambiente Power Platform e la risorsa di destinazione.

Per un elenco completo delle funzioni disponibili all'interno del modulo di diagnostica, vedere Modulo Microsoft.PowerPlatform.EnterprisePolicies.

Segnalare i problemi nel modulo di diagnostica

Se si verificano problemi durante l'esecuzione del modulo di diagnostica, segnalarli tramite il repository GitHub in cui è ospitato il modulo. Il repository è disponibile in: PowerPlatform-EnterprisePolicies.

Per segnalare un problema, passare alla sezione Problemi del repository e aprire un nuovo problema. Fornire informazioni dettagliate sul problema riscontrato. Includere eventuali messaggi di errore o voci di log che potrebbero essere utili quando si esamina il problema. Non includere informazioni riservate nel report.

Risolvere i problemi comuni

Un ambiente funziona ma un altro non funziona

Se tutto è configurato correttamente, ma si verificano ancora problemi, usare la funzione Get-EnvironmentRegion dal modulo powerShell di diagnostica per verificare se le aree degli ambienti Power Platform sono le stesse. Esegui questo comando:

Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"

Se gli ambienti si trovano in aree diverse e uno funziona ma l'altro non lo è, il problema si verifica nella configurazione della rete virtuale per l'area con errori. Per assicurarsi che l'installazione completa sia configurata correttamente, eseguire eventuali altri comandi di diagnostica in entrambe le aree. Per specificare un'area, includere il -Region parametro . Per esempio:

Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>" -Region "<AzureRegion>"

L'ambiente appartiene a un'area geografica specifica di Power Platform. Tuttavia, un'area di Power Platform può estendersi su due aree di Azure. L'ambiente può trovarsi in entrambe le aree e può anche eseguire automaticamente il failover tra di essi. Pertanto, per garantire disponibilità elevata e connettività, è necessario configurare le reti virtuali in entrambe le aree di Azure associate all'area di Power Platform. Per informazioni sul mapping delle aree di Power Platform alle aree di Azure che supportano la funzionalità di rete virtuale, vedere Aree di Power Platform.

Nome host non trovato

Se si verificano problemi che influiscono sulla risoluzione dei nomi host, usare la funzione Test-DnsResolution del modulo Di PowerShell di diagnostica per verificare se il nome host viene risolto correttamente. Esegui questo comando:

Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>"

Questo comando verifica la risoluzione DNS per il nome host specificato nel contesto dell'ambiente Power Platform. La richiesta viene avviata dalla subnet delegata e tenta di risolvere il nome host usando il server DNS configurato per la rete virtuale. Se il nome host non viene risolto correttamente, potrebbe essere necessario controllare le impostazioni DNS per assicurarsi che il nome host sia configurato correttamente.

La richiesta usa un indirizzo IP pubblico anziché l'indirizzo IP privato

Se si verificano problemi in cui le richieste a una risorsa usano un indirizzo IP pubblico anziché l'indirizzo IP privato, la risoluzione DNS per il nome host della risorsa potrebbe restituire un indirizzo IP pubblico. Questo problema può influire sulle risorse di Azure e non di Azure.

Risorsa non di Azure senza un endpoint privato

Se una risorsa non di Azure non ha un endpoint privato, ma è possibile accedervi dalla rete virtuale, è necessario configurare il server DNS per risolvere il nome host della risorsa nel relativo indirizzo IP privato. Aggiungere un record DNS A al server DNS che esegue il mapping del nome host della risorsa al relativo indirizzo IP privato:

• Se si usa un server DNS personalizzato, aggiungere il record A direttamente al server.
• Se si usa un DNS fornito da Azure, creare una zona DNS privato di Azure e collegarla alla rete virtuale. Aggiungere quindi il record A alla zona DNS privata.

Questo mapping garantisce di accedere alla risorsa tramite il relativo indirizzo IP privato.

Risorsa di Azure con un endpoint privato

Se una risorsa di Azure ha un endpoint privato, la risoluzione DNS per il nome host della risorsa deve restituire l'indirizzo IP privato associato all'endpoint privato. Se la risoluzione DNS restituisce invece un indirizzo IP pubblico, i record nella configurazione DNS potrebbero essere incompleti. Segui questi passaggi:

1. Verificare che esista una zona DNS privata per il tipo di risorsa. Ad esempio, privatelink.database.windows.net per il database SQL di Azure. Se la zona DNS privata non esiste, crearne una.
2. Verificare che la zona DNS privata sia collegata alla rete virtuale. Se la zona DNS privata non è collegata alla rete virtuale, collegarla.

Dopo aver collegato la zona privata DNS alla rete virtuale, l'hostname della risorsa dovrebbe risolversi nell'indirizzo IP privato associato all'endpoint privato.

Testare le modifiche alla configurazione DNS

Dopo aver aggiornato la configurazione DNS, usare la funzione Test-DnsResolution dal modulo powerShell di diagnostica per verificare che il nome host venga risolto nell'indirizzo IP privato corretto. Esegui questo comando:

Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>"

Non è possibile connettersi alla risorsa

Se si verificano problemi che influiscono sulla connettività a una risorsa, usare la funzione Test-NetworkConnectivity dal modulo PowerShell di diagnostica per verificare la connettività. Esegui questo comando:

Test-NetworkConnectivity -EnvironmentId "<EnvironmentId>" -Destination "<ResourceAddress>" -Port 1433

Questo comando tenta di stabilire una connessione TCP alla destinazione e alla porta specificate nel contesto dell'ambiente Power Platform. La richiesta viene avviata dalla subnet delegata e tenta di connettersi alla destinazione specificata usando la configurazione di rete dalla rete virtuale. Se la connessione non riesce, potrebbe essere necessario controllare le impostazioni di rete per assicurarsi che la destinazione sia raggiungibile dalla rete virtuale. Una connessione riuscita indica che la connettività di rete esiste tra l'ambiente Power Platform e la risorsa specificata.

Non è possibile stabilire un handshake TLS

Alcuni firewall potrebbero consentire la creazione di connessioni TCP, ma bloccano il traffico effettivo verso la risorsa, ad esempio HTTPS. Pertanto, anche se la funzione Test-NetworkConnectivity indica la connettività di rete, tale stato non garantisce che la risorsa sia completamente accessibile.

Usare la funzione Test-TLSHandshake per diagnosticare il motivo per cui non è possibile stabilire un handshake. Esegui questo comando:

Test-TLSHandshake -EnvironmentId "<EnvironmentId>" -Destination "<ResourceAddress>" -Port 1433

Questo comando restituisce informazioni che consentono di eseguire il debug del motivo per cui l'handshake non è riuscito. L'output include il certificato presentato dal server, la suite di crittografia, il protocollo ed eventuali descrizioni degli errori SSL.

La connettività ha esito positivo, ma l'applicazione non funziona ancora

Se i test di connettività hanno esito positivo, ma si verificano ancora problemi nell'applicazione, controllare le impostazioni e le configurazioni a livello di applicazione:

1. Verificare che il firewall consenta l'accesso dalla subnet delegata alla risorsa.
2. Verificare che il certificato presentato dalla risorsa sia attendibile pubblicamente.
3. Assicurarsi che nessun problema di autenticazione o autorizzazione impedisca l'accesso alla risorsa.

È possibile che non sia possibile diagnosticare o risolvere il problema usando il modulo Di PowerShell di diagnostica. In questo caso, creare una subnet senza delega nella rete virtuale e distribuire una macchina virtuale (VM) in tale subnet. È quindi possibile usare la macchina virtuale per eseguire ulteriori passaggi di diagnostica e risoluzione dei problemi, ad esempio il controllo del traffico di rete, l'analisi dei log e il test della connettività a livello di applicazione.

Scenari di risoluzione dei problemi di esempio

Incontra Contoso LLC, una società multi-nazionale che dispone di più ambienti Power Platform in tutta Europa e reti virtuali in Europa occidentale ed Europa settentrionale. Ogni rete virtuale ha una subnet delegata a Power Platform. Ogni subnet è associata a criteri aziendali collegati all'ambiente Power Platform.

Gli scenari seguenti illustrano in che modo Contoso usa i cmdlet di diagnostica forniti nelle sezioni precedenti per risolvere i problemi di connettività che influiscono su questa configurazione.

Connettersi a un Azure Key Vault tramite un endpoint privato

Contoso vuole che gli ambienti Power Platform si connettano al Key Vault tramite la rete virtuale e configura il Key Vault per rifiutare le richieste da Internet pubblica. Quando Contoso tenta di connettersi all'Azure Key Vault dall'ambiente aziendale, l'accesso viene negato perché le richieste non vengono instradate correttamente. Per diagnosticare il problema, Contoso usa la procedura di risoluzione dei problemi seguente.

Prima di tutto, esegue Get-EnvironmentRegion per verificare le richieste di subnet inviate a:

Get-EnvironmentRegion -EnvironmentId "00000000-0000-0000-0000-000000000001"
Get-EnvironmentRegion -EnvironmentId "00000000-0000-0000-0000-000000000002"

L'area restituita identifica la rete virtuale da analizzare. Ad esempio, se il comando restituisce Europa occidentale, Contoso deve concentrarsi sulla risoluzione dei problemi nella rete virtuale europa occidentale.

Contoso verifica quindi che l'indirizzo IP restituito dalla risoluzione DNS del fully qualified domain name (FQDN) del key vault sia un indirizzo IP privato. Poiché l'azienda dispone di ambienti in entrambe le aree, deve testare la risoluzione DNS per ogni area usando Test-DnsResolution:

Test-DnsResolution -EnvironmentId "00000000-0000-0000-0000-000000000001" -HostName "contoso-keyvault.vault.azure.net" -Region "westeurope"
Test-DnsResolution -EnvironmentId "00000000-0000-0000-0000-000000000001" -HostName "contoso-keyvault.vault.azure.net" -Region "northeurope"

Se la risoluzione DNS restituisce un indirizzo IP pubblico anziché un indirizzo IP privato, l'endpoint privato per il Key Vault potrebbe non essere configurato correttamente. Contoso deve verificare che:

1. Esiste un endpoint privato per il Key Vault ed è associato alla rete virtuale appropriata.
2. Una zona DNS privata esiste per il Key Vault (ad esempio, privatelink.vaultcore.azure.net), ed è collegata alla rete virtuale.
3. La zona DNS privata contiene un record A che associa il nome host del Key Vault all'indirizzo IP privato dell'endpoint privato.

Quando Contoso esegue il test di risoluzione DNS per l'Europa occidentale, l'azienda rileva che il comando restituisce un indirizzo IP pubblico. Dopo l'indagine dell'azienda, si accorge che la zona DNS privata per il key vault non è stata collegata alla rete virtuale dell'Europa Occidentale. Dopo che Contoso collega la zona DNS privata alla rete virtuale ed esegue nuovamente il test, la risoluzione DNS restituisce l'indirizzo IP privato corretto.

Dopo che la risoluzione DNS restituisce l'indirizzo IP privato corretto in entrambe le regioni, il passaggio successivo consiste nel testare la connettività di rete al key vault utilizzando Test-NetworkConnectivity:

Test-NetworkConnectivity -EnvironmentId "00000000-0000-0000-0000-000000000001" -Destination "contoso-keyvault.vault.azure.net" -Port 443 -Region "westeurope"
Test-NetworkConnectivity -EnvironmentId "00000000-0000-0000-0000-000000000001" -Destination "contoso-keyvault.vault.azure.net" -Port 443 -Region "northeurope"

Se la connessione non riesce, le regole del gruppo di sicurezza di rete o le impostazioni del firewall potrebbero bloccare il traffico dalla subnet delegata all'insieme di chiavi. Contoso deve verificare se:

1. Le regole NSG associate alla subnet delegata consentono il traffico in uscita sulla porta 443.
2. Il firewall della cassaforte delle chiavi consente connessioni in ingresso dall'intervallo IP della subnet delegata.
3. Qualsiasi appliance virtuale di rete o firewall di Azure nel percorso del traffico consente la connessione.

In questo caso, Contoso rileva che il firewall dell'insieme di credenziali delle chiavi segrete non è stato configurato per consentire le connessioni in ingresso da qualsiasi sorgente privata. Dopo aver aggiornato le impostazioni del firewall per consentire le connessioni dalla subnet delegata, il test di connettività di rete viene superato e il Power Platform Environment può connettersi correttamente al Key Vault tramite la rete virtuale.

Connettersi a un server Web ospitato in una rete locale

Contoso vuole anche che l'ambiente Power Platform si connetta a un server Web ospitato nella rete locale. Il server Web è accessibile tramite la rete virtuale della società tramite una connessione ExpressRoute . Quando Contoso tenta di connettersi al server Web dall'ambiente Power Platform, la connessione non riesce.

Anche se la risoluzione DNS restituisce l'indirizzo IP corretto e il test di connettività di rete ha esito positivo, Contoso non riesce ancora ad accedere al server Web. Per diagnosticare questo problema, l'azienda testa l'handshake TLS usando Test-TLSHandshake:

Test-TLSHandshake -EnvironmentId "00000000-0000-0000-0000-000000000001" -Destination "webserver.contoso.local" -Port 443 -Region "westeurope"

Se l'handshake TLS ha esito negativo, l'output fornisce informazioni dettagliate sul certificato, sulla suite di crittografia e sul protocollo usati. Contoso può usare queste informazioni per identificare eventuali problemi di configurazione tls o certificato. Il comando esegue un'analisi iniziale dell'output restituito e segnala alcuni problemi di base. Tuttavia, Contoso può analizzare l'output completo per analizzare il problema in modo più dettagliato.

In questo caso, Contoso rileva che l'handshake TLS non può essere stabilito perché il certificato non è attendibile. Dopo che l'azienda esamina i dettagli del certificato nell'output del comando, determina che il server Web usa un certificato autofirmato. Power Platform richiede certificati pubblicamente attendibili per le connessioni TLS. Dopo che Contoso aggiorna il server Web per l'uso di un certificato firmato da un'autorità di certificazione attendibile pubblicamente, l'handshake TLS ha esito positivo e l'ambiente Power Platform può connettersi al server Web.

Per altre informazioni sulle autorità di certificazione attendibili dai servizi di Azure, vedere Dettagli dell'autorità di certificazione di Azure.