Las pruebas de conectividad son una herramienta de diagnóstico que te permite verificar la conectividad entre los extremos de red. Analizan tu parámetro de configuración y, en algunos casos, realizan un análisis del plano de datos en vivo entre los extremos. Un extremo es una fuente o un destino del tráfico de red, como una VM, un clúster de Google Kubernetes Engine (GKE), una regla de reenvío del balanceador de cargas o una dirección IP en Internet.
Para analizar los parámetros de configuración de red, las pruebas de conectividad simulan la ruta de reenvío prevista de un paquete a través de tu red de nube privada virtual (VPC), túneles de Cloud VPN o adjuntos de VLAN. Las pruebas de conectividad también pueden simular la ruta de reenvío entrante esperada a los recursos en tu red de VPC.
Para algunas situaciones de conectividad, las pruebas de conectividad también realizan análisis del plano de datos en vivo. Esta característica envía paquetes a través del plano de datos para validar la conectividad y proporciona un diagnóstico de referencia de la latencia y la pérdida de paquetes. Si la ruta es compatible con la característica, cada prueba que ejecutes incluye un resultado del análisis del plano de datos en vivo.
Para obtener información sobre cómo crear y ejecutar pruebas en diversas situaciones, consulta Crea y ejecuta pruebas de conectividad.
La API para las pruebas de conectividad es la API de administración de redes. Para obtener más información, consulta la documentación de la API.
¿Por qué usar las pruebas de conectividad?
Las pruebas de conectividad pueden ayudarte a solucionar los siguientes problemas de conectividad de red:
- Opciones de configuración incoherentes no deseadas
- Opciones de configuración obsoletas debido a cambios en la configuración de la red o migraciones
- Errores de configuración para una variedad de servicios y funciones de red
Cuando pruebes servicios administrados por Google, las pruebas de conectividad también pueden ayudarte a determinar si hay algún problema en tu red de VPC o en la red de VPC que es propiedad de Google y que se usa para los recursos del servicio.
Cómo las pruebas de conectividad analizan los parámetros de configuración
Cuando se analizan los parámetros de configuración de red, las pruebas de conectividad usan una máquina de estado abstracto para modelar la forma en que una red de VPC debe procesar los paquetes. Google Cloud procesa un paquete en varios pasos lógicos.
El análisis puede tomar muchas rutas posibles
Debido a la variedad de servicios de red de VPC y funciones que el análisis de configuración admite, un paquete de prueba que atraviesa una configuración de red de VPC puede tomar muchas rutas posibles.
En el siguiente diagrama, se muestra un modelo de cómo el análisis de configuración simula el tráfico de seguimiento entre dos instancias de Compute Engine: una a la izquierda y otra a la derecha.
El análisis depende de tu infraestructura de red
Según la configuración de la red y los recursos de Google Cloud , este tráfico puede pasar a través de un túnel de Cloud VPN, una red de VPC, un balanceador de cargas de Google Cloud o una red de VPC similar antes de llegar a la instancia de Compute Engine de destino.
El análisis sigue uno de los numerosos estados finitos
La cantidad limitada de pasos entre estados discretos hasta que un paquete se entregó o descartó se modela como una máquina de estado finito. Esta máquina de estado finito puede estar en exactamente uno de los numerosos estados finitos a la vez y podría tener varios estados de éxito.
Por ejemplo, cuando las pruebas de conectividad coinciden con varias rutas según la precedencia de ruta, Google Cloud puede elegir una ruta entre varias según una función hash no especificada en el plano de datos. Si se configura una ruta basada en políticas, la prueba de conectividad enruta el paquete al próximo salto, que es un balanceador de cargas interno.
En el caso anterior, el seguimiento de pruebas de conectividad devuelve todas las rutas posibles, pero no puede determinar el método que Google Cloud usó para devolver las rutas. Esto se debe a que ese método es interno de Google Cloudy está sujeto a cambios.
Servicios administrados por Google
Los servicios administrados por Google, como Cloud SQL y Google Kubernetes Engine (GKE), asignan recursos para los clientes en proyectos y redes de VPC que Google posee y administra. Los clientes no tienen permiso para acceder a estos recursos.
Los análisis de configuración de pruebas de conectividad aún pueden ejecutar una prueba y proporcionar un resultado de accesibilidad general para los servicios administrados por Google, pero no proporcionan detalles con respecto a los recursos probados en el proyecto que es propiedad de Google.
En el siguiente diagrama, se muestra un modelo de cómo el análisis de configuración simula el tráfico de seguimiento desde una instancia de Compute Engine en una red de VPC de un cliente a una instancia de Cloud SQL en la red de VPC de Google. En este ejemplo, las redes se conectan través del intercambio de tráfico entre redes de VPC.
Al igual que en una prueba estándar entre dos instancias de Compute Engine, entre los pasos lógicos, se incluye verificar las reglas de firewall de salida pertinentes y hacer coincidir la ruta. Cuando ejecutas una prueba, el análisis de configuración de las pruebas de conectividad proporciona detalles sobre estos pasos. Sin embargo, en el último paso lógico de analizar la configuración en la red de VPC de Google, el análisis proporciona solo un resultado de accesibilidad general. Las pruebas de conectividad no proporcionan detalles de los recursos en el proyecto de Google porque no tienes permiso para verlos.
Para obtener más información, consulta los ejemplos de prueba en Prueba la conectividad desde y hacia los servicios administrados por Google.
Parámetros de configuración admitidos
El análisis de la configuración de las pruebas de conectividad admite la prueba de los parámetros de configuración de red que se describen en las siguientes secciones.
Extremos de origen
El análisis de la configuración de las pruebas de conectividad admite los siguientes extremos de origen:
- Instancia de Compute Engine
- Revisión de Cloud Run
- Cloud Run Functions (1ª gen.)
- Entorno estándar de App Engine
- Instancia de Cloud SQL
- Plano de control de GKE
- Dirección IP de Internet
- Dirección IP de una red local
- Dirección IP de una instancia de Compute Engine
- Dirección IP de una instancia de Cloud SQL
- Dirección IP de un plano de control de GKE
- Dirección IP sin asignar en una red de nube privada virtual
Extremos de destino
El análisis de configuración de las pruebas de conectividad admite los siguientes extremos de destino:
- Instancia de Compute Engine
- Instancia de Cloud SQL
- Plano de control de GKE
- Balanceador de cargas de aplicaciones externo y también interno
- Balanceador de cargas de red de proxy externo y también interno
- Balanceador de cargas de red de transferencia externo y también interno
- Extremo de Private Service Connect
- Memorystore for Redis Cluster
- Instancia de Memorystore for Redis
- Dirección IP de Internet
- Dirección IP de una red local
- Dirección IP de una regla de reenvío
- Dirección IP de una instancia de Compute Engine
- Dirección IP de una instancia de Cloud SQL
- Dirección IP de un plano de control de GKE
- Dirección IP de Memorystore for Redis Cluster
- Dirección IP de una instancia de Memorystore for Redis
Herramientas de las redes deGoogle Cloud
Puedes probar la conectividad entre los recursos que usan las siguientes funciones (se admiten IPv4 y también IPv6 cuando corresponda):
- Redes de VPC
- Intercambio de tráfico entre redes de VPC
- VPC compartida
- Acceso privado a Google
- Cloud Load Balancing
- Rangos de IP de alias
- Direcciones IPv4 públicas usadas de forma privada
- Instancias de Compute Engine con varias interfaces de red
- Enrutamiento de VPC
- Reglas de firewall de VPC
- Políticas de firewall de redes regionales
- Políticas de firewall jerárquicas y políticas de firewall de red globales
- Etiquetas de Resource Manager para firewalls, incluidas las que se conectan a instancias de Compute Engine con varias interfaces de red
- Rutas basadas en políticas
- Private Service Connect
- Instancias con direcciones IPv6, incluidas las instancias con varias interfaces de red
- Radios de VPC y radios híbridos para Network Connectivity Center
- NAT pública y NAT privada
- Cloud VPN
- Cloud Interconnect
- Cloud Router, incluidas las rutas dinámicas que usan BGP y rutas estáticas
Consideraciones para Cloud Load Balancing
En el caso de Cloud Load Balancing, el análisis de configuración de las pruebas de conectividad admite las siguientes funciones:
- Prueba la conectividad con las direcciones IP del balanceador de cargas.
- Verifica la conectividad de las verificaciones de estado de Cloud Load Balancing con los backends.
- Los balanceadores de cargas de TCP/UDP internos se pueden usar como próximos saltos.
Para las funciones de Cloud Load Balancing que no son compatibles, consulta la secciónParámetros de configuración no compatibles.
Para obtener información sobre cómo las pruebas de conectividad analizan los backends de un balanceador de cargas, consulta Cantidad de seguimientos en una prueba de balanceador de cargas.
Consideraciones para Google Kubernetes Engine
En el caso de GKE, el análisis de configuración de las pruebas de conectividad admite las siguientes funciones:
- Conectividad entre los nodos de GKE y el plano de control de GKE
- Conectividad al servicio de GKE a través de Cloud Load Balancing
Se admite la conectividad a un Pod de GKE en un clúster nativo de la VPC. Sin embargo, algunas funciones de redes de GKE, como las políticas de red de GKE, no son compatibles.
Para las funciones de GKE que no son compatibles, consulta la sección Opciones de configuración no compatibles.
Consideraciones sobre los extremos sin servidores
Las direcciones IP de origen de los extremos sin servidores suelen ser no determinísticas. En cada ejecución de prueba, las pruebas de conectividad seleccionan una dirección IP aleatoria del grupo de direcciones que están disponibles para el extremo sin servidores. Para obtener información general sobre cómo se asignan las direcciones IP a los extremos sin servidores, consulta lo siguiente:
- Para la conectividad externa, consulta Direcciones IP.
- Para obtener información sobre la conectividad a través de un conector de Acceso a VPC sin servidores, consulta Envía tráfico sin servidores a una red de nube privada virtual.
- Para la conectividad a través de la salida de VPC directa, consulta Asignación de direcciones IP. Este tipo de conectividad solo está disponible para Cloud Run.
En algunos casos, los conectores de salida de VPC directa y de Acceso a VPC sin servidores se configuran para enrutar el tráfico desde los extremos sin servidores a través de la conectividad externa en lugar de la red de nube privada virtual, según la configuración de salida.
Para las funciones sin servidores que no son compatibles, consulta la sección Opciones de configuración no compatibles.
Opciones de configuración no compatibles
El análisis de configuración de las pruebas de conectividad no admite las pruebas de los siguientes parámetros de configuración de red:
- No se admiten las reglas de políticas de firewall con objetos de ubicación geográfica, datos de inteligencia contra amenazas ni objetos FQDN. Si estos firewalls pueden afectar un flujo de tráfico específico, las pruebas de conectividad devuelven una advertencia correspondiente.
- No se admiten los backends de NEG de Internet que segmentan FQDN. Sin embargo, se admiten los backends de NEG de Internet que segmentan direcciones IP.
- No se admiten los balanceadores de cargas de Cloud Service Mesh
con las reglas de reenvío
INTERNAL_SELF_MANAGED. - Las políticas de Google Cloud Armor no se consideran ni se utilizan cuando se rastrea la conectividad a una dirección IP del balanceador de cargas de aplicaciones externo.
- No se admiten las puertas de enlace de VPN con alta disponibilidad conectadas a instancias de Compute Engine.
- Las políticas de red de GKE y los parámetros de configuración de enmascaramiento de IP no se consideran ni se usan cuando se rastrea la conectividad a direcciones IP dentro de los clústeres y nodos de GKE.
- No se admiten las réplicas de servidores externos de Cloud SQL definidas por nombres de DNS. Sin embargo, sí se admiten las réplicas de servidores externos definidas por direcciones IP.
- No se admite Cloud Run Functions (2ª gen.). Sin embargo, puedes testear la conectividad desde una función de Cloud Run (2ª gen.) creando una prueba de conectividad para la revisión subyacente de Cloud Run. Cada vez que se implementa una función de Cloud Run, se crea una revisión de Cloud Run.
- No se admite el entorno flexible de App Engine.
- No se admiten los trabajos de Cloud Run. Para obtener más información, consulta Servicios, trabajos y grupos de trabajadores: tres formas de ejecutar tu código.
Cómo las pruebas de conectividad analizan el plano de datos en vivo
La función de análisis del plano de datos en vivo prueba la conectividad enviando varios paquetes de sondeo desde el extremo de origen al de destino. Si el destino no es un recurso de Google Cloud , se prueba la conectividad entre el extremo de origen y la ubicación perimetral de la red.
Los resultados del análisis del plano de datos en vivo te muestran la cantidad de sondeos enviados, la cantidad de sondeos que llegaron con éxito al destino y un estado de accesibilidad. Este estado se determina en función de la cantidad de sondeos que se entregaron correctamente, como se describe en la siguiente tabla.
| Estado | Cantidad de sondeos que llegaron a su destino |
|---|---|
| Accesible | Al menos un 95% |
| Inaccesible | Ninguno |
| Parcialmente accesible | Más de 0 y menos de un 95% |
Además de mostrar cuántos paquetes se enviaron correctamente, el análisis del plano de datos en vivo también muestra información sobre la latencia de ida de un 95% y la mediana. Cuando el destino es una dirección IP de Internet, el análisis del plano de datos en vivo envía sondeos y muestra los resultados de cada router perimetral de la Red de Google por el que se podría enrutar el tráfico.
Limitaciones
Es posible que el análisis del plano de datos en vivo no abarque todas las rutas de redes posibles:
- Si el extremo de destino es un balanceador de cargas de Google Cloud con varios backends, cada sondeo de análisis del plano de datos en vivo se envía a un backend aleatorio. Algunos backends se pueden probar con muchos sondeos, mientras que otros no se pueden probar en absoluto.
- En el caso del enrutamiento de la ruta múltiple de igual costo (ECMP), cada sondeo de análisis del plano de datos en vivo se reenvía a través de una ruta aleatoria. Algunas rutas de acceso se pueden probar con muchos sondeos, mientras que otras no se prueban en absoluto.
- La cantidad de sondeos de análisis del plano de datos en vivo no depende de la cantidad de rutas de redes existentes, y es posible que no haya una cantidad suficiente de sondeos de análisis del plano de datos en vivo para probar cada ruta posible.
Si ves discrepancias evidentes entre el análisis de configuración y los resultados del análisis del plano de datos en vivo, consulta Soluciona problemas de pruebas de conectividad.
Parámetros de configuración admitidos
El análisis del plano de datos en vivo admite un subconjunto de parámetros de configuración que se testean con el análisis de configuración de las pruebas de conectividad.
Extremos de origen
El análisis del plano de datos en vivo admite los siguientes extremos de origen:
- Instancia de Compute Engine
- El extremo sin servidores configurado con un conector de Acceso a VPC sin servidores y asociado a uno de los siguientes recursos:
- Instancia de Cloud SQL
- Plano de control de GKE
Extremos de destino
El análisis del plano de datos en vivo admite los siguientes extremos de destino:
- Instancia de Compute Engine
- Balanceador de cargas de red de transferencia interno
- Private Service Connect con un balanceador de cargas de red de transferencia interno del productor
- Dirección IP de Internet, probada en la ubicación perimetral de la red
- Adjunto de VLAN para Cloud Interconnect
- El extremo privado asociado a uno de los siguientes recursos:
- Instancia de Cloud SQL
- Memorystore for Redis Cluster
- Instancia de Memorystore for Redis
- Plano de control de GKE
Protocolos
El análisis del plano de datos en vivo admite los protocolos TCP y UDP.
Herramientas de las redes deGoogle Cloud
El análisis del plano de datos en vivo admite las siguientes funciones:
- Redes de VPC
- Intercambio de tráfico entre redes de VPC
- VPC compartida
- Radios de VPC y radios híbridos en Network Connectivity Center
- Rangos de IP de alias
- Direcciones IP externas
- Direcciones IP internas, incluidas las direcciones IPv4 públicas usadas de forma privada
- Instancias de Compute Engine con varias interfaces de red
- Enrutamiento de VPC
- NAT pública y NAT privada, excepto NAT64
- Reglas de firewall de VPC
- Políticas de firewall jerárquicas, políticas de firewall de red globales y políticas de firewall de red regionales
- Etiquetas seguras para firewalls, incluso cuando se adjuntan a instancias de Compute Engine con varias interfaces de red
- Rutas basadas en políticas
- Instancias con direcciones IPv6, incluidas las instancias con varias interfaces de red
Opciones de configuración no compatibles
El análisis del plano de datos en vivo no admite los siguientes parámetros de configuración de red y no se ejecuta para ellos:
- Recursos que no son deGoogle Cloud como extremos de origen:
- Direcciones IP de Internet
- Tráfico entrante a Google Cloud a través de Cloud Interconnect, Cloud VPN y radios híbridos de Network Connectivity Center
- Direcciones IP sin asignar en una red de VPC como extremos de origen
- Los extremos de origen y destino son la misma instancia de Compute Engine
- Instancias de Compute Engine que no se ejecutan
- API y servicios de Google
- Balanceador de cargas de aplicaciones externo y también interno
- Balanceador de cargas de red de proxy externo y también interno
- Balanceador de cargas de red de transferencia externo
- Cloud VPN
- NAT64
Consideraciones y restricciones
Evalúa las siguientes consideraciones tras decidir si usar las pruebas de conectividad.
- El análisis de configuración que realizan las pruebas de conectividad se basa completamente en la información de configuración de los recursos de Google Cloud y puede no representar la condición o el estado real del plano de datos de una red de VPC.
- Si bien las pruebas de conectividad adquieren información de configuración dinámica, como el estado del túnel de Cloud VPN y las rutas dinámicas en Cloud Router, no accede ni mantiene el estado de la infraestructura de producción interna de Google y los componentes del plano de datos.
- Un estado de
Packet could be deliveredpara una prueba de conectividad no garantiza que el tráfico pueda atravesar el plano de datos. El propósito de la prueba es validar los problemas de configuración que pueden causar una disminución del tráfico.
En el caso de las rutas admitidas, los resultados del análisis del plano de datos activo complementan los resultados del análisis de configuración probando si los paquetes transmitidos llegan al destino.
Las pruebas de conectividad no tienen conocimiento de redes fuera de Google Cloud
Las redes externas se definen de la siguiente manera:
- Redes locales que residen en tu centro de datos o en otra instalación donde operas tus dispositivos de hardware y aplicaciones de software
- Otros proveedores de servicios en la nube en los que ejecutas recursos
- Un host en Internet que envía tráfico a tu red de VPC
Las pruebas de conectividad no realizan el seguimiento de la conexión de firewall
El seguimiento de conexión para los firewalls de VPC almacena información sobre conexiones nuevas y establecidas y nos deja permitir o restringir el tráfico posterior en función de esa información.
El análisis de configuración de pruebas de conectividad no admite el seguimiento de la conexión de firewall porque la tabla de conexión de firewall se encuentra en el plano de datos para una instancia de Compute Engine y no se puede acceder a ella. Sin embargo, el análisis de configuración puede simular el seguimiento de la conexión, ya que permite una conexión de retorno que una regla de firewall de entrada normalmente negaría, siempre que las pruebas de conectividad inicien la conexión saliente.
El análisis del plano de datos en vivo no admite la prueba del seguimiento de conexión de firewall.
Las pruebas de conectividad no pueden testear las instancias de Compute Engine configuradas para modificar el comportamiento de reenvío
Las pruebas de conectividad no pueden testear las instancias de Compute Engine que se configuraron para actuar en el plano de datos como routers, firewalls, puertas de enlace NAT o VPNs. Este tipo de configuración dificulta la evaluación del entorno que se ejecuta en la instancia de Compute Engine. Además, el análisis del plano de datos en vivo no admite este tipo de situación de prueba.
Los tiempos de resultados de las pruebas de conectividad pueden variar
Obtener los resultados de las pruebas de conectividad puede llevar desde 30 segundos hasta 10 minutos. El tiempo que toma realizar una prueba se basa en el tamaño de la configuración de tu red de VPC y la cantidad de recursos de Google Cloud que usas.
En la siguiente tabla, se muestran los tiempos de respuesta que puede esperar para todos los usuarios que ejecutan una prueba en una configuración de muestra en una consulta. Esta configuración contiene instancias de Compute Engine, un túnel de Cloud VPN y balanceadores de cargas de Google Cloud.
| Tamaño del proyecto | Cantidad de recursos de Google Cloud | Latencia de respuesta |
|---|---|---|
| Proyecto pequeño | Menos de 50 | 60 segundos para el 95% de las consultas de todos los usuarios |
| Proyecto medio | Más de 50, pero menos de 5,000 | 120 segundos para el 95% de las consultas de todos los usuarios |
| Proyecto grande | Más de 5,000 | 600 segundos para el 95% de las consultas de todos los usuarios |
El análisis del plano de datos en vivo no está diseñado para la supervisión continua
El análisis del plano de datos en vivo realiza una verificación única de la conectividad de red con fines de diagnóstico. Para supervisar continuamente la conectividad y la pérdida de paquetes, usa el Panel de rendimiento.
Compatibilidad con los Controles del servicio de VPC
Los Controles del servicio de VPC pueden proporcionar seguridad adicional para las pruebas de conectividad a fin de mitigar el riesgo de robo de datos. Con los Controles del servicio de VPC, puedes agregar proyectos a perímetros de servicio que protejan los recursos y servicios de las solicitudes que se originan fuera del perímetro.
Para obtener más información sobre los perímetros de servicio, consulta la página Configuración y detalles del perímetro de servicio de la documentación de Controles del servicio de VPC.
¿Qué sigue?
Detecta parámetros de configuración no válidos o incoherentes
Identifica y soluciona problemas de ICMP (instructivo)