Sigue las instrucciones que se indican a continuación para solucionar problemas habituales con las pruebas de conectividad.
Para obtener más información sobre las pruebas de conectividad, consulta la información general.
Para interpretar los estados de un análisis de configuración de una prueba de conectividad, consulta Estados del análisis de configuración.
Incidencias generales
Tarda demasiado en obtener los resultados de las pruebas
Como Connectivity Tests consulta la última instantánea de una configuración de red de nube privada virtual (VPC), puede tardar un tiempo en obtener los resultados. Para obtener más información, consulta los tiempos de respuesta de las consultas esperados.
Si experimentas latencias largas o inestables al ejecutar pruebas de conectividad, informa del problema al equipo de Asistencia y describe cómo reproducirlo.
El análisis de configuración de mi prueba no detecta el cambio de configuración que he hecho
Después de hacer un cambio en la configuración de los recursos de su ruta de prueba, puede usar el análisis de configuración de la prueba para validar el cambio. Google Cloud Sin embargo, las pruebas de conectividad tardan entre 20 y 120 segundos en recibir una actualización de configuración e incorporarla al análisis. Asegúrate de esperar el tiempo suficiente entre el cambio de configuración y la ejecución de las pruebas.
Algunos tipos de configuraciones pueden tardar más en completarse. Si los cambios en la configuración no se verifican con las pruebas de conectividad después de un periodo prolongado y se pueden reproducir, informa del problema al equipo de Asistencia y describe cómo reproducirlo.
Este retraso no se aplica al análisis del plano de datos en tiempo real. Por lo tanto, es posible que vea una discrepancia temporal entre los resultados que se muestran en el análisis del plano de datos activo y en el análisis de la configuración. Por ejemplo, si crea una regla de cortafuegos, el análisis del plano de datos activo suele responder a la nueva regla de inmediato. Sin embargo, es posible que tengas que esperar 20 segundos o más para que el análisis de la configuración pueda evaluar la regla de cortafuegos junto con los demás recursos de la ruta de prueba.
Problemas con el estado de la prueba
No puedo acceder a los detalles de una política de cortafuegos jerárquica
Es posible que la traza de tu prueba haga referencia a una política de cortafuegos jerárquica para la que no tienes permiso de visualización.
Sin embargo, aunque no tengas permiso para ver la política, puedes ver las reglas de la política que se aplican a tu red VPC. Para obtener más información, consulta el artículo Reglas de cortafuegos en vigor de la descripción general de las políticas de cortafuegos jerárquicas.
El acceso a las políticas de cortafuegos jerárquicas se define a nivel de organización y de carpeta. Para obtener información sobre los permisos que necesitas para ver estas políticas, consulta la sección Roles de Gestión de Identidades y Accesos (IAM) del artículo sobre las políticas de cortafuegos jerárquicas.
Mi prueba muestra un estado de análisis de configuración final de Deliver, pero la conectividad no funciona
En algunos casos, el análisis de configuración sugiere que se puede acceder a un endpoint de origen y a otro de destino. Sin embargo, puede que en la práctica la conectividad entre los dos endpoints se interrumpa o que el análisis del plano de datos en tiempo real muestre una pérdida de paquetes del 100 %.
Para entender esta situación, recuerda que Pruebas de conectividad usa dos tipos de análisis: un análisis de configuración, que detecta problemas en las configuraciones activas de tu proyecto, y un análisis del plano de datos en tiempo real, que envía sondeos en el plano de datos.
El estado final del análisis de configuración Deliver
significa que las pruebas de conectividad no han detectado ningún problema de configuración.
Sin embargo, puede que siga habiendo problemas con la ruta de datos que provoquen problemas de conectividad. Para solucionar el problema, ten en cuenta lo siguiente:
- La máquina virtual de origen o de destino tiene problemas con el SO invitado, como un error pánico del kernel del SO invitado, un controlador de interfaz de red (NIC) que no se ha inicializado o controladores de red incompatibles. Comprueba el estado de la VM y la configuración de la NIC.
- Un problema generalizado está afectando al plano de datos de la red. Consulta el Panel de rendimiento de tu proyecto y presta especial atención a la pérdida de paquetes del par de zonas correspondiente. Además, consulta el Google Cloud panel de estado.
- Tu cadena tiene problemas esporádicos de programación de red, como problemas con la propagación de la configuración de red a entidades específicas. Google Cloud Vuelve a ejecutar la prueba después de esperar cinco minutos. Si el problema persiste, detén e inicia la VM de origen o de destino, tal como se describe en Detener e iniciar una instancia, y vuelve a ejecutar la prueba.
Mi prueba ha devuelto un resultado general del análisis de configuración de Undetermined
Si el resultado general de accesibilidad es Undetermined, significa que el análisis de configuración no ha podido determinar la conectividad.
Este resultado puede aparecer por alguno de los siguientes motivos:
- Se ha producido un error de permisos. Por ejemplo, es posible que el usuario no tenga permisos de lectura para todos los recursos que se mencionan en la prueba.
- Se ha producido un error interno.
- El analizador ha recibido un argumento no válido o no admitido, o no ha podido identificar un endpoint conocido.
- Estás intentando verificar una ruta que supera los Google Cloud. Pruebas de conectividad no tiene acceso a las configuraciones de red externas Google Cloud.
Mi prueba ha devuelto un resultado general del análisis de configuración de Ambiguous
Un resultado general del análisis de configuración de
Ambiguous
significa que las pruebas de conectividad han devuelto varias trazas y que
hay un estado final mixto.
En la siguiente tabla se indican algunos de los motivos habituales y las soluciones para este estado.
| Motivo | Ejemplo | Cómo solucionarlo |
|---|---|---|
| La ubicación de origen no es única. | Has especificado una dirección IP de origen interna sin especificar también la red de VPC en la que se encuentra la dirección IP (una dirección IP de origen interna es una dirección a la que no puedes acceder desde Internet). Como se puede acceder a esta dirección desde varias redes de VPC, las pruebas de conectividad pueden iniciar un rastreo desde cada ubicación. | Actualiza la prueba con la red de VPC en la que se encuentra esta dirección IP. |
| El rastreo tiene varios destinos posibles. | El destino de la traza es un balanceador de carga que tiene varios backends o un backend con una política de selección de direcciones IP PREFER_IPV6, y no se puede acceder a todos los backends con todas las versiones de IP configuradas. | Investiga por qué ocurre esto y soluciona los problemas según sea necesario antes de volver a ejecutar la prueba. |
Mi prueba ha devuelto un resultado general del análisis de configuración de Abort con un mensaje Invalid Argument
Estos son algunos de los motivos habituales por los que se muestra el mensaje Invalid Argument:
- La dirección IP que has proporcionado no se admite. Por ejemplo, una dirección de bucle de retorno, una dirección IP de multidifusión o una dirección IPv6 de una instancia de VM que solo tenga asignada una dirección IPv4.
- La instancia de VM o la red especificada no existen. Esta situación puede darse si se ha eliminado la instancia de VM o la red de VPC mientras creabas la prueba.
Cuando se usa la API Network Management, el mensaje Invalid Argument suele devolverse por uno de los siguientes motivos:
- Un nombre mal escrito o una ubicación incorrecta de la máquina virtual o del URI de la red.
- Un ID de proyecto especificado incorrectamente. Este error se produce si has usado el nombre del proyecto en lugar del ID.
- Hay una discrepancia entre la dirección IP interna especificada y la red seleccionada. Aunque la Google Cloud consola de pruebas de conectividad realiza una validación estricta de la instancia, la red y el proyecto de Compute Engine especificados, este tipo de error puede seguir produciéndose.
El resultado del análisis de configuración es Packet could not be delivered, pero el análisis del plano de datos activo indica que se han enviado todos los paquetes
Esta aparente incongruencia puede deberse a varios motivos. Ten en cuenta las siguientes posibles causas y soluciones:
Los cambios recientes en la configuración de la red de VPC han provocado una incoherencia entre el análisis de configuración y la comprobación activa. Vuelve a ejecutar la prueba y asegúrate, si es posible, de que la configuración de red no cambie justo antes de la prueba o durante ella.
Se han producido problemas esporádicos con la programación de la cadena. Detén e inicia la VM de origen o de destino, tal como se describe en Detener e iniciar una instancia, y vuelve a ejecutar la prueba.
El resultado del análisis de configuración es Packet could be delivered, pero el análisis del plano de datos en tiempo real indica una pérdida parcial de paquetes
Esta aparente incongruencia puede deberse a varios motivos. Estas son algunas de las posibles causas y soluciones:
Se está limitando la velocidad de la VM de origen o de destino porque se ha superado el ancho de banda de salida o de entrada permitido. Analiza el volumen de tráfico de la VM. Para ello, ve a la página Detalles de la instancia de VM y consulta los detalles de la pestaña Monitorización. Consulta la métrica Bytes de red y compárala con los límites de ancho de banda que se describen para el tipo de máquina en Ancho de banda de red.
Un problema generalizado está afectando al plano de datos de la red. Consulta el Panel de rendimiento de tu proyecto y presta especial atención al par de zonas pertinente. Además, consulta el Google Cloud panel de estado.
El resultado del análisis de configuración es Packet could be delivered y el análisis del plano de datos activo muestra una entrega completa, pero mi aplicación experimenta pérdidas
Esta aparente incongruencia puede deberse a varios motivos. Estas son algunas de las posibles causas y soluciones:
- El sistema operativo invitado puede bloquear el tráfico (por ejemplo, mediante reglas de cortafuegos internas). Verifica que el tráfico no esté bloqueado y vuelve a hacer la prueba.
- Los paquetes de datos de la aplicación pueden recorrer una ruta de red diferente a la de las sondas de análisis del plano de datos activos. Prueba a restablecer la conexión de red. Por ejemplo, prueba a usar otro puerto de origen.
- El análisis del plano de datos activo detecta la pérdida de paquetes unidireccional. En tu caso, puede que se produzca una pérdida de paquetes en la ruta de retorno. Prueba a hacer una prueba en la dirección contraria.
Los resultados de la prueba no incluyen un resultado del análisis del plano de datos activo
No todas las configuraciones admitidas por las pruebas de conectividad se pueden verificar con el análisis del plano de datos en tiempo real. Asegúrate de que la prueba cumpla las condiciones necesarias para el análisis del plano de datos activos, tal como se especifica en la descripción general.
La API Network Management ha devuelto un INTERNAL_ERROR
Este evento no debería producirse normalmente. Si es así, informa del problema al equipo de Asistencia y describe cómo reproducirlo.
Google Cloud problemas con la consola
La Google Cloud consola de pruebas de conectividad ha fallado
La consola Google Cloud no debería fallar normalmente. Si es así, informa del problema al equipo de Asistencia y describe cómo reproducirlo.
Siguientes pasos
- Identificar y solucionar problemas de ICMP (tutorial)