En esta página se describe cómo mide la accesibilidad Connectivity Tests. También se explica cómo funcionan el análisis de configuración y el análisis del plano de datos activos.
¿Qué es la accesibilidad?
Un recurso es accesible desde otro endpoint si las configuraciones de red, como los cortafuegos y las rutas, permiten que el tráfico vaya de uno a otro. Por ejemplo, si la configuración de red debe permitir que la VM1 envíe paquetes a la VM2, se dice que la VM2 es accesible desde la VM1.
Tenga en cuenta los siguientes aspectos sobre cómo mide la accesibilidad Connectivity Tests:
- Pruebas de conectividad mide la accesibilidad de un origen concreto a un destino concreto. El hecho de que VM1 pueda acceder a VM2 no significa necesariamente que VM3 pueda acceder a VM2.
- Pruebas de conectividad mide la accesibilidad unidireccional. El hecho de que la VM1 pueda abrir una conexión con la VM2 no significa que la VM2 pueda abrir una conexión con la VM1. Las reglas de cortafuegos pueden permitir el tráfico en una dirección, pero no en la otra.
- Pruebas de conectividad mide la accesibilidad de un protocolo y un puerto de destino concretos. El hecho de que VM1 pueda acceder a VM2 en
tcp:443no significa que pueda acceder a ella entcp:80. - Las pruebas de conectividad solo prueban las configuraciones de la red VPC que pueden afectar a la entrega de paquetes del origen al destino. Google Cloud No comprueba si se está ejecutando un servidor válido en el destino, si las reglas del cortafuegos del sistema operativo pueden bloquear el tráfico o si el software de seguridad bloquea un paquete que contiene una carga útil de virus.
El concepto de accesibilidad se originó en la teoría de grafos. Desde un punto de vista conceptual, el gráfico de accesibilidad de una red contiene todos los endpoints como nodos y aristas direccionales que indican la accesibilidad de los nodos de origen a los de destino.
El análisis de accesibilidad es un término más genérico que describe un conjunto de análisis que se pueden llevar a cabo para determinar la accesibilidad de la red. Uno de los casos prácticos de un análisis de accesibilidad es una prueba de conectividad. En este caso, conectividad hace referencia al estado de las conexiones de red.
En cada paso de la ruta de reenvío de la red, un análisis de accesibilidad prueba y proporciona resultados de la configuración de red subyacente. Por ejemplo, Connectivity Tests analiza las Google Cloud reglas de cortafuegos y las rutas Google Cloud que se aplican a un paquete de prueba simulado.
Cómo funcionan las pruebas de conectividad
Pruebas de conectividad incluye dos componentes principales: un análisis de configuración y un análisis del plano de datos activo. En esta sección se describe cómo funcionan estos dos tipos de análisis.
Cómo funciona el análisis de configuración
En esta sección se describe cómo funcionan Connectivity Tests y sus componentes.
Pruebas de conectividad realiza un análisis de accesibilidad que evalúa los Google Cloud recursos de tu ruta de prueba en comparación con un modelo de configuración ideal. Se complementa con la función de análisis del plano de datos activo, que envía paquetes para verificar el estado del plano de datos y proporcionar información de referencia para las configuraciones admitidas. Para obtener más información sobre cómo funciona el análisis del plano de datos en tiempo real, consulta el artículo Cómo funciona el análisis del plano de datos en tiempo real.
Como administrador de red, puedes controlar muchas configuraciones que podrían influir en el resultado del análisis, aunque hay algunas excepciones. Por ejemplo, no tienes control sobre las redes VPC que alojan servicios gestionados por Google, como las instancias de Cloud SQL. Además, debido a las restricciones de permisos, es posible que no tengas control sobre las reglas de políticas de cortafuegos jerárquicas que afecten a tu red.
Cuando ejecutas una prueba de conectividad, introduces un conjunto específico de parámetros y recibes resultados formateados en forma de seguimiento de red o consulta. Una prueba de conectividad genera más de un rastreo si una prueba tiene varias rutas posibles en la red (por ejemplo, cuando el endpoint de destino es un balanceador de carga Google Cloud con varios back-ends).
- Una coincidencia significa que las pruebas de conectividad encuentran una configuración Google Cloud que permite que el paquete simulado continúe por la ruta de prueba.
- Sin coincidencias significa que las pruebas de conectividad no han encontrado ninguna coincidencia. Por lo tanto, la configuración no existe.
- Una coincidencia denegada significa que las pruebas de conectividad encuentran unaGoogle Cloud configuración en la que se debe descartar el paquete de prueba simulado.
Componentes de pruebas de conectividad
Una prueba de conectividad es el componente de nivel superior que contiene todos los demás subcomponentes de prueba necesarios para el análisis de la configuración. Entre estos componentes se incluyen los siguientes:
- Endpoints de origen y destino
- Detalles de accesibilidad de la prueba y sus trazas, incluido un resultado de accesibilidad general determinado por el análisis de configuración
- Una o varias trazas, cada una de las cuales contiene uno o varios pasos
- Un estado para cada paso
Cada prueba tiene un nombre único y cada paso tiene un estado y metadatos Info asociados. Por ejemplo, si un paso comprueba una ruta, RouteInfo
se incluye metadatos en ese paso.
En el siguiente diagrama se muestra una prueba de una instancia de VM de Compute Engine a otra. Para ver las descripciones de los componentes de la prueba, consulta las secciones siguientes.
Endpoints de origen y destino
El análisis de configuración de Connectivity Tests admite un encabezado de paquete de 5 tuplas sin el puerto de origen. Esto se debe a que el puerto de origen no se usa para validar recursos en las configuraciones de red de Google Cloud . Por lo tanto, no es necesario que lo proporciones al ejecutar pruebas.
El encabezado del paquete contiene los siguientes componentes:
- Un protocolo de red
- Un endpoint de origen, que consta de uno de los siguientes elementos:
- Nombre de una instancia de VM
- Una dirección IP de origen
- Un servicio de App Engine de origen
- Un entorno de Cloud Run Functions (1.ª gen.)
- Un servicio de Cloud Run
- Nombre de una instancia de Cloud SQL
- Nombre de un clúster de un plano de control de GKE
- Un endpoint de destino, que consta de uno de los siguientes elementos y un número de puerto:
- Nombre de una instancia de VM
- Una dirección IP de destino
- Nombre de una instancia de Cloud SQL
- Nombre de un clúster de un plano de control de GKE
- Un endpoint de Private Service Connect
También puedes especificar un tipo de red Google Cloud o noGoogle Cloud , o bien una combinación de un tipo de red y una dirección IP o un nombre de instancia de VM para identificar de forma única una ubicación de red.
Se admiten los siguientes protocolos de red para máquinas virtuales, direcciones IP y servicios gestionados por Google:
- TCP
- UDP
- ICMP
- ESP
- AH
- SCTP
- IPIP
Los conectores de Acceso a VPC sin servidor admiten los siguientes protocolos de red:
- TCP
- UDP
Se admiten puertos de destino para los protocolos TCP o UDP. Si no especificas un puerto, el valor predeterminado es el puerto 80.
Trazas, pasos y estados
El análisis de configuración contiene una o varias trazas. Cada traza representa una ruta de reenvío de paquetes simulada y única en una prueba.
- Cada traza contiene varios pasos ordenados.
- Cada paso contiene un estado relacionado con la Google Cloud configuración que comprueban las pruebas de conectividad en ese paso.
- Los estados se clasifican en estados no finales y finales.
Estados no finales
Los estados no finales representan una comprobación de la configuración de cada Google Cloud recurso de la ruta de prueba, como una instancia de VM, un endpoint, una regla de firewall, una ruta o un Google Cloud balanceador de carga.
Hay cuatro estados no finales:
- Inicial
- Comprobación de la configuración
- Reenvío
- Transición
Para obtener más información, consulta Estados del análisis de configuración.
Estado final
Cada traza debe terminar con un estado final, que es el último paso de la traza.
Hay cuatro estados finales posibles:
DropAbortForwardDeliver
Cada estado tiene un motivo asociado. Para obtener más información, consulta los detalles de cada estado final.
Resultado general de la accesibilidad
El análisis de la configuración también proporciona un resultado general de accesibilidad que puede tomar uno de estos cuatro valores: Reachable, Unreachable, Ambiguous o Undetermined.
Conocer el resultado general de accesibilidad puede ser útil para configurar la monitorización o la automatización.
Para obtener más información, consulta Resultado general de accesibilidad.
Comprobación de spoofing
Pruebas de conectividad realiza una comprobación de suplantación de identidad cuando un paquete simulado hacia o desde una instancia de VM usa una dirección IP que no es propiedad de esa instancia. Las direcciones IP propiedad de una máquina virtual incluyen todas las direcciones IP internas y secundarias de la máquina virtual.
Si la dirección parece proceder de tráfico externo (también denominada dirección externa), la dirección IP no supera la comprobación de suplantación.
Metadatos
Cada estado puede tener metadatos asociados en forma de campo Info.
Por ejemplo, InstanceInfo contiene detalles de una instancia de VM, como el nombre y la dirección IP.
El análisis de configuración proporciona metadatos sobre la propia prueba y sobre cada paso de una prueba.
Cómo funciona el análisis del plano de datos activos
El mecanismo de sondeo para el análisis del plano de datos activos no implica al SO invitado y es totalmente transparente para el usuario. Las sondas se insertan en la red en nombre del endpoint de origen y se eliminan justo antes de enviarse al endpoint de destino. Las sondas no se incluyen en la facturación de red normal, las métricas de telemetría ni los registros de flujo.
Siguientes pasos
Usar pruebas de conectividad para diferentes casos prácticos de conectividad
Identificar y solucionar problemas de ICMP (tutorial)