Las pruebas de conectividad pueden descartar un paquete de prueba por cualquiera de los siguientes motivos.
Para obtener una lista completa de los motivos posibles, consulta Estados de análisis de configuración.
No se permiten las direcciones IP externas
El paquete se descarta porque una instancia de Compute Engine puede enviar o recibir paquetes con una dirección IP externa solo 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 lo atraviesa no coincide con las direcciones IP de la instancia. Esto puede ocurrir, por ejemplo, cuando el paquete se entrega a la instancia a través de una ruta estática con la instancia de VM como un siguiente salto.
Recomendaciones
Crea una instancia de Compute Engine con el reenvío de IP habilitado o configura el atributo correspondiente para la instancia existente. Si deseas obtener más información, consulta Habilita el reenvío de IP para las instancias.
Descartado debido a una regla de firewall
El paquete se puede descartar debido a una regla de firewall, excepto cuando se permite el paquete debido al seguimiento de la conexión.
Causa probable
Las pruebas de conectividad pueden rechazar un paquete de prueba porque el paquete coincide con una regla de firewall de bloqueo o una regla de política de firewall. Sin embargo, el plano de datos real puede permitir el paquete debido al seguimiento de conexiones de la regla de firewall. El seguimiento de conexión permite que los paquetes de una conexión existente se devuelvan a pesar de la regla de firewall.
Cada red de VPC tiene dos reglas de firewall implícitas que permiten el tráfico de salida a todas partes y bloquean el tráfico entrante desde todas partes. También es posible que tengas una regla de firewall de denegación de salida de mayor prioridad.
Para que la conectividad tenga éxito, necesitas una regla de firewall de salida en el origen que permita el acceso al extremo de destino y una regla de firewall de entrada en el destino para permitir esta conexión.
Las reglas de firewall de VPC son reglas con estado. Si el extremo de destino especificado suele ser el lado que inicia la comunicación, el tráfico de respuesta se permite de forma automática con el seguimiento de conexiones y no se necesita una regla de firewall de entrada.
Recomendaciones
Borra la regla de denegación o crea una regla de permiso según los detalles en los resultados de las pruebas de conectividad. Para obtener más información, consulta Políticas de firewall y Usa reglas de firewall de VPC.
Se descartó debido a que no hay una ruta que coincida
El paquete se descarta debido a que no hay rutas que coincidan.
Causa probable
No hay una ruta activa que coincida con los atributos del paquete (como una dirección IP de destino) en la región y la red del paquete.
Recomendaciones
Verifica la lista de rutas eficaces en la consola de Google Cloud. Si acabas de crear una ruta nueva, ten en cuenta que puede tomar algún tiempo para que las pruebas de conectividad reciban una actualización de configuración y la incorporen al análisis.
Si intentas acceder al extremo de destino con su dirección IP interna, asegúrate de que las redes de origen y de destino estén conectadas (por ejemplo, mediante el intercambio de tráfico entre redes de VPC, Network Connectivity Center o una solución de conectividad híbrida, como Cloud VPN).
Ten en cuenta que no se admite el intercambio de tráfico de VPC transitivo. Considera conectar las redes de origen y de destino directamente o mediante una solución de conectividad híbrida.
Si intentas acceder al extremo de destino a través de Internet, asegúrate de tener una ruta para la dirección IP de destino con la puerta de enlace de Internet de próximo 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 ves en la tabla de vista de ruta no estén disponibles para el tráfico desde los NEG híbridos.
Para obtener más información, consulta Rutas y Cómo usar las rutas.
El paquete se envió a una red equivocada
El paquete se envía a una red no deseada. Por ejemplo, ejecutas una prueba desde una instancia de Compute Engine en la red network-1 hasta 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 rango de destino que incluye la dirección IP de la instancia de destino con el siguiente salto en una red diferente (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 la creación y la applicability de rutas, consulta Rutas y Cómo usar las rutas.
La dirección IP del próximo salto de ruta no está resuelta
El paquete se envía a un destino mediante una ruta no válida con la dirección IP del próximo salto que no está asignada a ningún recurso.
Causa probable
Si se trata de una ruta con next-hop-address, la dirección del próximo 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 en redes con intercambio de tráfico.
Si se trata de una ruta con next-hop-ilb, la dirección del próximo salto debe ser una dirección del balanceador de cargas de red de transferencia interno (no se admiten las reglas de reenvío que usan otros balanceadores de cargas, el reenvío de protocolos ni los extremos de Private Service Connect). La dirección IP debe asignarse a un recurso en la red de VPC de la ruta o en una red conectada a ella con el intercambio de tráfico entre redes de VPC.
Recomendaciones
Verifica que la dirección IP del próximo salto pertenezca a un recurso compatible. Para obtener más información, consulta Consideraciones para instancias de próximo salto y Consideraciones para próximos saltos del balanceador de cargas de red de transferencia interna.
La instancia de próximo salto de ruta tiene una NIC en la red incorrecta
El paquete se envía a un destino mediante una ruta no válida, con el siguiente salto de la instancia de Compute Engine 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 próximo salto de ruta debe tener una NIC en la red de la ruta (no en una red de VPC con intercambio de tráfico).
Recomendaciones
Verifica que la instancia de Compute Engine de próximo salto tenga una NIC en la red de la ruta. Para obtener más información, consulta Consideraciones para instancias de próximo salto.
La dirección de próximo salto de la ruta no es una dirección IP principal de VM
El paquete se envía a un destino con una ruta no válida donde la dirección IP del próximo salto (next-hop-address) no es una dirección IP principal de la instancia de Compute Engine.
Causa probable
La dirección IP del próximo salto de la ruta (next-hop-address) debe ser una dirección IPv4 interna principal de la instancia de Compute Engine.
No se admiten los rangos de direcciones IP de alias.
Recomendaciones
Verifica que la dirección IP del próximo salto sea una dirección IPv4 interna principal de la instancia de Compute Engine. Para obtener más información, consulta Consideraciones para instancias de próximo salto.
El tipo de regla de reenvío del próximo salto de ruta no es válido
El paquete se envía a un destino mediante una ruta no válida, donde la regla de reenvío del próximo salto (next-hop-ilb) no es una regla de reenvío del balanceador de cargas de red de transferencia interno.
Causa probable
La regla de reenvío del próximo salto de la ruta debe ser una regla de reenvío del balanceador de cargas de red de transferencia interno. Para obtener más información, consulta Consideraciones para los próximos saltos del balanceador de cargas de red de transferencia interna.
Recomendaciones
Crea una ruta dirigida a una regla de reenvío compatible en lugar de una ruta no válida.
Tráfico privado a Internet
Se envió un paquete con una dirección de destino interna a una puerta de enlace 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 hace coincidir una ruta con la puerta de enlace de Internet del siguiente salto.
Recomendaciones
Si deseas acceder al destino a través de Internet, asegúrate de que la instancia de Compute Engine de origen tenga conexión a Internet (por ejemplo, tiene una dirección IP externa o usa Cloud NAT) y usa la dirección IP externa del extremo de destino en la prueba.
Si deseas acceder al destino a través de su dirección IP interna, debes establecer conectividad (crear rutas) entre las redes de origen y de destino. Puedes hacerlo de cualquiera de las siguientes maneras:
- Si tu extremo de destino se encuentra dentro de 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 el extremo de destino se encuentra dentro de Google Cloud, sigue estos pasos:
- Configura el intercambio de tráfico entre redes de VPC entre redes de VPC.
- Configura Cloud VPN entre redes de VPC.
- Configura la conectividad de red con los radios de VPC de Network Connectivity Center.
Si ya tienes una conexión a la red de destino:
- La red del extremo de origen no tiene una ruta a través de esta conexión o usa la ruta predeterminada que pasa por la puerta de enlace 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 la applicability, consulta Rutas y Cómo usar rutas.
Si pruebas la conectividad a una red local desde una red de intercambio de tráfico, consulta este ejemplo para ver anuncios personalizados, modo de enrutamiento de red e intercambio de rutas personalizadas.
No se admite el intercambio de tráfico transitivo entre redes de VPC. Puedes usar una VPN o el intercambio de tráfico para estas dos redes de VPC.
No se permite el Acceso privado a Google
Una instancia de Compute Engine con solo una dirección IP interna intenta alcanzar la dirección IP externa de los servicios y las API de Google, pero el Acceso privado a Google no está habilitado en la subred de la instancia.
Recomendaciones
Puedes permitir que la instancia de VM de Compute Engine llegue a la dirección IP externa de las API y los servicios de Google de cualquiera de las siguientes maneras:
- Habilita el Acceso privado a Google para la subred de la instancia.
- Asigna una dirección IP externa a la NIC de Compute Engine.
- Habilita Cloud NAT para la subred de la instancia de VM.
No se admite el Acceso privado a Google a través del túnel VPN
Un extremo de origen con una dirección IP interna intenta acceder a la dirección IP externa de los servicios y las APIs de Google a través del túnel VPN hacia otra red, pero el Acceso privado a Google debe estar habilitado en la red del extremo de origen.
Causa probable
El paquete desde el extremo de origen hasta 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 no se admite esa configuración.
Recomendaciones
Si el extremo de origen es un extremo de Google Cloud (como una instancia de VM de Compute Engine), considera habilitar el Acceso privado a Google en su subred de origen.
Si el extremo de origen es un extremo local, consulta Acceso privado a Google para hosts locales a fin de obtener instrucciones detalladas.
La regla de reenvío no coincide
Los puertos y el protocolo de la regla de reenvío no coinciden con el encabezado del paquete.
Causa probable
El paquete se envía con un protocolo que no es compatible con la regla de reenvío, o el paquete se envía a un puerto de destino que no coincide con los puertos admitidos por la regla de reenvío.
Recomendaciones
Confirma los puertos y el protocolo de la regla de reenvío de destino.
La región de la regla de reenvío no coincide
La regla de reenvío no tiene habilitado el acceso global y su región no coincide con la región del paquete.
Causa probable
Además, según el balanceador de cargas y su nivel, la regla de reenvío puede ser global o regional. Para obtener más información, consulta la tabla de tipos de balanceadores de cargas.
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 cargas.
Recomendaciones
Si te conectas al balanceador de cargas desde un extremo de Google Cloud, como una instancia de VM de Compute Engine, asegúrate de que se encuentre en la misma región que la regla de reenvío.
Mientras te conectas desde una red local, asegúrate de que el cliente acceda al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de VLAN que se encuentren en la misma región que el balanceador de cargas. Para obtener más detalles, consulta Balanceadores de cargas de aplicaciones internos y redes conectadas.
Puedes habilitar el acceso global en los balanceadores de cargas de aplicaciones internos y los balanceadores de cargas de red del proxy interno regional para acceder a los clientes en cualquier región. De forma predeterminada, los clientes de estos balanceadores de cargas deben estar en la misma región que el balanceador de cargas. Para obtener más información, consulta Habilita el acceso global para los balanceadores de cargas de aplicaciones internos y Habilita el acceso global para los balanceadores de cargas de red del proxy internos regionales.
Verificación de estado del backend del balanceador de cargas que bloquea el firewall
Los firewalls bloquean los sondeos de verificación de estado en los backends y provocan que estos no estén disponibles para el tráfico desde el balanceador de cargas.
Causa probable
Para que las verificaciones de estado funcionen, debes crear reglas de firewall de entrada permitida que permitan que el tráfico de los sistemas de sondeo de Google Cloud llegue a tus backends. De lo contrario, los backends se consideran en mal estado.
Recomendaciones
Crea reglas de firewall de permiso de entrada de acuerdo con la tabla de rangos de IP de sondeo y reglas de firewall. Para obtener más información, consulta Reglas de firewall obligatorias.
No hay direcciones externas disponibles
Una instancia de VM con solo una dirección IP interna intentó acceder a hosts externos a través de una ruta cuyo siguiente salto es la puerta de enlace de Internet predeterminada. Esto es esperable cuando Cloud NAT no está habilitado en la subred o cuando no hay otra ruta predeterminada cuyo siguiente salto sea de un tipo diferente (como una VM de proxy).
Causa probable
Una instancia con solo una dirección IP interna intentó 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 deseas acceder a extremos externos, puedes asignar una dirección IP externa a tu instancia. Como alternativa, puedes habilitar Cloud NAT en su subred, a menos que la conexión pase por una instancia de proxy que brinde acceso a Internet.
Regla de reenvío sin instancias
La regla de reenvío no tiene backends configurados.
Causa probable
La regla de reenvío a la que intentas acceder no tiene ningún backend configurado.
Recomendaciones
Verifica la configuración del balanceador de cargas y asegúrate de que el servicio de backend del balanceador de cargas tenga backends configurados.
El tipo de tráfico está bloqueado
El tipo de tráfico está bloqueado y no puedes configurar una regla de firewall para habilitarlo. Para ver más detalles, consulta Tráfico que siempre está bloqueado.
Causa probable
Este tipo de tráfico se bloquea de forma predeterminada y no se puede habilitar mediante la creación de reglas de firewall. Los casos comunes son los siguientes:
- Enviar tráfico de salida a un destino externo con el puerto TCP 25 (SMTP). Para ver más detalles, consulta Tráfico que siempre está bloqueado.
- Enviar tráfico a un puerto no compatible 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 Cloud Function o una revisión de Cloud Run que usa un protocolo que no sea TCP o UDP
Recomendaciones
Para el tráfico de salida de SMTP (tráfico de salida a un destino externo con puerto TCP 25), consulta Envía correos electrónicos desde una instancia.
Para el protocolo DHCP, incluidos los paquetes IPv4 de UDP al puerto de destino 68 (respuestas de DHCPv4) y los paquetes IPv6 de UDP al puerto de destino 546 (respuestas de DHCPv6), solo se permite el tráfico de DHCP desde el servidor de metadatos (169.254.169.254).
Para la conectividad de Cloud SQL, asegúrate de que el puerto que se usa sea correcto.
El conector de Acceso a VPC sin servidores no está configurado
Se descartó el paquete porque la versión del entorno estándar de App Engine, la Cloud Function o la revisión de Cloud Run no tienen configurado un conector de Acceso a VPC sin servidores.
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 de la fuente, pero no hay ningún conector de Acceso a VPC sin servidores configurado para la versión del entorno estándar de App Engine, la Cloud Function o la revisión de Cloud Run.
Recomendaciones
Si intentas acceder al extremo de destino con su dirección IP privada, asegúrate de haber configurado un conector de Acceso a VPC sin servidores para la versión del entorno estándar de App Engine, la Cloud Function o la revisión de Cloud Run.
El conector de Acceso a VPC sin servidores no se está ejecutando
Se descartó el paquete porque el conector de Acceso a VPC sin servidores no se está ejecutando.
Causa probable
Se descartó el paquete porque se detuvieron todas las instancias del conector de Acceso a VPC sin servidores.
Recomendaciones
Si quieres obtener una lista de los pasos para solucionar problemas, consulta Solución de problemas.
No se acepta la conexión de Private Service Connect
Se descartó el paquete porque no se aceptó la conexión de Private Service Connect.
Causa probable
El extremo de Private Service Connect está en un proyecto que no está aprobado para conectarse al servicio. Para obtener más información, consulta Consulta los detalles del extremo.
Recomendaciones
Asegúrate de que el extremo de Private Service Connect esté en un proyecto aprobado para conectarse al servicio administrado.
Se accede al extremo de Private Service Connect desde una red con intercambio de tráfico
El paquete se envía al extremo de Private Service Connect en la red con intercambio de tráfico, pero esa configuración no es compatible.
Recomendaciones
Considera usar uno de los patrones de conectividad que se describen en la página de patrones de implementación de Private Service Connect. También puedes acceder a las APIs de Google y a los servicios publicados mediante los backends de Private Service Connect.