Pruebas de conectividad es una herramienta de diagnóstico que te permite comprobar la conectividad entre los endpoints de las redes. Analiza tu configuración y, en algunos casos, realiza un análisis del plano de datos en directo entre los endpoints. Un endpoint es un origen o un destino del tráfico de red, como una máquina virtual, un clúster de Google Kubernetes Engine (GKE), una regla de reenvío del balanceador de carga o una dirección IP en Internet.
Para analizar las configuraciones de red, Pruebas de conectividad simula la ruta de reenvío esperada de un paquete a través de tu red de nube privada virtual (VPC), túneles de Cloud VPN o vinculaciones de VLAN. Las pruebas de conectividad también pueden simular la ruta de reenvío entrante esperada a los recursos de tu red de VPC.
En algunos casos de conectividad, las pruebas de conectividad también realizan análisis del plano de datos en tiempo real. Esta función envía paquetes a través del plano de datos para validar la conectividad y proporciona diagnósticos básicos de latencia y pérdida de paquetes. Si la ruta es compatible con la función, cada prueba que realices incluirá un resultado de análisis del plano de datos en tiempo real.
Para saber cómo crear y ejecutar pruebas en diferentes situaciones, consulta el artículo Crear y ejecutar pruebas de conectividad.
La API de las pruebas de conectividad es la API Network Management. 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:
- Configuraciones incoherentes no deseadas
- Configuraciones obsoletas causadas por cambios o migraciones en la configuración de la red
- Errores de configuración de varios servicios y funciones de red
Cuando pruebes servicios gestionados por Google, las pruebas de conectividad también pueden ayudarte a determinar si hay algún problema en tu red VPC o en la red VPC propiedad de Google que se usa para los recursos del servicio.
Cómo analiza las configuraciones la herramienta Pruebas de conectividad
Al analizar las configuraciones de red, Pruebas de conectividad usa una máquina de estados abstracta para modelar cómo debe procesar los paquetes una red de VPC.Google Cloud procesa un paquete en varios pasos lógicos.
El análisis puede seguir muchos caminos posibles
Debido a la variedad de servicios y funciones de la red VPC que admite el análisis de configuración, un paquete de prueba que atraviesa una configuración de red 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 de Compute Engine: una a la izquierda y otra a la derecha.
El análisis depende de tu infraestructura de red
En función de las configuraciones de tu red Google Cloud y de tus recursos, este tráfico puede pasar por un túnel de Cloud VPN, una red de VPC, un balanceador de carga Google Cloud o una red de VPC emparejada antes de llegar a la instancia de VM de destino.
El análisis sigue uno de los muchos estados finitos
El número limitado de pasos entre estados discretos hasta que se ha entregado o descartado un paquete se modela como una máquina de estados finita. Esta máquina de estados finitos puede estar en exactamente uno de los muchos estados finitos en cualquier momento y puede tener varios estados sucesores.
Por ejemplo, cuando las pruebas de conectividad coinciden con varias rutas según la precedencia de las rutas, Google Cloud pueden elegir una ruta entre varias rutas en función de una función de hash no especificada en el plano de datos. Si se configura una ruta basada en políticas, Prueba de conectividad dirige el paquete al siguiente salto, que es un balanceador de carga interno.
En el caso anterior, el rastreo de las pruebas de conectividad devuelve todas las rutas posibles, pero no puede determinar el método Google Cloud utilizado para devolver las rutas. Esto se debe a que ese método es interno a Google Cloud y está sujeto a cambios.
Servicios gestionados por Google
Los servicios gestionados por Google, como Cloud SQL y Google Kubernetes Engine (GKE), asignan recursos a los clientes en proyectos y redes VPC que Google posee y gestiona. Los clientes no tienen permiso para acceder a estos recursos.
El análisis de la configuración de las pruebas de conectividad puede seguir ejecutando una prueba y proporcionando un resultado general de accesibilidad para los servicios gestionados por Google, pero no proporciona detalles sobre los recursos probados en el proyecto 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 de una instancia de VM en una red de VPC de un cliente a una instancia de Cloud SQL en la red de VPC propiedad de Google. En este ejemplo, las redes están conectadas mediante el emparejamiento entre redes de VPC.
Al igual que en una prueba estándar entre dos máquinas virtuales, los pasos lógicos incluyen comprobar las reglas de cortafuegos de salida pertinentes y buscar la ruta correspondiente. Cuando ejecutas una prueba, el análisis de configuración de pruebas de conectividad proporciona detalles sobre estos pasos. Sin embargo, en el paso lógico final de análisis de la configuración de la red VPC propiedad de Google, el análisis solo proporciona un resultado general de la accesibilidad. Pruebas de conectividad no proporciona detalles sobre los recursos del proyecto propiedad de Google porque no tienes permiso para verlos.
Para obtener más información, consulta los ejemplos de pruebas en Probar la conectividad con y desde servicios gestionados por Google.
Configuraciones admitidas
El análisis de la configuración de pruebas de conectividad permite probar las configuraciones de red que se describen en las siguientes secciones.
Flujos de tráfico
- Instancias de VM hacia y desde Internet
- De instancia de VM a instancia de VM
- Desde Google Cloud hacia y desde redes on-premise
- Entre dos redes on-premise conectadas a través de Network Connectivity Center
- Entre dos radios de VPC de Network Connectivity Center
Características de las redes de VPC
Puedes probar la conectividad entre recursos que usen las siguientes funciones (se admiten tanto IPv4 como IPv6 cuando corresponda):
- Redes de VPC
- Emparejamiento entre redes VPC
- VPC compartida
- Acceso privado de Google
- Intervalos de IP de alias
- Direcciones IP privadas fuera del intervalo de direcciones RFC 1918
- Una instancia de VM de Compute Engine con varias interfaces de red
- Rutas personalizadas importadas de redes de VPC emparejadas
- Enrutamiento transitivo de VPC
- Reglas de cortafuegos de VPC
- Políticas de cortafuegos de red regionales
- Políticas de cortafuegos jerárquicas y políticas de cortafuegos de red globales
- Etiquetas de Resource Manager para cortafuegos, incluido cuando se adjuntan 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
Google Cloud soluciones de redes híbridas
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 las 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 Google Cloud tipos de balanceadores de carga: balanceadores de carga de aplicaciones externos, balanceadores de carga de red de paso a través externos, balanceadores de carga de red de proxy externos, balanceadores de carga de aplicaciones internos, balanceadores de carga de red de paso a través internos y balanceadores de carga de red de proxy internos.
- Se admite la prueba de conectividad con las direcciones IP del balanceador de carga.
- Se admite la verificación de la conectividad de las comprobaciones de estado de Cloud Load Balancing con los backends.
- Los balanceadores de carga TCP/UDP internos se pueden usar como siguiente salto.
Para ver las funciones de balanceo de carga en Cloud que no se admiten, consulta la sección Configuraciones no admitidas.
Para obtener información sobre cómo analiza Connectivity Tests los backends de un balanceador de carga, consulte Número de trazas en una prueba de un balanceador de carga.
Google Kubernetes Engine (GKE)
- Se admite la conectividad con los nodos de GKE y entre ellos, así como con 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 VPC. Sin embargo, algunas funciones de red de GKE, como las políticas de red de GKE, no son compatibles.
Para ver las funciones de GKE que no se admiten, consulta la sección Configuraciones no admitidas.
Endpoints sin servidor
Se admiten los siguientes endpoints sin servidor:
Las direcciones IP de origen de los endpoints sin servidor suelen ser no deterministas. En cada prueba, Pruebas de conectividad selecciona una dirección IP aleatoria del grupo de direcciones que están disponibles para el endpoint sin servidor. Para obtener información general sobre cómo se asignan las direcciones IP a los endpoints sin servidor, consulta lo siguiente:
- Para obtener información sobre la conectividad externa, consulta Direcciones IP.
- Para obtener información sobre la conectividad a través de un conector de acceso a VPC sin servidor, consulta Enviar tráfico sin servidor a una red de nube privada virtual.
- Para obtener información sobre la conectividad a través de la salida de VPC directa, consulta la sección sobre la 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 servidor se configuran para enrutar el tráfico desde los endpoints sin servidor a través de la conectividad externa en lugar de la red de nube privada virtual, en función de los ajustes de salida.
Para ver las funciones sin servidor que no se admiten, consulta la sección Configuraciones no admitidas.
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 las conexiones de Private Service Connect, las conexiones de intercambio de tráfico entre redes de VPC y las réplicas externas.
- Se admiten las instancias de Memorystore para Redis.
- Se admiten los clústeres de Memorystore para Redis.
Configuraciones no admitidas
El análisis de configuración de las pruebas de conectividad no admite las siguientes configuraciones de red:
- No se admiten reglas de políticas de cortafuegos con objetos de geolocalización, datos de inteligencia sobre amenazas ni objetos FQDN. Si estos cortafuegos pueden afectar a un flujo de tráfico específico, las pruebas de conectividad devuelven una advertencia correspondiente.
- No se admiten back-ends de NEG de Internet que segmenten FQDNs. Sin embargo, se admiten backends de NEG de Internet que tienen como destino direcciones IP.
- No se admiten los balanceadores de carga de Cloud Service Mesh con reglas de reenvío
INTERNAL_SELF_MANAGED. - Las políticas de Google Cloud Armor no se tienen en cuenta ni se usan al rastrear la conectividad a una dirección IP de balanceador de carga de aplicaciones externo.
- No se admiten pasarelas VPN de alta disponibilidad conectadas a VMs de Compute Engine.
- Las configuraciones de NetworkPolicies de GKE y suplantación de IP no se tienen en cuenta ni se usan al rastrear la conectividad a direcciones IP dentro de clústeres y nodos de GKE.
- No se admiten las réplicas de servidores externos de Cloud SQL definidas por nombres DNS. Sin embargo, se admiten las réplicas de servidores externos definidas por direcciones IP.
- No se admiten las Cloud Run Functions (2.ª gen.). Sin embargo, puedes probar la conectividad desde una función de Cloud Run (2.ª gen.) creando una prueba de conectividad para la revisión de Cloud Run subyacente. Se crea una revisión de Cloud Run cada vez que se despliega una función de Cloud Run.
- No se admite el entorno flexible de App Engine.
- Las tareas de Cloud Run no se admiten. Para obtener más información, consulta Servicios y trabajos: dos formas de ejecutar tu código.
Cómo analizan las pruebas de conectividad el plano de datos activo
La función de análisis del plano de datos activo prueba la conectividad enviando varios paquetes de rastreo desde el endpoint de origen al de destino. Los resultados del análisis del plano de datos activos muestran el número de sondas enviadas, el número de sondas que han llegado correctamente al destino y el estado de accesibilidad. Este estado se determina en función del número de sondas que se han entregado correctamente, tal como se describe en la siguiente tabla.
| Estado | Número de sondas que han llegado a su destino |
|---|---|
| Accesible | Como mínimo un 95% |
| Inaccesible | Ninguno |
| Parcialmente accesible | Más de 0 y menos del 95% |
Además de mostrar cuántos paquetes se han entregado correctamente, el análisis del plano de datos en tiempo real también muestra información sobre la latencia unidireccional mediana y del percentil 95. El análisis del plano de datos activo no depende del análisis de configuración. En su lugar, el análisis del plano de datos activo proporciona una evaluación independiente del estado de la conectividad.
Si observas discrepancias entre los resultados del análisis de la configuración y los del análisis del plano de datos activo, consulta el artículo Solucionar problemas con las pruebas de conectividad.
Configuraciones admitidas
El análisis del plano de datos activos 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 endpoint de plano de control de GKE
- Entre una instancia de VM y una ubicación perimetral de la red de Google. El análisis del plano de datos activo se realiza desde la instancia de VM de origen hasta todos los routers perimetrales de la red de Google posibles a través de los cuales se puede enrutar el tráfico en función de la dirección IP de destino.
- Protocolos IP: TCP y UDP
Características de las redes de VPC
Puedes verificar de forma dinámica la conectividad entre recursos que usan las siguientes funciones:
- Emparejamiento entre redes VPC
- VPC compartida
- Intervalos de IP de alias
- Direcciones IP externas
- Direcciones IP internas: direcciones IP privadas fuera del intervalo de direcciones RFC 1918
- Rutas personalizadas
- Balanceadores de carga como destino. Los backends admitidos de los balanceadores de carga son grupos de instancias, grupos de endpoints de red (NEG) zonales y backends de Private Service Connect.
- Reglas de cortafuegos de entrada, incluidas las reglas de políticas de cortafuegos jerárquicas de entrada y las reglas de cortafuegos de VPC de entrada
- Instancias con direcciones IPv6, incluidas las instancias con varias interfaces de red
- Puntos finales de Private Service Connect para servicios publicados y APIs de Google
Configuraciones no admitidas
No se admiten todas las configuraciones que no se indiquen explícitamente como compatibles. Además, no se admiten configuraciones en las que la conectividad esté bloqueada por reglas de cortafuegos de salida.
En cualquier prueba, si no se ejecuta la función de análisis del plano de datos en tiempo real, aparecerá N/A o - en el campo Resultado de la última transmisión de paquetes.
Consideraciones y restricciones
Tenga en cuenta los siguientes aspectos a la hora de decidir si usar pruebas de conectividad.
- El análisis de configuración que realizan las pruebas de conectividad se basa por completo en la información de configuración de los recursos y puede que no represente el estado o la condición reales del plano de datos de una red VPC. Google Cloud
- Aunque Pruebas de conectividad adquiere información de configuración dinámica, como el estado del túnel de Cloud VPN y las rutas dinámicas de Cloud Router, no accede ni mantiene el estado de la infraestructura de producción interna de Google ni los componentes del plano de datos.
- El estado
Packet could be deliveredde una prueba de conectividad no garantiza que el tráfico pueda pasar por el plano de datos. El objetivo de la prueba es validar los problemas de configuración que pueden provocar una caída del tráfico.
En las rutas admitidas, los resultados del análisis del plano de datos en tiempo real complementan los resultados del análisis de configuración al comprobar si los paquetes transmitidos llegan al destino.
Connectivity Tests no tiene información sobre redes que no sean de Google Cloud
Las redes externas se definen de la siguiente manera:
- Redes locales que residen en tu centro de datos u otras instalaciones 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.
Pruebas de conectividad no realiza un seguimiento de las conexiones del cortafuegos
El seguimiento de conexiones de los cortafuegos de VPC almacena información sobre las conexiones nuevas y establecidas, y permite admitir o restringir el tráfico posterior en función de esa información.
El análisis de configuración de las pruebas de conectividad no admite el seguimiento de conexiones del cortafuegos porque la tabla de conexiones del cortafuegos se encuentra en el plano de datos de una instancia de VM y no se puede acceder a ella. Sin embargo, el análisis de configuración puede simular el seguimiento de conexiones permitiendo una conexión de retorno que normalmente se denegaría por una regla de cortafuegos de entrada, siempre que las pruebas de conectividad inicien la conexión saliente.
El análisis del plano de datos en tiempo real no admite pruebas de seguimiento de conexiones de firewall.
Las pruebas de conectividad no pueden probar instancias de VM configuradas para modificar el comportamiento de reenvío
Las pruebas de conectividad no pueden probar instancias de VM que se hayan configurado para actuar en el plano de datos como routers, cortafuegos, pasarelas NAT, VPNs, etc. 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 activo no admite este tipo de prueba.
Los tiempos de los resultados de las pruebas de conectividad pueden variar
Obtener los resultados de las pruebas de conectividad puede tardar entre 30 segundos y 10 minutos. El tiempo que tarda una prueba depende del tamaño de la configuración de tu red VPC y del número de recursos Google Cloud que utilices.
En la siguiente tabla se muestran los tiempos de respuesta que pueden esperar todos los usuarios que ejecuten 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 Google Cloud balanceadores de carga.
| Tamaño del proyecto | Número 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 5000 | 120 segundos para el 95% de las consultas de todos los usuarios |
| Proyecto grande | Más de 5000 | 600 segundos para el 95% de las consultas de todos los usuarios |
El análisis del plano de datos activos no está diseñado para la monitorización continua
El análisis del plano de datos activo realiza una verificación única de la conectividad de red con fines de diagnóstico. Para monitorizar continuamente la conectividad y la pérdida de paquetes, usa el panel de rendimiento.
Compatible con los Controles de Servicio de VPC
Los Controles de Servicio de VPC pueden proporcionar seguridad adicional a las pruebas de conectividad para ayudar a mitigar el riesgo de filtración externa de datos. Con Controles de Servicio de VPC, puedes añadir proyectos a perímetros de servicio que protejan recursos y servicios de solicitudes que procedan de fuera del perímetro.
Para obtener más información sobre los perímetros de servicio, consulta la página Detalles y configuración de los perímetros de servicio de la documentación de Controles de Servicio de VPC.
Siguientes pasos
Identificar y solucionar problemas de ICMP (tutorial)