Las pruebas de conectividad pueden descartar un paquete de prueba por cualquiera de los siguientes motivos.
Para ver una lista completa de los posibles motivos, consulta Estados del análisis de configuración.
Dirección IP extranjera no permitida
El paquete se ha descartado porque una instancia de Compute Engine solo puede enviar o recibir paquetes con una dirección IP externa cuando el reenvío de IP está habilitado.
Causa probable
La instancia de VM no tiene habilitado el reenvío de IP, pero la dirección IP de origen o de destino del paquete que pasa por ella no coincide con las direcciones IP de la instancia. Esto puede ocurrir, por ejemplo, cuando el paquete se entrega a la instancia mediante una ruta estática con la instancia de VM como siguiente salto.
Recomendaciones
Crea una instancia de Compute Engine con el reenvío de IP habilitado o define el atributo correspondiente en la instancia que ya tengas. Para obtener más información, consulta Habilitar el reenvío de IP para instancias.
Se ha eliminado por una regla de cortafuegos
El paquete se puede eliminar por una regla de cortafuegos, excepto cuando se permite debido al seguimiento de conexiones.
Causa probable
Es posible que las pruebas de conectividad denieguen un paquete de prueba porque coincida con una regla de cortafuegos o una regla de política de cortafuegos que lo bloquee. Sin embargo, es posible que el plano de datos real permita que el paquete pase debido al seguimiento de conexiones en la regla de cortafuegos. El seguimiento de conexiones permite que los paquetes de una conexión ya establecida vuelvan a pesar de la regla de cortafuegos.
Todas las redes de VPC tienen dos reglas de cortafuegos implícitas que permiten el tráfico saliente a cualquier destino y bloquean el tráfico entrante procedente de cualquier origen. También puede tener una regla de cortafuegos de salida de denegación de mayor prioridad.
Para que la conectividad se realice correctamente, necesitas una regla de cortafuegos de salida en el origen que permita el acceso al endpoint de destino y una regla de cortafuegos de entrada en el destino que permita esta conexión.
Las reglas de cortafuegos de VPC tienen estado. Si el punto final de destino especificado suele ser el lado que inicia la comunicación, el tráfico de respuesta se permite automáticamente con el seguimiento de la conexión y no es necesaria ninguna regla de firewall de entrada.
Recomendaciones
Elimina la regla de denegación o crea una regla de permiso basada en los detalles de los resultados de las pruebas de conectividad. Para obtener más información, consulta Políticas de cortafuegos y Usar reglas de cortafuegos de VPC. Si la regla de la política de cortafuegos que ha denegado el tráfico tiene un tipo de red especificado, consulta las reglas de la política de cortafuegos para determinar si la regla se aplica a tu caso práctico.
Se ha eliminado porque no hay ninguna ruta que coincida
El paquete se ha descartado porque no hay ninguna ruta que coincida.
Causa probable
No hay ninguna ruta activa que coincida con los atributos del paquete (como una dirección IP de destino) en la red y la región del paquete.
Recomendaciones
Verifica la lista de rutas efectivas en la consola Google Cloud . Si acabas de crear una ruta, ten en cuenta que puede que las pruebas de conectividad tarden un poco en recibir una actualización de la configuración e incorporarla al análisis.
Si intentas acceder al endpoint de destino mediante su dirección IP interna, asegúrate de que las redes de origen y de destino estén conectadas (por ejemplo, mediante el emparejamiento entre redes de VPC, Network Connectivity Center o una solución de conectividad híbrida, como Cloud VPN).
Ten en cuenta que el emparejamiento transitivo de VPCs no es compatible. Puedes conectar las redes de origen y de destino directamente o mediante una solución de conectividad híbrida.
Si intentas acceder al endpoint de destino a través de Internet, asegúrate de que tienes una ruta para la dirección IP de destino con la pasarela de Internet del siguiente salto.
Si el paquete pasa por el grupo de extremos de red de conectividad híbrida, ten en cuenta los requisitos adicionales para la aplicabilidad de las rutas. Es posible que algunas rutas que veas en la tabla de la vista de ruta no estén disponibles para el tráfico de NEGs híbridos.
Para obtener más información, consulta Rutas y Usar rutas.
El paquete se ha enviado a una red incorrecta
El paquete se ha enviado a una red incorrecta por equivocación. Por ejemplo, ejecutas una prueba desde una instancia de Compute Engine en la red network-1 a la instancia de Compute Engine en la red network-2, pero el paquete se envía a la red network-3.
Causa probable
La red network-1 tiene una ruta con un intervalo de destino que incluye la dirección IP de la instancia de destino con el siguiente salto en otra red (network-3 en el ejemplo anterior).
Recomendaciones
Verifica la lista de rutas efectivas y la lista de rutas aplicables a la instancia de origen en la consola de Google Cloud . Para obtener más información sobre cómo crear rutas y su aplicabilidad, consulta Rutas y Usar rutas.
No se ha resuelto la dirección IP del siguiente salto de la ruta
El paquete se envía a un destino mediante una ruta no válida con la dirección IP del siguiente salto no asignada a ningún recurso.
Causa probable
Si se trata de una ruta con next-hop-address, la dirección del siguiente salto debe ser una dirección IPv4 interna principal o una dirección IPv6 de la instancia de Compute Engine en la red de VPC de la ruta. No se admiten direcciones de redes emparejadas.
Si se trata de una ruta con next-hop-ilb, la dirección del siguiente salto debe ser una dirección del balanceador de carga de red de paso a través interno (no se admiten las reglas de reenvío que usan otros balanceadores de carga, el reenvío de protocolos ni los endpoints de Private Service Connect). La dirección IP debe asignarse a un recurso de la red de VPC de la ruta o a una red conectada a ella mediante el emparejamiento entre redes de VPC.
Recomendaciones
Verifica que la dirección IP del siguiente salto pertenezca a un recurso admitido. Para obtener más información, consulta las secciones Consideraciones sobre las instancias de próximo salto y Consideraciones sobre los próximos saltos del balanceador de carga de red de paso a través interno.
La instancia de siguiente salto de la ruta tiene una NIC en la red incorrecta
El paquete se envía a un destino mediante una ruta no válida con la instancia de Compute Engine del siguiente salto que no tiene un controlador de interfaz de red (NIC) en la red de la ruta.
Causa probable
La instancia de Compute Engine que se usa como siguiente salto de una ruta debe tener una interfaz de red en la red de la ruta (no en una red de VPC emparejada).
Recomendaciones
Verifica que la instancia de Compute Engine del siguiente salto tenga una NIC en la red de la ruta. Para obtener más información, consulta Consideraciones sobre las instancias de salto siguiente.
La dirección del siguiente salto de la ruta no es la dirección IP principal de una VM
El paquete se envía a un destino mediante una ruta no válida en la que la dirección IP del siguiente salto (next-hop-address) no es una dirección IP principal de la instancia de Compute Engine.
Causa probable
La dirección IP del siguiente salto de la ruta (next-hop-address) debe ser una dirección IPv4 interna principal de la instancia de Compute Engine.
No se admiten intervalos de direcciones IP de alias.
Recomendaciones
Verifica que la dirección IP del siguiente salto sea una dirección IPv4 interna principal de la instancia de Compute Engine. Para obtener más información, consulta Consideraciones sobre las instancias de salto siguiente.
El tipo de regla de reenvío del siguiente salto de la ruta no es válido
El paquete se envía a un destino mediante una ruta no válida, ya que la regla de reenvío del siguiente salto (next-hop-ilb) no es una regla de reenvío del balanceador de carga de red interno de tipo pasarela.
Causa probable
La regla de reenvío del siguiente salto de la ruta debe ser una regla de reenvío del balanceador de carga de red de paso a través interno. Para obtener más información, consulta Consideraciones sobre los saltos siguientes del balanceador de carga de red de paso a través interno.
Recomendaciones
Crea una ruta que tenga como destino una regla de reenvío admitida en lugar de la ruta no válida.
Tráfico privado a Internet
Se ha enviado un paquete con una dirección de destino interna a una pasarela de Internet.
Causa probable
La dirección IP de destino del paquete es una dirección IP privada, a la que no se puede acceder a través de Internet. Sin embargo, el paquete sale de la instancia de Compute Engine de origen y coincide con una ruta con la pasarela de Internet del siguiente salto.
Recomendaciones
Si quieres acceder al destino a través de Internet, asegúrate de que la instancia de Compute Engine de origen tenga conectividad a Internet (por ejemplo, que tenga una dirección IP externa o que use Cloud NAT) y usa la dirección IP externa del endpoint de destino en la prueba.
Si quieres acceder al destino a través de su dirección IP interna, debes establecer la conectividad (crear rutas) entre las redes de origen y de destino. Puedes hacerlo de cualquiera de las siguientes formas:
- Si tu endpoint de destino está en una red local, usa una solución de Network Connectivity Center o una solución de conectividad híbrida, como Cloud VPN o Cloud Interconnect.
- Si tu endpoint de destino está en Google Cloud:
- Configura el emparejamiento entre redes de VPC entre redes de VPC.
- Configura Cloud VPN entre redes de VPC.
- Configura la conectividad de red mediante los radios de VPC de Network Connectivity Center.
Si ya tienes una conexión a la red de destino:
- La red del endpoint de origen no tiene una ruta a través de esta conexión o usa la ruta predeterminada que pasa por la pasarela de Internet. Verifica la lista de rutas efectivas y la lista de rutas aplicables a la instancia de origen en la consola de Google Cloud . Para obtener más información sobre la creación de rutas y su aplicabilidad, consulta Rutas y Usar rutas.
Si estás probando la conectividad a una red local desde una red emparejada, consulta este ejemplo para ver cómo se hace la publicidad personalizada, el modo de enrutamiento de red y el intercambio de rutas personalizadas.
No se admite el emparejamiento transitivo entre redes de VPC. Puedes usar una VPN o el peering para estas dos redes VPC.
No se permite el acceso privado de Google
Una instancia de Compute Engine que solo tiene una dirección IP interna intenta acceder a la dirección IP externa de las APIs y los servicios de Google, pero Acceso privado de Google no está habilitado en la subred de la instancia.
Recomendaciones
Puedes permitir que la instancia de VM de Compute Engine acceda a la dirección IP externa de las APIs y los servicios de Google de cualquiera de las siguientes formas:
- Habilita Acceso privado de Google en la subred de la instancia.
- Asigna una dirección IP externa a la interfaz de red de Compute Engine.
- Habilita Cloud NAT en la subred de la instancia de VM.
No se admite el acceso privado a Google a través de un túnel VPN
Un endpoint de origen con una dirección IP interna intenta acceder a la dirección IP externa de las APIs y los servicios de Google a través del túnel VPN a otra red, pero es necesario habilitar Acceso privado de Google en la red del endpoint de origen.
Causa probable
El paquete del endpoint de origen a la dirección IP externa de las APIs y los servicios de Google se enruta a través del túnel de Cloud VPN, pero esta configuración no se admite.
Recomendaciones
Si el endpoint de origen es un endpoint (como una instancia de VM de Compute Engine), considera habilitar el acceso privado a Google en su subred de origen. Google Cloud
Si el endpoint de origen es un endpoint on-premise, consulta las instrucciones detalladas en Acceso privado de Google para hosts on-premise.
Discrepancia en la regla de reenvío
El protocolo y los puertos de la regla de reenvío no coinciden con el encabezado del paquete.
Causa probable
El paquete se envía mediante un protocolo que no es compatible con la regla de reenvío o se envía a un puerto de destino que no coincide con los puertos compatibles con la regla de reenvío.
Recomendaciones
Confirme el protocolo y los puertos de la regla de reenvío de destino.
Discordancia con la región de la regla de reenvío
La regla de reenvío no tiene habilitado el acceso global y su región no coincide con la del paquete.
Causa probable
En función del balanceador de carga y de su nivel, una regla de reenvío puede ser global o regional. Para obtener más información, consulta la tabla de tipos de balanceadores de carga.
Si la regla de reenvío es regional, el cliente (por ejemplo, la VM o el conector de VPC) debe estar en la misma región que el balanceador de carga.
Recomendaciones
Si te conectas al balanceador de carga desde un Google Cloud endpoint, como una instancia de VM de Compute Engine, asegúrate de que esté ubicado en la misma región que la regla de reenvío.
Cuando te conectes desde una red on-premise, asegúrate de que el cliente acceda al balanceador de carga a través de túneles de Cloud VPN o de adjuntos de VLAN que estén en la misma región que el balanceador de carga. Para obtener más información, consulta el artículo Balanceadores de carga de aplicación internos y redes conectadas.
Puedes habilitar el acceso global en los balanceadores de carga de aplicaciones internos y en los balanceadores de carga de red con proxy internos regionales para acceder a los clientes de cualquier región. De forma predeterminada, los clientes de estos balanceadores de carga deben estar en la misma región que el balanceador de carga. Para obtener más información, consulta los artículos Habilitar el acceso global a los balanceadores de carga de aplicación internos y Habilitar el acceso global a los balanceadores de carga de red con proxy internos regionales.
El cortafuegos bloquea la comprobación del estado del backend del balanceador de carga
Los cortafuegos bloquean las comprobaciones del estado en los backends y provocan que estos no estén disponibles para el tráfico del balanceador de carga.
Causa probable
Para que las comprobaciones del estado funcionen, debes crear reglas de cortafuegos que permitan que el tráfico de entrada de los Google Cloud probers llegue a tus backends. De lo contrario, los backends se consideran en mal estado.
Recomendaciones
Crea reglas de cortafuegos de permiso de entrada según la tabla Intervalos de IPs de sondeo y reglas de cortafuegos. Para obtener más información, consulta Reglas de cortafuegos obligatorias.
No hay ninguna dirección externa disponible
Una instancia de VM que solo tiene una dirección IP interna ha intentado acceder a hosts externos a través de una ruta cuyo siguiente salto es la pasarela de Internet predeterminada. Se espera cuando Cloud NAT no está habilitado en la subred o cuando no hay otra ruta predeterminada que use otro tipo de salto siguiente (como una VM proxy).
Causa probable
Una instancia que solo tiene una dirección IP interna ha intentado acceder a un host externo, pero no tenía una dirección IP externa o Cloud NAT no estaba habilitado en la subred.
Recomendaciones
Si quieres acceder a endpoints externos, puedes asignar una dirección IP externa a tu instancia. También puedes habilitar Cloud NAT en su subred, a menos que la conexión se realice a través de una instancia de proxy que dé acceso a Internet.
Regla de reenvío sin instancias
No se ha configurado ningún backend en la regla de reenvío.
Causa probable
La regla de reenvío a la que intenta acceder no tiene ningún backend configurado.
Recomendaciones
Comprueba la configuración del balanceador de carga y asegúrate de que el servicio de backend del balanceador de carga tiene backends configurados.
El tipo de tráfico está bloqueado
Este tipo de tráfico está bloqueado y no se puede configurar una regla de cortafuegos para habilitarlo. Para obtener más información, consulta Tráfico siempre bloqueado.
Causa probable
Este tipo de tráfico está bloqueado de forma predeterminada y no se puede habilitar creando reglas de cortafuegos. Estos son algunos de los casos más habituales:
- Enviar tráfico de salida a un destino externo con el puerto TCP 25 (SMTP). Para obtener más información, consulta Tráfico siempre bloqueado.
- Envío de tráfico a un puerto no admitido en una instancia de Cloud SQL. Por ejemplo, enviar tráfico al puerto TCP 3310 a una instancia de Cloud SQL de MySQL con el puerto 3306 abierto.
- Enviar tráfico de salida desde una versión del entorno estándar de App Engine, una función de Cloud Run o una revisión de Cloud Run que use un protocolo distinto de TCP o UDP.
Recomendaciones
Para el tráfico SMTP de salida (tráfico de salida a un destino externo con el puerto TCP 25), consulta el artículo Enviar correos desde una instancia.
En el caso del protocolo DHCP, incluidos los paquetes UDP IPv4 al puerto de destino 68 (respuestas DHCPv4) y los paquetes UDP IPv6 al puerto de destino 546 (respuestas DHCPv6), el tráfico DHCP solo se permite desde el servidor de metadatos (169.254.169.254).
En el caso de la conectividad de Cloud SQL, asegúrate de que el puerto utilizado sea el correcto.
Las etiquetas de red no son compatibles con la salida directa de VPC en las reglas de cortafuegos de entrada
El paquete se ha descartado porque la salida directa de VPC no admite etiquetas de red de origen en las reglas de firewall de entrada.
Causa probable
No se admite la coincidencia de reglas de cortafuegos de entrada por etiquetas de red de origen para las conexiones de Cloud Run a través de la salida directa de VPC. Para obtener más información, consulta Limitaciones.
Recomendaciones
Actualiza las reglas de tu cortafuegos para que usen intervalos de IP de origen en lugar de etiquetas de red de origen para que coincidan con el tráfico de las conexiones de Cloud Run a través de la salida de VPC directa.
El conector de Acceso a VPC sin servidor no está configurado
El paquete se ha descartado porque la versión del entorno estándar de App Engine, la función de Cloud Run o la revisión de Cloud Run no tienen configurado un conector de acceso a VPC sin servidor.
Causa probable
La dirección IP de destino es una dirección IP privada, a la que no se puede acceder a través de Internet. El paquete sale del origen, pero no hay ningún conector de acceso a VPC sin servidor configurado para la versión del entorno estándar de App Engine, la función de Cloud Run o la revisión de Cloud Run.
Recomendaciones
Si intentas acceder al endpoint de destino mediante su dirección IP privada, asegúrate de haber configurado un conector de acceso a VPC sin servidor para la versión del entorno estándar de App Engine, la función de Cloud Run o la revisión de Cloud Run.
El conector de Acceso a VPC sin servidor no está en ejecución
El paquete se ha descartado porque el conector de acceso a VPC sin servidor no está en ejecución.
Causa probable
El paquete se ha descartado porque todas las instancias del conector de Acceso a VPC sin servidor están detenidas.
Recomendaciones
Para ver una lista de los pasos que debes seguir para solucionar problemas, consulta Solución de problemas.
No se acepta la conexión de Private Service Connect
Se ha descartado el paquete porque no se ha aceptado la conexión de Private Service Connect.
Causa probable
El endpoint de Private Service Connect está en un proyecto que no tiene permiso para conectarse al servicio. Para obtener más información, consulta Ver detalles de un endpoint.
Recomendaciones
Asegúrate de que el punto final de Private Service Connect esté en un proyecto aprobado para conectarse al servicio gestionado.
Se accede al endpoint de Private Service Connect desde una red emparejada
El paquete se envía al endpoint de Private Service Connect de la red emparejada, pero esta configuración no se admite.
Recomendaciones
Google recomienda que cambies a una arquitectura de concentrador y radios que use Network Connectivity Center para habilitar la propagación de conexiones de Private Service Connect.
También puedes usar uno de los siguientes patrones de conectividad:
Si el productor de servicios lo admite, cambia a un patrón de conectividad de acceso multipunto.
Si el productor del servicio lo admite, configura un balanceador de carga de consumidor compatible con un backend de Private Service Connect.
Si necesitas más ayuda, ponte en contacto con el equipo de asistencia de tu productor de servicios o con tu Google Cloud representante.