Un caso de uso habitual de las pruebas de conectividad es probar la conexión entre dos instancias de máquina virtual (VM) de Compute Engine en la misma red de nube privada virtual (VPC) o en redes de VPC emparejadas.
En este tipo de prueba, Pruebas de conectividad evalúa la accesibilidad mediante el análisis de la configuración y el análisis del plano de datos activo. Para analizar la configuración, Pruebas de conectividad identifica y evalúa una ruta de traza.
En los diagramas de seguimiento de esta página se usan los símbolos que se describen en la siguiente leyenda.
En el siguiente diagrama se muestra la ruta de seguimiento habitual entre dos instancias de VM. El objeto Match routes puede representar rutas que dirigen el tráfico en una sola red de VPC o entre dos redes de VPC emparejadas.
En los pasos siguientes se describen los puntos de control que corresponden a cada punto del diagrama de seguimiento. La comprobación puede fallar en cualquier punto. En los resultados de la consulta se muestra el motivo de cada error. Para ver una lista completa de los estados y mensajes de las pruebas, consulta Estados del análisis de configuración.
Pruebas de conectividad verifica que la VM de origen puede enviar paquetes de salida con la dirección IP de origen especificada o que puede usar el proceso de comprobación de suplantación de identidad de forma predeterminada.
-
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.
Para determinar si se pueden enviar paquetes de rastreo desde la fuente, Pruebas de conectividad verifica las reglas de cortafuegos de salida adecuadas. Como parte de este proceso, Pruebas de conectividad empieza evaluando las reglas de las políticas de cortafuegos jerárquicas que haya. Para obtener información sobre cómo afectan las reglas de políticas de cortafuegos jerárquicas y las reglas de cortafuegos de VPC a la conectividad, consulta los ejemplos de políticas de cortafuegos jerárquicas.
Pruebas de conectividad encuentra (coincide con) una ruta para la dirección IP de destino, según el orden de enrutamiento. Si no hay otras rutas disponibles para la instancia de VM de destino, Connectivity Tests usa la ruta estática predeterminada con la siguiente salto como puerta de enlace de Internet. Todas las redes de VPC usan esta ruta predeterminada, a menos que la hayas eliminado.
Pruebas de conectividad verifica que las reglas del cortafuegos de entrada de la red permiten que el paquete llegue a la VM de destino. De nuevo, Connectivity Tests empieza evaluando las reglas de políticas de cortafuegos jerárquicas que haya.
Si es necesario, Connectivity Tests ejecuta una comprobación de suplantación en el paquete que llega a la segunda VM.
Pruebas de conectividad verifica que la VM de destino puede recibir un paquete con la dirección IP de destino especificada. Si esta dirección es una dirección IP externa, la VM de destino debe tener habilitado el reenvío de IP. Una dirección IP externa es una dirección que no pertenece a la VM.
En la siguiente captura de pantalla de la consola Google Cloud se muestran los resultados de una prueba de VM a VM.
El análisis de configuración muestra el resultado El paquete se ha podido enviar.
En la respuesta de la API, esta etiqueta se corresponde con un estado final de Deliver.
Este resultado muestra que el análisis de configuración ha validado la conectividad de red de todos los recursos Google Cloud de la ruta de la VM de origen a la de destino. En este caso, la ruta incluía dos reglas de cortafuegos de VPC: una regla de cortafuegos de VPC implícita (llamada default) y otra que se creó para esta red de VPC.
Además, Pruebas de conectividad verificó de forma dinámica que se puede acceder a la VM de destino mediante sondeos activos. En el campo Resultado de la última transmisión de paquetes se muestran los detalles de este resultado.
Puede desplegar cada una de las tarjetas de la ruta de seguimiento para ver más detalles.
En el siguiente ejemplo se muestra una tarjeta ampliada de una regla de firewall de entrada. Esta tarjeta incluye información sobre la red de VPC, la acción configurada para la regla de cortafuegos (permitir) y la prioridad de la regla.
Cuando una traza contiene una ruta de red de VPC con el siguiente salto como una red de VPC emparejada, el inicio de la traza no es una instancia de VM, sino una red de VPC. Este tipo de traza valida las reglas de cortafuegos y las rutas a nivel de red, ya que la dirección IP que pruebas procede de un intervalo de red en lugar de una instancia de VM.
Las redes emparejadas pueden estar en el mismo proyecto o en proyectos diferentes. En el siguiente ejemplo de traza se muestran redes emparejadas en diferentes proyectos.
Fallos de prueba de redes de VPC
En la siguiente tabla se enumeran los errores habituales de las pruebas en redes de VPC.
| Tipo de fallo | Descripción | Resultados de traza |
|---|---|---|
| Bloqueada por una regla de cortafuegos | El tráfico que sale de un endpoint de origen o entra en un endpoint de destino se bloquea mediante una regla de política de cortafuegos jerárquica o una regla de cortafuegos de VPC. |
|
| No se ha encontrado ninguna ruta que coincida | No se ha encontrado ninguna ruta al endpoint de destino. |
|
| La instancia no se está ejecutando | La instancia de VM de destino existe, pero no está en estado de ejecución. | El análisis determina que el paquete podría perderse. |
| Siguiente salto no válido | El siguiente salto configurado para una instancia de VM ya no existe y la ruta a esa instancia no es válida. | El análisis determina que el paquete podría perderse. |
En la siguiente captura de pantalla se muestra un rastreo que ha fallado porque la conectividad se ha bloqueado por una regla de política de cortafuegos jerárquica de entrada.
Pruebas fallidas de redes de VPC compartidas
En las redes de VPC compartidas, no tener permisos para el proyecto host o el proyecto de servicio puede provocar los errores de prueba que se indican en la siguiente tabla.
| Tipo de fallo | Comportamiento | Resultados de traza |
|---|---|---|
| Permisos solo para el proyecto del host | No puedes ejecutar el rastreo porque no tienes permisos para el proyecto de servicio en el que se encuentra la dirección IP de destino. | El análisis de configuración muestra el resultado Análisis de configuración anulado. En la respuesta de la API, esta etiqueta se corresponde con un estado final de
Abort. |
| Permisos solo para el proyecto de servicio |
No puedes ejecutar el rastreo ni seleccionar la red del proyecto host en la consola Google Cloud porque no tienes permiso. Como el proyecto host es el propietario de las configuraciones de red, no se puede realizar un rastreo de los recursos del proyecto de servicio sin acceso a las reglas de cortafuegos de VPC, las rutas de red o las direcciones IP del proyecto host. |
El resultado general de la prueba de accesibilidad es
Undetermined
porque las pruebas de conectividad no pueden determinar si el paquete se puede
enviar al destino. |
Fallos de prueba de redes de emparejamiento entre redes de VPC
Con el emparejamiento entre redes de VPC, si no tienes permiso para acceder al proyecto de la red peered
Google Cloud desde la red primary, se puede producir el resultado de la prueba que se muestra en la siguiente tabla.
| Tipo de fallo | Comportamiento | Resultados de traza |
|---|---|---|
| No tienes permisos para la configuración del proyecto en la red VPC emparejada. | Las pruebas de conectividad solo pueden rastrear las configuraciones del proyecto de la red principal. | El análisis de configuración muestra el resultado El paquete podría reenviarse.
Este resultado indica que un paquete saldría de la red y se enviaría
a una red a la que no tienes acceso. En este caso, el paquete se ha reenviado a una pasarela de red emparejada. En la respuesta de la API, este estado corresponde a un estado final de Forward. |
La siguiente ruta de seguimiento muestra el estado de reenvío de las redes de VPC emparejadas.
Siguientes pasos
- Situaciones de prueba habituales
- Información sobre las pruebas de conectividad
- Solucionar problemas con las pruebas de conectividad