Solución de problemas de red virtual

En este artículo se proporcionan instrucciones para solucionar problemas de escenarios comunes para redes virtuales en Microsoft Power Platform. El artículo se centra en cómo usar el módulo de PowerShell Microsoft.PowerPlatform.EnterprisePolicies para ayudarle a identificar y resolver problemas relacionados con las configuraciones de red virtual.

Uso del módulo de PowerShell de diagnóstico

El Microsoft.PowerPlatform.EnterprisePolicies módulo de PowerShell le ayuda a diagnosticar y solucionar problemas relacionados con las configuraciones de red virtual en Power Platform. Puede usar la herramienta para comprobar la conectividad entre el entorno de Power Platform y la red virtual. También puede usarlo para identificar cualquier configuración incorrecta que pueda causar problemas. El módulo de PowerShell de diagnóstico está disponible en la Galería de PowerShell y en su repositorio de GitHub , PowerPlatform-EnterprisePolicies.

Instalación del módulo

Para instalar el módulo de PowerShell de diagnóstico, ejecute el siguiente comando de PowerShell:

Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies

Ejecución de las funciones de diagnóstico

Después de instalar el módulo, impórtelo en la sesión de PowerShell mediante la ejecución del siguiente comando:

Import-Module Microsoft.PowerPlatform.EnterprisePolicies

El módulo incluye varias funciones para diagnosticar y solucionar problemas relacionados con las configuraciones de red virtual. Algunas de las funciones clave son:

• Get-EnvironmentRegion: recupera la región del entorno de Power Platform especificado.
• Get-EnvironmentUsage: proporciona información sobre el uso del entorno de Power Platform especificado.
• Test-DnsResolution: prueba la resolución DNS para el nombre de dominio especificado.
• Test-NetworkConnectivity: comprueba la conectividad de red entre el entorno de Power Platform y el recurso de destino.
• Test-TLSHandshake: comprueba si se puede establecer un protocolo de enlace TLS entre el entorno de Power Platform y el recurso de destino.

Para obtener una lista completa de las funciones disponibles en el módulo de diagnóstico, consulte Módulo Microsoft.PowerPlatform.EnterprisePolicies.

Notificar problemas en el módulo de diagnóstico

Si tiene problemas al ejecutar el módulo de diagnóstico, notifiquelos a través del repositorio de GitHub donde se hospeda el módulo. El repositorio está disponible en: PowerPlatform-EnterprisePolicies.

Para notificar un problema, vaya a la sección Problemas del repositorio y abra un nuevo problema. Proporcione información detallada sobre el problema que encuentre. Incluya los mensajes de error o las entradas de registro que puedan ayudar al investigar el problema. No incluya ninguna información confidencial en el informe.

Solución de problemas comunes

Un entorno funciona, pero otro no

Si todo está configurado correctamente, pero sigue teniendo problemas, use la función Get-EnvironmentRegion del módulo de PowerShell de diagnóstico para comprobar si las regiones de los entornos de Power Platform son las mismas. Ejecute el siguiente comando:

Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"

Si los entornos están en regiones diferentes y uno funciona, pero el otro no, el problema se produce en la configuración de la red virtual para la región con errores. Para asegurarse de que la configuración completa está configurada correctamente, ejecute los comandos de diagnóstico adicionales en ambas regiones. Para especificar una región, incluya el -Region parámetro . Por ejemplo:

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

Su entorno pertenece a una geografía específica de Power Platform. Sin embargo, una región de Power Platform puede abarcar dos regiones de Azure. Tu entorno puede estar ubicado en cualquiera de las regiones y también puede realizar una conmutación por error automáticamente entre ellas. Por lo tanto, para garantizar una alta disponibilidad y conectividad, debe configurar las redes virtuales en ambas regiones de Azure asociadas a la región de Power Platform. Para obtener información sobre cómo las regiones de Power Platform se asignan a las regiones de Azure que admiten la funcionalidad de red virtual, consulte Regiones de Power Platform.

No se encontró el nombre de host

Si encuentra problemas que afectan a la resolución de nombres de host, use la función Test-DnsResolution del módulo de PowerShell de diagnóstico para comprobar si el nombre de host se ha resuelto correctamente. Ejecute el siguiente comando:

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

Este comando prueba la resolución DNS del nombre de host especificado en el contexto del entorno de Power Platform. La solicitud se inicia desde la subred delegada e intenta resolver el nombre de host mediante el servidor DNS configurado para la red virtual. Si el nombre de host no se ha resuelto correctamente, es posible que tenga que comprobar la configuración de DNS para asegurarse de que el nombre de host está configurado correctamente.

Importante

Si observa que la configuración de DNS es incorrecta y tiene que actualizar la configuración del servidor DNS de la red virtual, consulte ¿Puedo actualizar la dirección DNS de mi red virtual después de delegarla en "Microsoft.PowerPlatform/enterprisePolicies"?

La solicitud usa una dirección IP pública en lugar de la dirección IP privada

Si encuentra problemas en los que las solicitudes a un recurso usan una dirección IP pública en lugar de la dirección IP privada, la resolución DNS del nombre de host del recurso podría devolver una dirección IP pública. Este problema puede afectar tanto a los recursos de Azure como a los que no son de Azure.

Recurso no-Azure sin un punto de conexión privado

Si un recurso que no es de Azure no tiene un punto de conexión privado, pero puede acceder a él desde la red virtual, debe configurar el servidor DNS para resolver el nombre de host del recurso en su dirección IP privada. Agregue un registro DNS A al servidor DNS que asigne el nombre de host del recurso a su dirección IP privada:

• Si usa un servidor DNS personalizado, agregue el registro A directamente al servidor.
• Si usa un DNS proporcionado por Azure, cree una zona DNS privada de Azure y vincúlela a la red virtual. A continuación, agregue el registro A a la zona DNS privada.

Esta asignación garantiza que accedas al recurso a través de su dirección IP privada.

Recurso de Azure que tiene un punto de conexión privado

Si un recurso de Azure tiene un punto de conexión privado, la resolución DNS del nombre de host del recurso debe devolver la dirección IP privada asociada al punto de conexión privado. Si la resolución DNS devuelve una dirección IP pública en su lugar, es posible que falten registros en la configuración de DNS. Siga estos pasos:

1. Compruebe que existe una zona DNS privada para el tipo de recurso. Por ejemplo, privatelink.database.windows.net para Azure SQL Database. Si la zona DNS privada no existe, cree una.
2. Compruebe que la zona DNS privada esté vinculada a la red virtual. Si la zona DNS privada no está vinculada a la red virtual, vinculela.

Después de vincular la zona DNS privada a la red virtual, el nombre de host del recurso debe resolverse en la dirección IP privada asociada al punto de conexión privado.

Prueba de los cambios de configuración de DNS

Después de actualizar la configuración de DNS, use la función Test-DnsResolution del módulo de PowerShell de diagnóstico para comprobar que el nombre de host se resuelve en la dirección IP privada correcta. Ejecute el siguiente comando:

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

No se puede conectar al recurso

Si experimenta problemas que afectan a la conectividad a un recurso, use la función Test-NetworkConnectivity del módulo de PowerShell de diagnóstico para comprobar la conectividad. Ejecute el siguiente comando:

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

Este comando intenta establecer una conexión TCP con el destino y el puerto especificados en el contexto del entorno de Power Platform. La solicitud se inicia desde la subred delegada e intenta conectarse al destino especificado mediante la configuración de red de la red virtual. Si se produce un error en la conexión, es posible que tenga que comprobar la configuración de red para asegurarse de que el destino es accesible desde la red virtual. Una conexión correcta indica que existe conectividad de red entre el entorno de Power Platform y el recurso especificado.

Nota:

Este comando solo comprueba si se puede establecer una conexión TCP en el destino y el puerto especificados. No comprueba si el recurso está disponible o si algún problema de nivel de aplicación podría impedir el acceso al recurso.

No se puede establecer un intercambio TLS

Algunos firewalls pueden permitir que se establezcan conexiones TCP, pero luego bloquean el tráfico real al recurso (por ejemplo, HTTPS). Por lo tanto, incluso si la función Test-NetworkConnectivity indica la conectividad de red, ese estado no garantiza que el recurso sea totalmente accesible.

Use la función Test-TLSHandshake para diagnosticar por qué no se puede establecer un protocolo de enlace. Ejecute el siguiente comando:

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

Este comando devuelve información que puede ayudarle a depurar por qué se produjo un error en el protocolo de enlace. La salida incluye el certificado que el servidor presentó, el conjunto de cifrado, el protocolo y las descripciones de errores SSL.

Importante

Solo se admiten certificados de confianza pública. Para obtener más información, consulte ¿Admite certificados desconocidos?

La conectividad se realiza correctamente, pero la aplicación sigue sin funcionar

Si las pruebas de conectividad se realizan correctamente, pero sigue experimentando problemas en la aplicación, compruebe la configuración y las configuraciones de nivel de aplicación:

1. Compruebe que el firewall permite el acceso desde la subred delegada al recurso.
2. Compruebe que el certificado que presenta el recurso es de confianza pública.
3. Asegúrese de que ningún problema de autenticación o autorización impida el acceso al recurso.

Es posible que no pueda diagnosticar o resolver el problema mediante el módulo de PowerShell de diagnóstico. En este caso, cree una subred sin delegación en la red virtual e implemente una máquina virtual (VM) en esa subred. A continuación, puede usar la máquina virtual para realizar más diagnósticos y pasos de solución de problemas, como comprobar el tráfico de red, analizar registros y probar la conectividad de nivel de aplicación.

Escenarios de solución de problemas de ejemplo

Conozca Contoso LLC, una empresa multinacional que tiene varios entornos de Power Platform en toda Europa y redes virtuales en Oeste de Europa y Norte de Europa. Cada red virtual tiene una subred delegada a Power Platform. Cada subred está asociada a una directiva empresarial vinculada al entorno de Power Platform.

En los escenarios siguientes se muestra cómo Contoso usa los cmdlets de diagnóstico que se proporcionan en las secciones anteriores para solucionar problemas de conectividad que afectan a esta configuración.

Conexión a una instancia de Azure Key Vault a través de un punto de conexión privado

Contoso quiere que sus entornos de Power Platform se conecten a su almacén de claves a través de la red virtual y configure el almacén de claves para rechazar las solicitudes de la red pública de Internet. Cuando Contoso intenta conectarse al almacén de claves desde su propio entorno, la conexión se rechaza porque las solicitudes no se enrutan correctamente. Para diagnosticar el problema, Contoso usa los siguientes pasos de solución de problemas.

En primer lugar, ejecuta Get-EnvironmentRegion para comprobar a qué solicitudes de subred se envían:

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

La región obtenida identifica qué red virtual se va a investigar. Por ejemplo, si el comando devuelve Europa Occidental, Contoso debe centrarse en solucionar problemas en la red virtual de Europa Occidental.

A continuación, Contoso comprueba que la dirección IP que se obtiene a partir de la resolución DNS del nombre de dominio completamente calificado (FQDN) del almacén de claves es una dirección IP privada. Dado que la empresa tiene entornos en ambas regiones, tiene que probar la resolución DNS para cada región mediante 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"

Si la resolución DNS devuelve una dirección IP pública en lugar de una dirección IP privada, es posible que el punto de conexión privado del almacén de claves no esté configurado correctamente. Contoso tiene que comprobar que:

1. Existe un punto de conexión privado para el almacén de claves y está asociado a la red virtual correcta.
2. Existe una zona DNS privada para el almacén de claves (por ejemplo, privatelink.vaultcore.azure.net) y está vinculada a la red virtual.
3. La zona DNS privada contiene un registro A que asigna el nombre de host del Key Vault a la dirección IP privada del punto de conexión privado.

Cuando Contoso ejecuta la prueba de resolución DNS para Oeste de Europa, la empresa detecta que el comando devuelve una dirección IP pública. Una vez que la empresa investiga, detecta que la zona DNS privada del almacén de claves no estaba vinculada a la red virtual oeste de Europa. Después de que Contoso vincule la zona DNS privada a la red virtual y vuelva a ejecutar la prueba, la resolución DNS devuelve la dirección IP privada correcta.

Después de que la resolución DNS devuelva la dirección IP privada correcta en ambas regiones, el siguiente paso es probar la conectividad de red con el almacén de claves mediante 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"

Si se produce un error en la conexión, las reglas del grupo de seguridad de red (NSG) o la configuración del firewall podrían estar bloqueando el tráfico de la subred delegada al almacén de claves. Contoso tiene que comprobar si:

1. Las reglas de NSG asociadas a la subred delegada permiten el tráfico saliente en el puerto 443.
2. El firewall de la bóveda de claves permite conexiones entrantes desde el rango de IP de la subred delegada.
3. Cualquier Azure Firewall o dispositivo virtual de red en la ruta de acceso de tráfico permite la conexión.

En este caso, Contoso detecta que el firewall del almacén de claves no se configuró para permitir conexiones entrantes desde cualquier origen privado. Una vez actualizada la configuración del firewall para permitir conexiones desde la subred delegada, la prueba de conectividad de red se realiza correctamente y el entorno de Power Platform se puede conectar correctamente al almacén de claves a través de la red virtual.

Conexión a un servidor web hospedado en una red local

Contoso también quiere que su entorno de Power Platform se conecte a un servidor web hospedado en su red local. El servidor web es accesible a través de la red virtual de la empresa a través de una conexión expressRoute . Cuando Contoso intenta conectarse al servidor web desde su entorno de Power Platform, se produce un error en la conexión.

Aunque la resolución DNS devuelve la dirección IP correcta y la prueba de conectividad de red se realiza correctamente, Contoso todavía no puede acceder al servidor web. Para diagnosticar este problema, la empresa prueba el protocolo de enlace TLS mediante Test-TLSHandshake:

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

Si se produce un error en el protocolo de enlace TLS, la salida proporciona detalles sobre el certificado, el conjunto de cifrado y el protocolo que se usaron. Contoso puede usar esta información para identificar cualquier problema de configuración de TLS o certificado. El comando realiza un análisis inicial de la salida devuelta y alertas sobre algunos problemas básicos. Sin embargo, Contoso puede analizar el resultado completo para investigar el problema de manera más detallada.

En este caso, Contoso descubre que no se puede establecer el handshake TLS porque el certificado no es de confianza. Después de que la empresa investigue los detalles del certificado en la salida del comando, determina que el servidor web usa un certificado autofirmado. Power Platform requiere certificados de confianza pública para las conexiones TLS. Una vez que Contoso actualiza el servidor web para usar un certificado firmado por una entidad de certificación de confianza pública, el protocolo de enlace TLS se realiza correctamente y el entorno de Power Platform puede conectarse al servidor web.

Para más información sobre las entidades de certificación de confianza de los servicios de Azure, consulte los detalles de las entidades de certificación de Azure.