Las pruebas de conectividad son una herramienta de diagnóstico que te permite verificar la conectividad entre los extremos de red. Analizan tu 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 las configuraciones de red, las pruebas de conectividad simulan la ruta de reenvío prevista para 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 el 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 una ruta es compatible con la función, cada prueba que ejecutes incluye un resultado de análisis del plano de datos en vivo.
Para obtener información sobre cómo crear y ejecutar pruebas para varias 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 los servicios administrados por Google, las pruebas de conectividad también pueden ayudarte a determinar si hay un problema en tu red de VPC o en la red de VPC de Google que se usa para los recursos de servicio.
Cómo las pruebas de conectividad analizan los parámetros de configuración
Cuando se analizan las configuraciones 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 admite el análisis de configuración, 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 máquina virtual (VM) de Compute Engine: una a la izquierda y otra a la derecha.
El análisis depende de la infraestructura de red
Según la red de Google Cloud y las configuraciones de recursos, 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 VM de destino.
El análisis sigue uno de los muchos 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 de 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 siguiente salto, que es un balanceador de cargas interno.
En el caso anterior, el seguimiento de pruebas de conectividad muestra todas las rutas posibles, pero no puede determinar el método que Google Cloud utilizó para mostrar las rutas. Esto se debe a que ese método es interno de Google Cloud y 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 para 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 VM 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 a través del intercambio de tráfico entre redes de VPC.
Al igual que en una prueba estándar entre dos VM, los pasos lógicos incluyen verificar las reglas de firewall de salida relevantes y hacer coincidir la ruta. Cuando ejecutas una prueba, el análisis de configuración de 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 general de accesibilidad. 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 la sección Prueba la conectividad desde y hacia los servicios administrados por Google.
Configuraciones admitidas
El análisis de configuración de las pruebas de conectividad admite la prueba de las configuraciones de red descritas en las siguientes secciones.
Flujos de tráfico
- Instancias de VM hacia y desde Internet
- Instancia de VM a instancia de VM
- Desde Google Cloud hacia y desde redes locales
- Entre dos redes locales que están conectadas a través de Network Connectivity Center
- Entre dos radios de VPC de Network Connectivity Center
Funciones de la red de VPC
Puedes probar la conectividad entre los recursos que usan las siguientes funciones (se admiten IPv4 e IPv6 siempre que corresponda):
- Redes de VPC
- Intercambio de tráfico entre redes de VPC
- VPC compartida
- Acceso privado a Google
- Rangos de alias de IP
- Direcciones IP privadas fuera del rango de direcciones RFC 1918
- Una instancia deVM de Compute Engine con múltiples interfaces de red
- Rutas personalizadas importadas de redes de VPC de intercambio de tráfico
- Enrutamiento transitivo de VPC
- Reglas de firewall de VPC
- Políticas de firewall de red regionales
- Políticas de firewall jerárquicas y políticas de firewall de red globales
- Etiquetas de Resource Manager para firewalls si se adjuntan a la instancia de Compute Engine con una sola interfaz de red
- Rutas basadas en políticas
- Private Service Connect
- Instancias con direcciones IPv6, incluidas las instancias con varias interfaces de red
Soluciones de redes híbridas de Google Cloud
Las siguientes soluciones de redes híbridas son compatibles con IPv4 e IPv6:
- Cloud VPN
- Cloud Interconnect
- Cloud Router, incluidas las rutas dinámicas que usan BGP y rutas estáticas
Network Connectivity Center
Se admiten radios de VPC y radios híbridos para Network Connectivity Center.
Cloud NAT
Se admiten NAT pública y NAT privada.
Cloud Load Balancing
- Se admiten los siguientes tipos de balanceador de cargas de Google Cloud: balanceadores de cargas de aplicaciones externos, balanceadores de cargas de red de transferencia externos, balanceadores de cargas de red de proxy externos, balanceadores de cargas de aplicaciones internos, balanceadores de cargas de red de transferencia internos y balanceadores de cargas de red de proxy internos.
- Se admite la prueba de conectividad a las direcciones IP del balanceador de cargas.
- Se admite la verificación de la conectividad de las verificaciones de estado de Cloud Load Balancing con los backends.
- Los balanceadores de cargas TCP/UDP internos se pueden usar como próximos saltos.
Para las funciones de Cloud Load Balancing que no son compatibles, consulte la sección Configuraciones no compatibles.
Google Kubernetes Engine (GKE)
- Se admite la conectividad entre los nodos de GKE y el plano de control de GKE.
- Se admite la 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 NetworkPolicies de GKE, no son compatibles.
Para las funciones de GKE que no son compatibles, consulte la sección Opciones de configuración no compatibles.
Otros productos y servicios de Google Cloud
Se admiten los siguientes productos o servicios adicionales de Google Cloud:
- Se admiten instancias de Cloud SQL, incluidas la conexión de Private Service Connect, la conexión de intercambio de tráfico de red de VPC y las réplicas externas.
- Se admiten instancias de Memorystore para Redis.
- Se admiten Memorystore for Redis Clusters.
- Se admiten las funciones de Cloud Run (1ª gen.).
- Se admiten las revisiones de Cloud Run.
- Es compatible con el entorno estándar de App Engine.
Opciones de configuración no compatibles
El análisis de configuración de pruebas de conectividad no admite las pruebas de las siguientes configuraciones 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 esos firewalls pueden afectar un flujo de tráfico específico, las pruebas de conectividad muestran una advertencia correspondiente.
- Las etiquetas de Resource Manager para firewalls no son compatibles si se adjuntan a instancias de Compute Engine con varias interfaces de red.
- No se admiten los backends de NEG de Internet segmentados para FQDN. Sin embargo, se admiten backends de NEG de Internet que se orientan a direcciones IP.
- No se admiten los balanceadores de cargas de Cloud Service Mesh (con las reglas de reenvío de
INTERNAL_SELF_MANAGED). - Las políticas de Google Cloud Armor no se consideran ni se utilizan al rastrear la conectividad a una dirección IP del balanceador de cargas de aplicaciones externo.
- No se admite la asignación de puertos de Private Service Connect.
- No se admiten las puertas de enlace de VPN con alta disponibilidad conectadas a VMs de Compute Engine.
- Las configuraciones de NetworkPolicies de GKE y de enmascaramiento de IP no se consideran ni se utilizan cuando se realiza un seguimiento de la conectividad a direcciones IP dentro de los clústeres y nodos de GKE.
- No se admiten réplicas de servidores externos de Cloud SQL definidas por nombres de DNS. Sin embargo, se admiten réplicas de servidores externos definidas por direcciones IP.
- No se admiten las funciones de Cloud Run (2ª gen.). Sin embargo, puedes probar la conectividad desde una función de Cloud Run (2ª gen.) si creas una prueba de conectividad para la revisión subyacente de Cloud Run. Se crea una revisión de Cloud Run cada vez que se implementa una función de Cloud Run.
- No se admite el entorno flexible de App Engine.
- No se admiten trabajos de Cloud Run. Para obtener más información, consulta Servicios y trabajos: dos formas de ejecutar tu código.
- No se admite la salida de VPC directa de Cloud Run.
De qué forma 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 mediante el envío de varios paquetes de seguimiento desde el extremo de origen al de destino. 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 alcanzaron su destino |
|---|---|
| Accesible | Por lo menos 95% |
| No se puede acceder | Ninguna |
| Parcialmente accesible | Más de 0 y menos de 95% |
Además de mostrar cuántos paquetes se enviaron correctamente, la verificación dinámica también muestra información sobre la latencia unidireccional de 95% y la mediana.
El análisis del plano de datos en vivo no depende del análisis de configuración. En su lugar, proporciona una evaluación independiente del estado de conectividad.
Si ves discrepancias aparentes 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.
Configuraciones admitidas
El análisis del plano de datos en vivo admite las siguientes configuraciones de red.
Flujos de tráfico
- Entre dos instancias de VM
- Entre una instancia de VM y una instancia de Cloud SQL
- Entre una instancia de VM y un extremo del plano de control de GKE
- Entre una instancia de VM y una ubicación perimetral de la red de Google
- Protocolos IP: TCP, UDP
Funciones de la red de VPC
Puedes verificar la conectividad de forma dinámica entre los recursos que usan las siguientes funciones:
- Intercambio de tráfico entre redes de VPC
- VPC compartida
- Rangos de alias de IP
- Direcciones IP externas
- Direcciones IP internas, direcciones IP privadas fuera del rango de direcciones RFC 1918
- Rutas personalizadas
- Balanceadores de cargas como destino Los backends admitidos de los balanceadores de cargas son grupos de instancias, grupos de extremos de red (NEG) zonales y backends de Private Service Connect.
- Reglas de firewall de entrada, incluidas las reglas de políticas jerárquicas de firewall de entrada y las reglas de firewall de VPC de entrada
- Instancias con direcciones IPv6, incluidas las instancias con varias interfaces de red
- Extremos de Private Service Connect para servicios publicados y APIs de Google
Opciones de configuración no compatibles
Toda configuración que no se mencione de forma explícita como compatible no se admite. Además, no se admiten las configuraciones en las que la conectividad está bloqueada por reglas de firewall de salida.
Para cualquier prueba, si no se ejecuta la función de análisis del plano de datos en vivo, aparecerá un valor N/A o - en el campo Resultado de la última transmisión de paquetes.
Consideraciones y limitaciones
Evalúe las siguientes consideraciones al decidir si usar pruebas de conectividad.
- El análisis de configuración que realizan las pruebas de conectividad se basa completamente en 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 acceden ni mantienen 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 pasar a través del 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 en vivo complementan los resultados del análisis de configuración mediante la prueba 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 su centro de datos o en otra instalación donde opera sus dispositivos de hardware y aplicaciones de software.
- Otros proveedores de servicios en la nube en los que ejecuta recursos.
- Un host en Internet que envía tráfico a su 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 permite 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 VM 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 probar las instancias de VM configuradas para modificar el comportamiento de reenvío
Las pruebas de conectividad no pueden probar las instancias de VM que se configuraron para actuar en el plano de datos como routers, firewalls, puertas de enlace NAT, VPN, etcétera. Este tipo de configuración dificulta la evaluación del entorno que se ejecuta en la instancia de VM. Además, el análisis del plano de datos en vivo no admite esta 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 se realiza 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 VM, 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 | Superior a 50, pero menos de 5,000 | 120 segundos para el 95% de las consultas de todos los usuarios |
| Proyecto grande | Mayor que 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 conectividad de red con fines de diagnóstico. Para supervisar continuamente la conectividad y la pérdida de paquetes, usa el Panel de rendimiento.
El análisis del plano de datos en vivo no prueba varios seguimientos
El análisis del plano de datos en vivo no se admite en los casos en que la ruta no es determinista.
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.