Solucionar problemas de rede virtual

Este artigo fornece diretrizes para solucionar problemas de cenários comuns para redes virtuais no Microsoft Power Platform. O artigo se concentra em como usar o módulo Microsoft.PowerPlatform.EnterprisePolicies PowerShell para ajudá-lo a identificar e resolver problemas relacionados às configurações de rede virtual.

Usar o módulo de diagnóstico do PowerShell

O módulo do Microsoft.PowerPlatform.EnterprisePolicies PowerShell ajuda você a diagnosticar e solucionar problemas relacionados às configurações de rede virtual no Power Platform. Você pode usar a ferramenta para verificar a conectividade entre seu ambiente do Power Platform e sua rede virtual. Você também pode usá-lo para identificar quaisquer configurações incorretas que possam causar problemas. O módulo de diagnóstico do PowerShell está disponível na Galeria do PowerShell e em seu repositório GitHub, PowerPlatform-EnterprisePolicies.

Instalar o módulo

Para instalar o módulo de diagnóstico do PowerShell, execute o seguinte comando do PowerShell:

Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies

Executar as funções de diagnóstico

Depois de instalar o módulo, importe-o para sua sessão do PowerShell executando o seguinte comando:

Import-Module Microsoft.PowerPlatform.EnterprisePolicies

O módulo inclui várias funções para diagnosticar e solucionar problemas relacionados às configurações de rede virtual. Algumas das principais funções são:

• Get-EnvironmentRegion: recupera a região do ambiente do Power Platform especificado.
• Get-EnvironmentUsage: fornece informações sobre o uso do ambiente do Power Platform especificado.
• Test-DnsResolution: testa a resolução DNS para o nome de domínio especificado.
• Test-NetworkConnectivity: testa a conectividade de rede entre o ambiente do Power Platform e o recurso de destino.
• Test-TLSHandshake: testa se um handshake TLS pode ser estabelecido entre o ambiente do Power Platform e o recurso de destino.

Para obter uma lista completa das funções disponíveis no módulo de diagnóstico, consulte o Módulo Microsoft.PowerPlatform.EnterprisePolicies.

Relatar problemas no módulo de diagnóstico

Se você encontrar problemas ao executar o módulo de diagnóstico, relate-os por meio do repositório GitHub em que o módulo está hospedado. O repositório está disponível em: PowerPlatform-EnterprisePolicies.

Para relatar um problema, vá para a seção Problemas do repositório e abra um novo problema. Forneça informações detalhadas sobre o problema encontrado. Inclua mensagens de erro ou entradas de log que possam ajudar ao investigar o problema. Não inclua informações confidenciais em seu relatório.

Solução de problemas comuns

Um ambiente funciona, mas outro não

Se tudo estiver configurado corretamente, mas você ainda encontrar problemas, use a função Get-EnvironmentRegion do módulo de diagnóstico do PowerShell para verificar se as regiões de seus ambientes do Power Platform são as mesmas. Execute o comando a seguir:

Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"

Se os ambientes estiverem em regiões diferentes e um funcionar, mas o outro não funcionar, o problema estará na configuração da rede virtual para a região com falha. Para garantir que a configuração completa esteja configurada corretamente, execute quaisquer comandos de diagnóstico adicionais em ambas as regiões. Para especificar uma região, inclua o -Region parâmetro. Por exemplo:

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

Seu ambiente pertence a uma geografia específica do Power Platform. No entanto, uma região do Power Platform pode abranger duas regiões do Azure. Seu ambiente pode estar localizado em qualquer região e também pode fazer failover automaticamente entre elas. Portanto, para garantir alta disponibilidade e conectividade, você precisa configurar suas redes virtuais em ambas as regiões do Azure associadas à sua região do Power Platform. Para saber como as regiões do Power Platform são mapeadas para regiões do Azure que dão suporte à funcionalidade de rede virtual, consulte as regiões do Power Platform.

Nome do host não encontrado

Se você encontrar problemas que afetam a resolução de nome de host, use a função Test-DnsResolution do módulo de diagnóstico do PowerShell para verificar se o nome do host foi resolvido corretamente. Execute o comando a seguir:

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

Esse comando testa a resolução DNS para o nome do host especificado no contexto do seu ambiente do Power Platform. A solicitação inicia da sub-rede delegada e tenta resolver o nome do host usando o servidor DNS configurado para sua rede virtual. Se o nome do host não for resolvido corretamente, talvez seja necessário verificar as configurações de DNS para verificar se o nome do host está configurado corretamente.

A solicitação usa um endereço IP público em vez do endereço IP privado

Se você encontrar problemas nos quais as solicitações a um recurso usam um endereço IP público em vez do endereço IP privado, a resolução DNS para o nome do host do recurso poderá estar retornando um endereço IP público. Esse problema pode afetar recursos do Azure e não do Azure.

Recurso não-Azure sem ponto de extremidade privado

Se um recurso não-Azure não tiver um ponto de extremidade privado, mas você puder acessá-lo de sua rede virtual, será necessário configurar o servidor DNS para resolver o nome de host do recurso para o seu endereço IP privado. Adicione um registro DNS A ao servidor DNS que mapeia o nome do host do recurso para seu endereço IP privado:

• Se você estiver usando um servidor DNS personalizado, adicione o registro A diretamente ao servidor.
• Se você estiver usando um DNS fornecido pelo Azure, crie uma Zona DNS Privada do Azure e vincule-a à sua rede virtual. Em seguida, adicione o registro A à zona DNS privada.

Esse mapeamento garante que você acesse o recurso por meio de seu endereço IP privado.

Recurso do Azure que possui um ponto de extremidade privado

Se um recurso do Azure tiver um ponto de extremidade privado, a resolução DNS para o nome do host do recurso deverá retornar o endereço IP privado associado ao ponto de extremidade privado. Se a resolução DNS retornar, em vez disso, um endereço IP público, é possível que sua configuração de DNS esteja faltando registros. Siga estas etapas:

1. Verifique se existe uma zona DNS privada para o tipo de recurso. Por exemplo, privatelink.database.windows.net para o Banco de Dados SQL do Azure. Se a zona DNS privada não existir, crie uma.
2. Verifique se a zona DNS privada está vinculada à sua rede virtual. Se a zona DNS privada não estiver vinculada à sua rede virtual, vincule-a.

Depois de vincular a zona DNS privada à sua rede virtual, o nome do host do recurso deverá ser resolvido para o endereço IP privado associado ao ponto de extremidade privado.

Testar alterações de configuração de DNS

Depois de atualizar a configuração de DNS, use a função Test-DnsResolution do módulo de diagnóstico do PowerShell para verificar se o nome do host é resolvido para o endereço IP privado correto. Execute o comando a seguir:

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

Não é possível se conectar ao recurso

Se você tiver problemas que afetam a conectividade com um recurso, use a função Test-NetworkConnectivity do módulo de diagnóstico do PowerShell para verificar a conectividade. Execute o comando a seguir:

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

Esse comando tenta estabelecer uma conexão TCP com o destino e a porta especificados no contexto do seu ambiente do Power Platform. A solicitação é iniciada a partir da sub-rede delegada e tenta se conectar ao destino especificado usando a configuração de rede da rede virtual. Se a conexão falhar, talvez seja necessário verificar as configurações de rede para verificar se o destino está acessível na rede virtual. Uma conexão bem-sucedida indica que a conectividade de rede existe entre o ambiente do Power Platform e o recurso especificado.

Não é possível estabelecer um TLS handshake

Alguns firewalls podem permitir que conexões TCP sejam estabelecidas, mas bloqueiam o tráfego real para o recurso (por exemplo, HTTPS). Portanto, mesmo que a função Test-NetworkConnectivity indique conectividade de rede, esse status não garante que o recurso esteja totalmente acessível.

Use a função Test-TLSHandshake para diagnosticar por que um handshake não pode ser estabelecido. Execute o comando a seguir:

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

Esse comando retorna informações que podem ajudá-lo a depurar por que o handshake falhou. A saída inclui o certificado que o servidor apresentou, o conjunto de criptografias, o protocolo e quaisquer descrições de erro SSL.

A conectividade é bem-sucedida, mas o aplicativo ainda não está funcionando

Se os testes de conectividade forem bem-sucedidos, mas você ainda estiver enfrentando problemas em seu aplicativo, verifique as configurações e as configurações no nível do aplicativo:

1. Verifique se o firewall permite o acesso da sub-rede delegada ao recurso.
2. Verifique se o certificado que o recurso apresenta é publicamente confiável.
3. Verifique se nenhum problema de autenticação ou autorização impede o acesso ao recurso.

Talvez você não consiga diagnosticar ou resolver o problema usando o módulo de diagnóstico do PowerShell. Nesse caso, crie uma sub-rede sem delegação em sua rede virtual e implante uma VM (máquina virtual) nessa sub-rede. Em seguida, você pode usar a VM para executar mais etapas de diagnóstico e solução de problemas, como verificar o tráfego de rede, analisar logs e testar a conectividade no nível do aplicativo.

Exemplo de cenários de solução de problemas

Conheça a Contoso LLC, uma empresa multinacional que tem vários ambientes do Power Platform em toda a Europa e redes virtuais na Europa Ocidental e Norte da Europa. Cada rede virtual tem uma sub-rede delegada ao Power Platform. Cada sub-rede está associada a uma política empresarial vinculada ao ambiente do Power Platform.

Os cenários a seguir mostram como a Contoso usa os cmdlets de diagnóstico fornecidos nas seções anteriores para solucionar problemas de conectividade que afetam essa configuração.

Conectar-se a um Azure Key Vault por meio de ponto de extremidade privado

A Contoso quer que seus ambientes do Power Platform se conectem ao cofre de chaves por meio da rede virtual e configure o cofre de chaves para rejeitar solicitações da Internet pública. Quando a Contoso tenta se conectar ao Key Vault do seu ambiente, a conexão é rejeitada porque as solicitações não são roteadas corretamente. Para diagnosticar o problema, a Contoso usa as seguintes etapas de solução de problemas.

Primeiro, ele executa Get-EnvironmentRegion para verificar quais solicitações de sub-rede são enviadas para:

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

A região retornada identifica qual rede virtual deve ser investigada. Por exemplo, se o comando retornar a Europa Ocidental, a Contoso terá que se concentrar na solução de problemas na rede virtual da Europa Ocidental.

Em seguida, a Contoso verifica se o endereço IP retornado pela resolução DNS do nome de domínio totalmente qualificado (FQDN) do cofre de chaves é um endereço IP privado. Como a empresa tem ambientes em ambas as regiões, ela precisa testar a resolução de DNS para cada região 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 a resolução DNS retornar um endereço IP público em vez de um endereço IP privado, o ponto de extremidade privado do cofre de chaves poderá não estar configurado corretamente. A Contoso precisa verificar se:

1. Existe um ponto de extremidade privado para o cofre de chaves, e ele está associado à rede virtual correta.
2. Existe uma zona DNS privada para o cofre de chaves (por exemplo), privatelink.vaultcore.azure.nete está vinculada à rede virtual.
3. A zona DNS privada contém um registro A que mapeia o nome do host do cofre de chaves para o endereço IP privado do ponto de extremidade privado.

Quando a Contoso executa o teste de resolução DNS para a Europa Ocidental, a empresa descobre que o comando retorna um endereço IP público. Depois que a empresa investiga, ela descobre que a zona DNS privada do cofre de chaves não estava vinculada à rede virtual da Europa Ocidental. Depois que a Contoso vincula a zona DNS privada à rede virtual e executa novamente o teste, a resolução DNS retorna o endereço IP privado correto.

Depois que a resolução DNS retornar o endereço IP privado correto em ambas as regiões, a próxima etapa é testar a conectividade de rede com o cofre de chaves usando 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 a conexão falhar, as regras do NSG (grupo de segurança de rede) ou as configurações de firewall poderão estar bloqueando o tráfego da sub-rede delegada para o cofre de chaves. Contoso precisa verificar se:

1. As regras NSG associadas à sub-rede delegada permitem o tráfego de saída na porta 443.
2. O firewall do Key Vault permite conexões de entrada do intervalo de IP da sub-rede delegada.
3. Qualquer firewall do Azure ou dispositivo virtual de rede no caminho de tráfego permite a conexão.

Nesse caso, a Contoso descobre que o firewall do cofre de chaves não foi configurado para permitir conexões de entrada de nenhuma fonte privada. Depois que as configurações de firewall são atualizadas para permitir conexões da sub-rede delegada, o teste de conectividade de rede é bem-sucedido e o ambiente do Power Platform pode se conectar com êxito ao cofre de chaves por meio da rede virtual.

Conectar-se a um servidor Web hospedado em uma rede local

A Contoso também deseja que seu ambiente do Power Platform se conecte a um servidor Web hospedado em sua rede local. O servidor Web é acessível por meio da rede virtual da empresa por meio de uma conexão do ExpressRoute . Quando a Contoso tenta se conectar ao servidor Web a partir de seu ambiente do Power Platform, a conexão falha.

Embora a resolução DNS retorne o endereço IP correto e o teste de conectividade de rede seja bem-sucedido, a Contoso ainda não pode acessar o servidor Web. Para diagnosticar esse problema, a empresa testa o handshake do TLS usando Test-TLSHandshake:

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

Se o handshake do TLS falhar, a saída fornecerá detalhes sobre o certificado, o pacote de criptografia e o protocolo que foram usados. A Contoso pode usar essas informações para identificar quaisquer problemas de configuração de certificado ou TLS. O comando faz uma análise inicial da saída retornada e alertas sobre alguns problemas básicos. No entanto, a Contoso pode analisar a saída completa para investigar o problema com mais detalhes.

Nesse caso, a Contoso descobre que o handshake do TLS não pode ser estabelecido porque o certificado não é confiável. Depois que a empresa investiga os detalhes do certificado na saída do comando, ela determina que o servidor Web está usando um certificado autoassinado. O Power Platform requer certificados publicamente confiáveis para conexões TLS. Depois que a Contoso atualiza o servidor Web para usar um certificado assinado por uma autoridade de certificação publicamente confiável, o handshake do TLS é bem-sucedido e o ambiente do Power Platform pode se conectar ao servidor Web.

Para obter mais informações sobre autoridades de certificação confiáveis pelos serviços do Azure, consulte os detalhes da Autoridade de Certificação do Azure.