Casos de uso comunes de pruebas de conectividad

Las pruebas de conectividad evalúan si el tráfico puede viajar correctamente entre extremos dentro de tu red. Evalúan la accesibilidad mediante el análisis de la configuración de tu red y, en algunos casos de uso, mediante el envío de paquetes de sondeo.

En esta página, se describen casos de uso comunes de las pruebas de conectividad que se dividen en seis categorías:

  • Pruebas dentro de las redes de la nube privada virtual (VPC), incluidas las redes que usan el intercambio de tráfico entre redes de VPC y la VPC compartida
  • Prueba servicios administrados por Google (vista previa)
  • Pruebas desde una red de VPC en una red que no sea de VPC, como un centro de datos local
  • Prueba desde una red que no sea de Google a una red de VPC
  • Realiza pruebas desde una red ajena a Google Cloud a otra red que no sea de Google Cloud
  • Prueba de balanceadores de cargas de Google Cloud

En Detecta configuraciones no válidas o incoherentes, se describe cómo manejar esas situaciones.

En el caso práctico de prueba de una instancia de máquina virtual (VM) a otra, se describe una situación de prueba de extremo a extremo completa, incluidos los resultados de la prueba proporcionados en Google Cloud Console.

Si deseas obtener instrucciones para ejecutar pruebas, consulta Ejecuta pruebas de conectividad.

Leyenda para diagramas de seguimiento

En los diagramas de seguimiento de esta página, se usan los símbolos que se describen en la siguiente leyenda.

Symbol Name Significado
Leyenda para el diagrama de seguimiento de paquetes: diamante gris.
Diamante gris
Check Point Un punto decisivo en el que las pruebas de conectividad comprueban una configuración y deciden si un paquete de seguimiento debe reenviarse, entregarse o descartarse.
Leyenda para el diagrama de seguimiento de paquetes: rectángulo azul.
Rectángulo azul
Hop Es un paso en la ruta de reenvío de un paquete de seguimiento, que representa un recurso de Google Cloud que reenvía un paquete al siguiente salto en una red de VPC (por ejemplo, a un proxy de Cloud Load Balancing o un túnel de Cloud VPN).
Leyenda para el diagrama de seguimiento de paquetes: hexágono naranja.
Hexágono naranja
Extremo Es el origen o el destino de un paquete de seguimiento.

Pruebas dentro de redes de VPC

Un caso de uso común para las pruebas de conectividad es la prueba entre dos instancias de máquina virtual (VM) de Compute Engine en las mismas redes de VPC o en redes de VPC con intercambio de tráfico. Para este tipo de prueba, las pruebas de conectividad evalúan la accesibilidad mediante el análisis de configuración y la verificación dinámica.

Para analizar la configuración, las pruebas de conectividad identifican y evalúan una ruta de seguimiento.

En el siguiente diagrama, se muestra la ruta de seguimiento típica 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 con intercambio de tráfico.

Seguimiento de VM de origen a VM de destino.
Seguimiento de VM de origen a VM de destino

En los siguientes pasos, se describen los puntos de control que corresponden a cada punto en el diagrama de seguimiento. En cada punto de control, la verificación puede fallar. En los resultados de la consulta, se muestra el motivo de cada falla. Para obtener una lista completa de los mensajes y estados de prueba, consulta la referencia de estados de análisis de configuración.

  1. Las pruebas de conectividad verifican que la VM de origen pueda enviar paquetes de salida con la dirección IP de origen especificada, o bien se establece de forma predeterminada en la dirección IP interna principal. Si no es así, la VM debe tener habilitado el reenvío de direcciones IP.
  2. Las pruebas de conectividad realizan una verificación de falsificación de identidad cuando un paquete simulado desde o hacia una instancia de VM usa una dirección IP que no es propiedad de esa instancia. Las direcciones IP que pertenecen a una VM incluyen todas las direcciones IP internas de la VM y las direcciones IP secundarias.

    Si la dirección es una dirección que parece originarse en el tráfico externo, también llamada dirección extranjera, entonces la dirección IP no pasa la verificación de falsificación de identidad.

  3. Para determinar si se pueden enviar paquetes de seguimiento desde el origen, las pruebas de conectividad verifican las reglas de firewall de salida adecuadas. Como parte de este proceso, las pruebas de conectividad comienzan con la evaluación de cualquier regla de política de firewall jerárquica que exista. Para obtener detalles sobre cómo las reglas de políticas de firewall jerárquicas y las reglas de firewall de VPC afectan la conectividad, consulta Ejemplos de políticas de firewall jerárquicas.
  4. Las pruebas de conectividad encuentran (hacen coincidir) 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, las pruebas de conectividad utilizan la ruta estática predeterminada con el siguiente salto como la puerta de enlace de Internet. Todas las redes de VPC usan esta ruta predeterminada, a menos que la hayas quitado.
  5. Las pruebas de conectividad verifican que las reglas de firewall de entrada de la red permitan que el paquete llegue a la VM de destino. Una vez más, las pruebas de conectividad comienzan cuando se evalúan las reglas de políticas jerárquicas de firewall que existen.
  6. Si es necesario, las pruebas de conectividad ejecutan una verificación de falsificación en el paquete que llega a la segunda VM.
  7. Las pruebas de conectividad verifican que la VM de destino pueda recibir un paquete con la dirección IP de destino especificada. Si esta dirección es una dirección IP extranjera, la VM de destino debe tener habilitado el reenvío de IP. Una dirección IP extranjera es una dirección que no pertenece a la VM.

Console

En la siguiente captura de pantalla de Google Cloud Console, se muestran los resultados de una prueba de VM a VM.

El análisis de configuración muestra el resultado Es posible que se haya entregado el paquete (Packet could be delivered) (en la respuesta de la API, esta etiqueta corresponde a un estado final de Deliver).

En este resultado, se muestra que el análisis de configuración validó la conectividad de red para cada recurso de Google Cloud en la ruta desde la VM de origen hasta la VM de destino. En este caso, la ruta incluía dos reglas de firewall de VPC: una regla de firewall de VPC implícita (llamada default) y una creada para esta red de VPC.

Además, las pruebas de conectividad verificaron de forma dinámica que se puede acceder a la VM de destino mediante el sondeo activo. En el campo Resultado de la última transmisión de paquetes (Last packet transmission result), se muestran los detalles de este resultado.

Captura de pantalla de Cloud Console para el seguimiento de VM a VM.
Captura de pantalla de Cloud Console para el seguimiento de VM a VM

Puedes expandir cada una de las tarjetas en la ruta de seguimiento para ver más detalles.

En el ejemplo siguiente, se muestra una tarjeta expandida para una regla de firewall de entrada. Esta tarjeta incluye información sobre la red de VPC, la acción configurada para la regla de firewall (permitir) y la prioridad de la regla.

Tarjeta de la regla de firewall de entrada expandida
Tarjeta de la regla de firewall de entrada expandida

Cuando un seguimiento contiene una ruta de red de VPC con el siguiente salto como una red de VPC con intercambio de tráfico, el inicio del seguimiento no es una instancia de VM, sino una red de VPC. Este tipo de seguimiento valida las rutas y las reglas de firewall a nivel de red, ya que la dirección IP que pruebas proviene de un rango de red, y no de una instancia de VM.

Las redes con intercambio de tráfico pueden existir en el mismo proyecto o en proyectos diferentes. En el siguiente ejemplo de seguimiento, se muestran redes con intercambio de tráfico en proyectos diferentes.

Seguimiento de VM a VM mediante una red de VPC con intercambio de tráfico accesible en un proyecto diferente
Seguimiento de VM a VM mediante una red de VPC con intercambio de tráfico accesible en un proyecto diferente

Fallas de prueba para redes de VPC

En la siguiente tabla, se enumeran las fallas comunes de las pruebas dentro de las redes de VPC.

Tipo de falla Descripción Resultados del seguimiento
Bloqueado por una regla de firewall Una regla de política de firewall jerárquica o una regla de firewall de VPC bloquean el tráfico que sale de un extremo de destino o de origen.
  • Si la conectividad está bloqueada por una regla de política de firewall jerárquica, el seguimiento incluye el nombre de la política. Ten en cuenta que la persona que ejecuta la prueba podría no tener permiso para ver los detalles de la política. Para obtener más detalles sobre esta situación, consulta Solución de problemas.
  • Si una regla de firewall de VPC bloquea la conectividad, el seguimiento enumera el nombre de la regla de firewall de entrada o salida correspondiente.
No hay rutas que coincidan No se pudo encontrar una ruta al extremo de destino.
  • Si las instancias de VM de origen y de destino se encuentran en redes de VPC diferentes y esas redes no intercambian tráfico, el análisis determina que es posible que se haya descartado el paquete.
  • Si las VM están en la misma red, pero no se encuentra una ruta coincidente, el tráfico se envía en la ruta estática predeterminada, con un siguiente salto a la puerta de enlace de Internet. En este caso, el tráfico nunca llega a la VM de destino, y el análisis determina que es posible que se haya descartado el paquete.
  • Si no hay una ruta a una puerta de enlace de Internet, el análisis determina que Es posible que se haya descartado el paquete.
La instancia no se encuentra en ejecución La instancia de VM de destino existe, pero no se encuentra en un estado de ejecución. El análisis determina que Es posible que se haya descartado el paquete.
El siguiente salto no es 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 Es posible que se haya descartado el paquete.

Console

En la siguiente captura de pantalla, se muestra un seguimiento que falló debido a que una regla de política de firewall jerárquica de entrada bloqueó la conectividad.

Captura de pantalla de Cloud Console para un seguimiento que está bloqueado por una regla de política de firewall jerárquica
Captura de pantalla de Cloud Console para un seguimiento bloqueado por una regla de políticas de firewall jerárquicas

Fallas de prueba para redes de VPC compartidas

En las redes de VPC compartida, no tener permisos para el proyecto host o el proyecto de servicio puede generar las fallas de las pruebas que se enumeran en la siguiente tabla.

Tipo de falla Comportamiento Resultados del seguimiento
Permisos solo para el proyecto host No puedes ejecutar el seguimiento porque no tienes los 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 Se anuló el análisis de configuración (en la respuesta de la API, esta etiqueta corresponde a un estado final de Abort).
Permisos solo para el proyecto de servicio

No puedes ejecutar el seguimiento ni seleccionar la red del proyecto host en Cloud Console porque no tienes permiso.

Debido a que el proyecto host posee parámetros de configuración de red, un seguimiento de los recursos del proyecto de servicio no puede continuar sin acceso a reglas de firewall de VPC, rutas de red o direcciones IP en el proyecto host.

El resultado de accesibilidad general es Undetermined, ya que las pruebas de conectividad no pueden determinar si el paquete se puede entregar al destino.

Fallas de prueba para redes de intercambio de tráfico entre redes de VPC

Con el intercambio de tráfico entre redes de VPC, no tener permiso para el proyecto de Google Cloud de la red peered desde la red primary puede provocar las fallas de prueba que se enumeran en la siguiente tabla.

Tipo de falla Comportamiento Resultados del seguimiento
No tienes permisos para la configuración del proyecto en la red de VPC con intercambio de tráfico. Las pruebas de conectividad solo pueden realizar un seguimiento de las configuraciones en el proyecto de la red principal. El análisis de configuración muestra el resultado Es posible que se haya reenviado el paquete. Este resultado indica que un paquete dejará la red y se enviará a una red a la que no tienes acceso. En este caso, el paquete se reenvió a una puerta de enlace de red con intercambio de tráfico. En la respuesta de la API, este estado corresponde a un Forward.

La siguiente ruta de seguimiento muestra esta falla para las redes de VPC con intercambio de tráfico.

Seguimiento de VM a VM mediante una red de VPC con intercambio de tráfico inaccesible en un proyecto diferente
Seguimiento de VM a VM mediante una red de VPC con intercambio de tráfico inaccesible en un proyecto diferente

Prueba servicios administrados por Google

Puedes obtener un análisis de configuración de pruebas de conectividad en las rutas hacia y desde los servicios administrados por Google, como las instancias principales del clúster de Google Kubernetes Engine (GKE) o las instancias de Cloud SQL. Aunque no tienes permiso para acceder al proyecto de Google en el que se encuentran estos recursos, las pruebas de conectividad aún pueden analizar la configuración de la red de VPC del proyecto y proporcionar un resultado de accesibilidad general. Las pruebas de conectividad no proporcionan detalles de configuración del análisis dentro del proyecto de Google.

Según la configuración predeterminada, las pruebas de conectividad intentan ejecutar una prueba mediante la dirección IP privada del extremo del servicio administrado por Google y la conexión de intercambio de tráfico entre redes de VPC entre tu red y la red de Google. Si el extremo no tiene una dirección IP privada, las pruebas de conectividad usan la dirección IP pública. Las pruebas de conectividad analizan si el paquete puede alcanzar el extremo, lo que incluye analizar la configuración en la red de VPC de Google del extremo. Si las pruebas de conectividad detectan problemas de configuración en el interior de tu proyecto, su análisis se detiene antes de llegar a la red de Google.

En el siguiente diagrama, se muestra la ruta de seguimiento cuando se prueba la conectividad con los servicios administrados por Google, en el que se usa una prueba de nodo a instancia principal de GKE como ejemplo:

Seguimiento del nodo de GKE de origen a la instancia principal de GKE de destino
Seguimiento del nodo de GKE de origen a la instancia principal de GKE de destino

Cloud SQL a una VM

En esta sección, se describe una prueba de ejemplo de una instancia de Cloud SQL a una VM.

Entradas de muestra

En la siguiente tabla, se muestran valores de entrada de ejemplo para una prueba desde una instancia de Cloud SQL. Para ver el resultado de una prueba exitosa, avanza a la siguiente sección.

Parámetro de datos Valor de entrada
Protocolo TCP
Instancia de Cloud SQL de origen instance-1
Proyecto de origen my-project
VM de destino vm-1
Puerto de destino 80

Una prueba exitosa

En esta sección, se proporciona un resultado de ejemplo de una prueba exitosa desde una instancia de Cloud SQL.

Console

En la siguiente captura de pantalla de Cloud Console, se muestra un seguimiento de una instancia de Cloud SQL que indica un resultado general de Reachable.

Este resultado muestra que las pruebas de conectividad validan la conectividad de red de la instancia de Cloud SQL de origen a la VM de destino. Esto incluye analizar la configuración dentro del proyecto de Google en el que se ejecuta la instancia de Cloud SQL. El seguimiento no proporciona detalles de los recursos en el proyecto de Google porque no tienes permiso para verlos.

Captura de pantalla de Cloud Console para el seguimiento de Cloud SQL a la VM.
Captura de pantalla de Cloud Console para el seguimiento de la instancia Cloud SQL a la VM

Nodo de GKE para la instancia principal del clúster de GKE

En esta sección, se describe una prueba de ejemplo de un nodo de Google Kubernetes Engine (GKE) a una instancia principal del clúster de GKE.

Muestra de entradas de prueba

En la siguiente tabla, se muestran valores de entrada de ejemplo para una prueba en una instancia principal de GKE. Para ver el resultado de una prueba exitosa, avanza a la siguiente sección.

Parámetro de datos Valor de entrada
Protocolo TCP
Nodo de GKE de origen gke-cluster-1-node-1
Proyecto de origen my-project
Instancia principal del clúster de GKE de destino projects/myproject/locations/us-central1/clusters/cluster-1
Puerto de destino 443

Una prueba exitosa

En esta sección, se proporciona un resultado de ejemplo de una prueba exitosa a una instancia principal de GKE.

Console

En la siguiente captura de pantalla de Cloud Console, se muestra un seguimiento de una instancia principal de GKE de destino que indica un resultado general de Reachable.

Este resultado muestra que las pruebas de conectividad validaron la conectividad de red del nodo de GKE de origen a la instancia principal de GKE de destino. Esto incluye analizar la configuración de los recursos dentro del proyecto de Google en el que se ejecuta la instancia principal. El seguimiento no proporciona detalles de los recursos en el proyecto de Google porque no tienes permiso para verlos.

Captura de pantalla de Cloud Console para el seguimiento del nodo a la instancia principal de GKE.
Captura de pantalla de Cloud Console para el seguimiento del nodo a la instancia principal de GKE

Nodo de GKE para una instancia principal de GKE a través de una dirección IP pública

En la siguiente tabla, se muestran valores de entrada de ejemplo para una prueba en una instancia principal de GKE a través de una dirección IP pública. Para ver el resultado de una prueba exitosa, avanza a la siguiente sección.

Muestra de entradas de prueba

Parámetro de datos Valor de entrada
Protocolo TCP
Nodo de GKE de origen gke-cluster-1-node-1
Proyecto de origen my-project
Dirección IP de destino 104.1.1.1
Puerto de destino 443

Una prueba exitosa

En esta sección, se describe un ejemplo de una prueba exitosa para una instancia principal de GKE a través de una dirección IP pública.

Console

En la siguiente captura de pantalla de Cloud Console, se muestra un seguimiento de la dirección IP pública de una instancia principal de GKE que indica un resultado general de Reachable.

Este resultado muestra que las pruebas de conectividad validaron la conectividad de red del nodo de GKE de origen a la red en la que se ejecuta la instancia principal de GKE, pero no a la instancia principal de GKE. Cuando se realizan pruebas a través de una dirección IP pública, las pruebas de conectividad no analizan la configuración de los recursos dentro del proyecto de Google en el que se ejecuta la instancia principal.

Captura de pantalla de Cloud Console para el seguimiento de nodo a instancia principal de GKE a través de una dirección IP pública.
Captura de pantalla de Cloud Console para el seguimiento de nodo a instancia principal de GKE a través de una dirección IP pública

Fallas de prueba de servicios administrados por Google

Cuando se prueban los servicios administrados por Google, la prueba puede fallar con un mensaje de error que indica que el paquete se descartó dentro del servicio (por ejemplo, DROPPED_INSIDE_GKE_SERVICE o DROPPED_INSIDE_CLOUD_SQL_SERVICE). Este mensaje puede indicar un problema de configuración en el proyecto de Google que aloja el servicio en los siguientes casos:

  • Probaste la conectividad entre una instancia principal de GKE y un nodo de GKE en el mismo clúster (en cualquier dirección).
  • Probaste la conectividad de tu red de VPC a una instancia de Cloud SQL conectada a tu red, en la que el origen y el destino están en la misma región.

Si recibes el mensaje de error mencionados en uno de los casos mencionados, comunícate con el equipo de asistencia. De lo contrario, el mensaje de error podría indicar una entrada no válida. Confirma que estás realizando pruebas en o desde un extremo que existe y que esperas acceder al recurso administrado en el proyecto de Google. Por ejemplo, si realizas pruebas desde un nodo de GKE en una instancia principal de GKE, confirma que el nodo existe y se espera que tenga conectividad con la instancia principal.

Entradas de prueba de muestra: VM para una instancia de Cloud SQL en una región diferente

En la siguiente tabla, se muestran valores de entrada de ejemplo para una prueba de una VM en una instancia de Cloud SQL, en la que la VM se encuentra en una región diferente a la de la instancia de Cloud SQL. Para ver el resultado de la prueba con errores, avanza a la siguiente sección.

Parámetro de datos Valor de entrada
Protocolo TCP
VM de origen instance-1
Esta VM está en una región diferente a la de la instancia de Cloud SQL.
Proyecto de origen my-project
Instancia de Cloud SQL de destino vm-1
Puerto de destino 5432

Una prueba con errores

en esta sección, se describe un ejemplo de una prueba con errores en una instancia de Cloud SQL.

Console

En la siguiente captura de pantalla de Cloud Console, se muestra un seguimiento de una instancia de Cloud SQL de destino que indica un resultado general de Unreachable.

Captura de pantalla de Cloud Console para el seguimiento de una VM con errores en Cloud SQL.
Captura de pantalla de Cloud Console para el seguimiento de una VM con errores en Cloud SQL

Prueba desde una red de VPC a una red que no sea de Google Cloud

Puedes usar el análisis de configuración de pruebas de conectividad para probar la conectividad desde tu red de VPC hasta una red que no sea de Google Cloud a través de Cloud VPN o Cloud Interconnect. Por lo general, una red que no es de Google Cloud es la red local o la red de otro proveedor de servicios en la nube.

El análisis de configuración evalúa la ruta de acceso de la red solo hasta la dirección IP externa del router o la puerta de enlace de VPN en una red de intercambio de tráfico.

En el siguiente ejemplo, se muestra un seguimiento de VM1 en una red de VPC, en un túnel VPN clásico que usa el enrutamiento estático, a VM2 en una red local.

Seguimiento de paquetes a través de un túnel de Cloud VPN mediante rutas estáticas
Seguimiento de paquetes a través de un túnel de Cloud VPN mediante rutas estáticas

Si hay una ruta estática o dinámica que coincide para la dirección IP de destino en una red de intercambio de tráfico, el análisis de configuración coincide con la ruta y la verifica en función de la prioridad de la ruta.

Hay una ruta estática predeterminada para todos los destinos con el siguiente salto como la puerta de enlace de Internet. Las pruebas de conectividad pueden coincidir con esta ruta predeterminada, a menos que la quites o la modifiques.

Si la ruta estática predeterminada no existe y no hay otras rutas válidas para el destino, el seguimiento muestra un estado final de Drop.

Ruta de seguimiento a una red que no es de Google Cloud mediante el uso del enrutamiento estático
Ruta de seguimiento a una red que no es de Google Cloud mediante el uso del enrutamiento estático


Ruta de seguimiento a una red que no es de Google Cloud mediante el uso del enrutamiento dinámico
Ruta de seguimiento a una red que no es de Google Cloud mediante el uso del enrutamiento dinámico

Prueba desde una red que no sea de Google a una red de VPC

El análisis de configuración verifica que tu red de VPC pueda recibir un paquete entrante de tu red local después de que ese paquete pueda llegar a tu red de VPC. El análisis también verifica que es probable que la configuración de la red de VPC permita la entrega de este paquete al destino previsto. El análisis de configuración muestra que Es posible que se haya reenviado el paquete (en la respuesta de la API, el estado final es Forward). Se considera que se puede acceder al destino.

Cuando tu red de VPC intercambia tráfico con tu red local a través de Cloud Router, la red de VPC recibe una o más rutas dinámicas desde tu red local con intercambio de tráfico. Al mismo tiempo, la red de VPC anuncia sus propias rutas a tu red local con intercambio de tráfico.

Dado que las pruebas de conectividad no tienen acceso a tu configuración de red local, no pueden verificar la configuración de las rutas y las reglas de firewall correctas en tu router local. Por lo tanto, el tráfico de la red local a tu red de VPC siempre se considera válido a través del análisis de configuración de las pruebas de conectividad.

Sin embargo, las pruebas de conectividad pueden evaluar si la configuración de VPC permitiría la entrega de un paquete a un destino en Google Cloud. Para evaluar la accesibilidad, se evalúan los siguientes recursos de Google Cloud:

  • Las reglas de firewall de entrada de la red de VPC
  • La ruta anunciada para las direcciones IP en tu red de VPC que Cloud Router anuncia en tu red local (de intercambio de tráfico)

Muestra de entradas de prueba

En la siguiente tabla, se muestran valores de entrada de ejemplo para un balanceador de cargas de prueba de Google Cloud descrito en la sección anterior. Continúa con la siguiente sección para ver el resultado de una prueba correcta.

Parámetro de datos Valor de entrada
Protocolo TCP
Dirección IP local de muestra 10.0.29.2
Casilla de verificación Esta es una dirección IP que se usa en Google Cloud. Desmarca esta casilla de verificación cuando especifiques la dirección de origen de una IP local.

Una prueba exitosa de una red local

En esta sección, se describe un ejemplo de una prueba exitosa de una red local a una red de VPC.

Console

En el siguiente resultado de prueba, se evalúa la conectividad a través de Cloud VPN de la dirección IP local a una instancia de VM, y también se evalúa la sesión, las rutas y las reglas de firewall del protocolo de Puerta de Enlace Fronteriza (BGP).

Resultado de ejemplo para una prueba exitosa de una ubicación local en Google Cloud.
Resultado de ejemplo para una prueba exitosa de una ubicación local en Google Cloud

Realiza pruebas entre dos redes ajenas a Google Cloud

Puedes usar el análisis de configuración de pruebas de conectividad para evaluar la accesibilidad entre dos redes ajenas a Google Cloud que están conectadas a través de Network ConnectivityManager. En este contexto, una red ajena a Google Cloud suele ser el centro de datos local o una sucursal.

Debido a que las pruebas de conectividad no tienen acceso a la configuración de tu red local, no puede verificar la configuración de las rutas y reglas de firewall en tu router local. Por lo tanto, el análisis de configuración de pruebas de conectividad siempre considera válido el tráfico de la red local a la red de VPC, y solo se verifican los parámetros de configuración dentro de Google Cloud.

El análisis de configuración aprende los rangos de red local de los Cloud Routers asociados a los radios del Network Connectivity Center. Puedes identificar los problemas de configuración dentro de tu red de VPC que pueden afectar la conectividad entre las redes locales.

Todos los tipos de radio del Centro de conectividad de red usan Cloud Routers para intercambiar rutas a través de sesiones de BGP. Por ejemplo:

  • El dispositivo del router usa el mismo nivel: cuando las instancias de Cloud Router y el dispositivo de router se encuentran en la misma región, intercambian rutas entre sí.
  • Cloud VPN y radios de adjuntos de VLAN: Cloud Routers intercambian rutas de BGP con routers en la red local.

Para obtener más información sobre Network Connectivity Center, consulta la descripción general de Network Connectivity Center.

Pruebas entre dos redes que no son de Google Cloud a través del dispositivo de router

En el siguiente ejemplo, las pruebas de conectividad rastrean un paquete simulado de una red local a otra. El paquete ingresa a la red de VPC del radio del dispositivo del router conectado a la primera red local. A partir de este punto, sigue una ruta dinámica anunciada por el Cloud Router asociado al dispositivo de router que está conectado a la segunda red local. El paquete llega a la red local desde la segunda instancia de dispositivo de router.

Entradas de muestra

En la siguiente tabla, se muestran valores de entrada de ejemplo para una prueba desde una dirección IP en la red local. Para ver el resultado de una prueba exitosa, avanza a la siguiente sección.

Parámetro de datos Valor de entrada
Protocolo TCP
Dirección IP del extremo de origen 192.168.1.1
Casilla de verificación Esta es una dirección IP que se usa en Google Cloud. Desmarca esta casilla de verificación cuando especifiques la dirección de origen de una IP local.
Dirección IP del extremo de destino 172.16.1.1
Casilla de verificación Esta es una dirección IP que se usa en Google Cloud. Desmarca esta casilla de verificación cuando especifiques la dirección de destino de una IP local.

Una prueba exitosa de una red local a otra red local

En esta sección, se describe un ejemplo de una prueba que se realizó correctamente de una red local a otra a través de los radios del dispositivo Router.

Console

El siguiente resultado de prueba evalúa la conectividad desde una red local a través de dos instancias de dispositivo del router hasta otra red local. También evalúa la sesión de BGP, las rutas y las reglas de firewall de VPC.

Ejemplo de resultado para una prueba correcta desde una ubicación local, en forma local.
Ejemplo de resultado para una prueba exitosa de un entorno local a uno local

Realiza pruebas entre dos redes ajenas a Google Cloud mediante Cloud VPN y Cloud Interconnect

En el siguiente ejemplo, las pruebas de conectividad rastrean un paquete simulado de una red local a otra. El paquete ingresa a la red de VPC a través de la puerta de enlace VPN. El paquete llega a la otra red local a través de una conexión de interconexión.

Entradas de muestra

En la siguiente tabla, se muestran valores de entrada de ejemplo para una prueba desde una dirección IP en la red local. Para ver el resultado de una prueba exitosa, avanza a la siguiente sección.

Parámetro de datos Valor de entrada
Protocolo TCP
Dirección IP del extremo de origen 10.0.0.1
Casilla de verificación Esta es una dirección IP que se usa en Google Cloud. Desmarca esta casilla de verificación cuando especifiques la dirección de origen de una IP local.
Dirección IP del extremo de destino 10.240.0.1
Casilla de verificación Esta es una dirección IP que se usa en Google Cloud. Desmarca esta casilla de verificación cuando especifiques la dirección de destino de una IP local.
Puerto de destino 80

Ejemplo de prueba de una red local a otra red local

En esta sección, se describe un ejemplo de una prueba desde una red local hasta otra red local mediante VPN y radios del adjunto de VLAN.

Console

El siguiente resultado de prueba evalúa la conectividad desde una red local a través de una VPN y radios de adjuntos de VLAN a otra red local.

Resultado de ejemplo para una prueba exitosa de un entorno local a uno local.
Resultado de ejemplo para una prueba exitosa de un entorno local a uno local a través de VPN y radios de adjuntos de VLAN

Prueba de balanceadores de cargas de Google Cloud

El análisis de configuración de pruebas de conectividad admite el seguimiento de paquetes simulados en todos los tipos de balanceadores de cargas de Google Cloud.

La ruta de seguimiento de un balanceador de cargas HTTP(S) externo también se aplica a un balanceador de cargas de proxy TCP y a un balanceador de cargas de proxy SSL. Para obtener más información, consulta la descripción general de Cloud Load Balancing.

En el siguiente ejemplo, las pruebas de conectividad realizan un seguimiento de un paquete simulado de un host externo en una VIP de un balanceador de cargas HTTP(S) externo. La conexión TCP del host externo finaliza en el proxy para el balanceador de cargas HTTP(S) externo. Luego, el balanceador de cargas HTTP(S) externo inicia una nueva conexión TCP a una VM que funciona como backend del balanceador de cargas.

Una ruta de seguimiento típica a un balanceador de cargas HTTP(S) externo con leyenda del diagrama.
Una ruta de seguimiento típica a un balanceador de cargas HTTP(S) externo

En la siguiente ruta de seguimiento, el análisis de configuración de pruebas de conectividad proporciona tres seguimientos, uno para cada ruta posible a los tres backends del balanceador de cargas. Las pruebas de conectividad hacen esto porque validan solo las configuraciones, no el plano de datos en vivo.

Seguimiento de paquetes para un balanceador de cargas HTTP(S) externo
Seguimiento de paquetes para un balanceador de cargas HTTP(S) externo(consulta la leyenda del diagrama)

Muestra de entradas de prueba

En la siguiente tabla, se muestran valores de entrada de ejemplo para una prueba en el balanceador de cargas HTTP(S) externo descrito en la sección anterior. Para ver el resultado de una prueba exitosa, avanza a la siguiente sección.

Parámetro de datos Valor de entrada
Protocolo de destino TCP
Puerto de destino 80
Dirección IP de origen externa de muestra (no se muestra) 62.35.1.1
Dirección IP externa del balanceador de cargas 203.0.113.99
Proyecto de destino myproject

Una prueba exitosa para un balanceador de cargas

En esta sección, se describe un ejemplo de una prueba exitosa del balanceador de cargas HTTP(S) externo descrito antes.

En el plano de datos real, el algoritmo de balanceo de cargas elige una instancia de VM para cada conexión de backend. Debido a que hay tres backends del balanceador de cargas en este ejemplo, el menú Selección del seguimiento en la pantalla Resultados te permite seleccionar el seguimiento que quieres ver.

Console

El siguiente resultado de prueba exitosa valida que todos los recursos de Google Cloud del balanceador de cargas HTTP(S) externo a continuación estén configurados de forma correcta.

  • La regla de reenvío
  • Los backends del balanceador de cargas, incluida la capacidad de que el balanceador de cargas envíe correctamente las verificaciones de estado a esos backends
  • La conexión del proxy
  • Reglas de firewall de VPC

Este resultado muestra que un paquete simulado desde una dirección IP externa podría alcanzar con éxito las instancias de VM de backend.

Para obtener un ejemplo detallado de un seguimiento en los tres backends, consulta Detecta configuraciones no válidas o incoherentes.

Resultado de ejemplo de una prueba exitosa de un balanceador de cargas HTTP(S) externo
Resultado de ejemplo de una prueba exitosa de un balanceador de cargas HTTP(S) externo

Si no tienes permisos para revisar los recursos de Google Cloud en la ruta de la red del balanceador de cargas HTTP(S) externo, aún puedes ver los resultados en Cloud Console, incluidos los resultados exitosos. Sin embargo, la tarjeta de cada recurso probado dice "Sin permiso para ver el recurso en PROJECT_NAME".

Una prueba que muestra que falta una regla de firewall para una comprobación de estado

Un seguimiento del balanceador de cargas verifica muchas de las mismas opciones de configuración de los recursos de Google Cloud descritas antes. Sin embargo, si los siguientes recursos del balanceador de cargas están mal configurados, el análisis muestra el mensaje Es posible que se haya descartado el paquete (un estado final del seguimiento es Drop).

Console

En el siguiente resultado de prueba, se muestra que las reglas de firewall de entrada de la red de VPC no permiten una verificación de estado para los backends del balanceador de cargas, lo que hace que los backends no estén disponibles para el balanceador de cargas.

Resultado de ejemplo de una regla de firewall faltante
Resultado de ejemplo de una regla de firewall faltante

Además de las reglas de firewall de VPC no válidas, los siguientes problemas son errores de configuración comunes que las pruebas de conectividad detectan para los balanceadores de cargas de Google Cloud.

Para corregir estos problemas, utiliza las soluciones que se describen en la siguiente tabla.

Problema de configuración Solución
Los parámetros de entrada no coinciden con el protocolo o el puerto que definiste en la regla de reenvío del balanceador de cargas. Antes de ejecutar una prueba, cambia el parámetro de entrada para que coincida con el protocolo o el puerto que definiste en la regla de reenvío.
La regla de reenvío del balanceador de cargas no tiene backends configurados. Antes de ejecutar una prueba, configura los backends del balanceador de cargas.
El balanceador de cargas tiene configuraciones incoherentes o no válidas. Antes de ejecutar una prueba, corrige las configuraciones no válidas o incoherentes.
El tráfico no puede llegar a un balanceador de cargas TCP/UDP interno que tenga una región que no coincida porque el balanceador de cargas TCP/UDP interno es un servicio regional. Antes de ejecutar una prueba, configura los componentes del balanceador de cargas para que se encuentren en la misma región.

¿Qué sigue?