Solucionar problemas de acceso al servidor de metadatos

En este documento se explica cómo resolver problemas con el servidor de metadatos de Compute Engine.

Las máquinas virtuales de Compute Engine almacenan metadatos en un servidor de metadatos. Las VMs tienen acceso automático a la API del servidor de metadatos sin necesidad de autorización adicional. Sin embargo, a veces las VMs pueden perder el acceso al servidor de metadatos por uno de los siguientes motivos:

  • No se ha podido resolver el nombre de dominio del servidor de metadatos
  • La conexión con el servidor de metadatos está bloqueada por uno de los siguientes motivos:
    • Configuración del cortafuegos a nivel de SO
    • Configuración del proxy
    • Enrutamiento personalizado

Si las máquinas virtuales no pueden acceder al servidor de metadatos, es posible que algunos procesos fallen.

Para obtener información sobre cómo solucionar problemas con gke-metadata-server, consulta el artículo Solucionar problemas de autenticación de GKE.

Antes de empezar

  • Si aún no lo has hecho, configura la autenticación. La autenticación verifica tu identidad para acceder a Google Cloud servicios y APIs. Para ejecutar código o ejemplos desde un entorno de desarrollo local, puedes autenticarte en Compute Engine seleccionando una de las siguientes opciones:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Instala Google Cloud CLI. Después de la instalación, inicializa la CLI de Google Cloud ejecutando el siguiente comando: 

      gcloud init

      Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

    2. Set a default region and zone.

    REST

    Para usar las muestras de la API REST de esta página en un entorno de desarrollo local, debes usar las credenciales que proporciones a la CLI de gcloud.

      Instala Google Cloud CLI. Después de la instalación, inicializa la CLI de Google Cloud ejecutando el siguiente comando: 

      gcloud init

      Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

    Para obtener más información, consulta el artículo Autenticarse para usar REST de la documentación sobre autenticación de Google Cloud .

Solucionar problemas con códigos de servidor

Los siguientes códigos de servidor se devuelven cuando haces llamadas al servidor de metadatos de Compute Engine. Consulta esta sección para saber cómo responder a cada código de servidor devuelto por el servidor de metadatos.

Códigos de servidor habituales

Estos códigos de servidor se devuelven con frecuencia desde el servidor de metadatos.

Código de servidor Descripción Resolución
200 OK: la solicitud se ha realizado correctamente. N/A
400 Solicitud incorrecta: este estado de error se devuelve en muchos casos, como cuando una solicitud tiene parámetros de consulta incorrectos o no se han cumplido los requisitos de ese endpoint. Revisa el mensaje de error para ver sugerencias sobre cómo solucionarlo.
403 Prohibido: este estado de error se devuelve en los siguientes casos:
  • El endpoint solicitado está inhabilitado por la configuración del proyecto o de las instancias
  • La solicitud no supera las comprobaciones de seguridad. Este problema puede ocurrir si la conexión TCP al servidor se ha cerrado en la capa de red.
 Comprueba los ajustes de tu proyecto y de tu instancia para asegurarte de que el endpoint esté habilitado o comprueba la configuración de tu red.
404 No encontrado: el endpoint solicitado no existe Corregir la ruta de la solicitud
429 Demasiadas solicitudes: se produce porque algunos endpoints usan limitación de frecuencia para evitar la sobrecarga en el servicio de respaldo. Te recomendamos que vuelvas a intentarlo con un tiempo de espera exponencial. Para obtener más información, consulta la lista de endpoints con límite de frecuencia. Espera unos segundos y vuelve a intentar la llamada.
503 Servicio no disponible: el servidor de metadatos no está listo para proporcionar el servicio. El servidor de metadatos puede devolver el código de estado Error 503 en cualquiera de las siguientes circunstancias:
  • El servidor de metadatos aún se está iniciando
  • El servidor de metadatos está en proceso de migración
  • El servidor de metadatos no está disponible temporalmente.
  • La máquina host está realizando un evento de mantenimiento
  • El servidor de metadatos puede devolver un 503 cuando limite la frecuencia de algunos endpoints.
 Los errores 503 son transitorios y deberían resolverse en unos segundos como máximo. Para solucionarlo, espera unos segundos y vuelve a intentar la llamada.

Códigos de servidor poco frecuentes

Estos códigos de servidor, aunque son poco frecuentes, también pueden devolverse desde el servidor de metadatos.

Código de servidor Descripción Resolución
301 Moved Permanently: se proporciona para las rutas que tienen redirecciones. Actualizar la ruta de la solicitud
405 No permitido: se devuelve este código de error si se solicita un método no admitido.

El servidor de metadatos solo admite operaciones GET, excepto los metadatos que se pueden escribir por el invitado, que permite operaciones SET.		 Actualiza el método en la ruta de tu solicitud

Códigos de error de endpoints con límite de frecuencia

Los siguientes endpoints tienen límites de frecuencia y pueden devolver códigos de error. Para gestionar estos códigos de error devueltos, consulta Guía de reintentos.

Endpoint Código de estado Descripción
oslogin/ 429 Los límites de frecuencia de inicio de sesión del SO se comparten entre las solicitudes de usuario, autorización y grupo.
instance/service-accounts/identity 503 El endpoint de firma de identidad puede devolver códigos de respuesta 429 o 503 para indicar que la respuesta está limitada por la frecuencia.
instance/service-accounts/default/token 429 Los tokens almacenados en caché en el servidor de metadatos no tienen límites de frecuencia. Los tokens no almacenados en caché están sujetos a la limitación de frecuencia.
instance/guest-attributes/ 429, 503 Las solicitudes de atributos de invitado pueden limitarse si superas las 3 consultas por segundo o las 10 consultas por minuto. Si se produce una limitación, se devuelven los códigos de error 429 o 503.

Reintentar indicaciones

El servidor de metadatos devuelve de forma rutinaria los códigos de error 503 y 429. Para que tus aplicaciones sean resilientes, te recomendamos que implementes una lógica de reintento para las aplicaciones que consulten el servidor de metadatos. También te recomendamos que implementes retroceso exponencial en tus secuencias de comandos para tener en cuenta las posibles limitaciones de frecuencia.

Solucionar problemas con solicitudes fallidas al servidor de metadatos

A continuación, se muestran algunos ejemplos de errores que pueden producirse si tu VM no puede acceder al servidor de metadatos:

curl: (6) Could not resolve host: metadata.google.internal

postAttribute error: Put "http://metadata.google.internal/computeMetadata/v1/instance/guest-attributes/guestInventory/ShortName": dial tcp: lookup metadata.google.internal on [::1]:53: read udp [::1]:58319->[::1]:53: read: connection refused

Si tu VM ha perdido el acceso al servidor de metadatos, haz lo siguiente:

Linux

  1. Conéctate a tu VM Linux.

  2. En tu VM Linux, ejecuta los siguientes comandos para probar la conectividad con el servidor de metadatos:

    1. Consultar el servidor de nombres de dominio:

      nslookup metadata.google.internal

      La salida debería ser similar a la siguiente:

      Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   metadata.google.internal
Address: 169.254.169.254

    2. Comprueba que se pueda acceder al servidor de metadatos. Para verificarlo, ejecuta los siguientes comandos:

      ping -c 3 metadata.google.internal

      La salida debería ser similar a la siguiente:

      PING metadata.google.internal (169.254.169.254) 56(84) bytes of data.
64 bytes from metadata.google.internal (169.254.169.254): icmp_seq=1 ttl=255 time=0.812 ms

      ping -c 3 169.254.169.254

      La salida debería ser similar a la siguiente:

      PING 169.254.169.254 (169.254.169.254) 56(84) bytes of data.
64 bytes from 169.254.169.254: icmp_seq=1 ttl=255 time=1.11 ms

    3. Si el resultado de los comandos anteriores coincide con el resultado sugerido, tu máquina virtual está conectada al servidor de metadatos y no es necesario que hagas nada más. Si los comandos fallan, haz lo siguiente:

      1. Comprueba que el servidor de nombres esté configurado en el servidor de metadatos:

        cat /etc/resolv.conf

        La salida debería ser similar a la siguiente:

        domain ZONE.c.PROJECT_ID.internal
search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254

        Si el resultado no tiene las líneas anteriores, consulta la documentación de tu sistema operativo para obtener información sobre cómo editar la política de DHCP para conservar la configuración del servidor de nombres en 169.254.169.254. Esto se debe a que los cambios en /etc/resolv.conf se sobrescribirán en una hora si se aplican los ajustes de DNS de zona a las VMs de tu proyecto. Si tu proyecto sigue usando un DNS global, el archivo resolv.conf volverá al DHCP predeterminado en 24 horas.

      2. Comprueba que exista la asignación entre el nombre de dominio del servidor de metadatos y su dirección IP:

        cat /etc/hosts

        La siguiente línea debe aparecer en el resultado:

        169.254.169.254 metadata.google.internal  # Added by Google

        Si el resultado no incluye la línea anterior, ejecuta el siguiente comando:

        echo "169.254.169.254 metadata.google.internal" >> /etc/hosts

Windows

  1. Conéctate a tu VM de Windows.

  2. En tu VM de Windows, ejecuta los siguientes comandos:

    1. Consultar el servidor de nombres de dominio:

      nslookup metadata.google.internal

      La salida debería ser similar a la siguiente:

      Server:  UnKnown
Address:  10.128.0.1

Non-authoritative answer:
Name:    metadata.google.internal
Address:  169.254.169.254

    2. Comprueba que se pueda acceder al servidor de metadatos. Para verificarlo, ejecuta los siguientes comandos:

      ping -n 3 metadata.google.internal

      La salida debería ser similar a la siguiente: 

      Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255


      ping -n 3 169.254.169.254

      La salida debería ser similar a la siguiente:

      Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255

    3. Si el resultado de los comandos anteriores coincide con el resultado sugerido, tu VM estará conectada al servidor de metadatos y no tendrás que hacer nada más. Si los comandos fallan, haz lo siguiente:

      1. Comprueba que haya una ruta persistente al servidor de metadatos ejecutando el siguiente comando:

        route print

        El resultado debe contener lo siguiente:

        Persistent Routes:
Network Address          Netmask  Gateway Address  Metric
169.254.169.254  255.255.255.255         On-link        1

        Si el resultado no incluye la línea anterior, añade la ruta con los siguientes comandos:

        $Adapters = Get-NetKVMAdapterRegistry
$FirstAdapter = $Adapters | Select-Object -First 1
route /p add 169.254.169.254 mask 255.255.255.255 0.0.0.0 'if' $FirstAdapter.InterfaceIndex metric 1

      2. Comprueba que exista la asignación entre el nombre de dominio del servidor de metadatos y su dirección IP:

        type %WINDIR%\System32\Drivers\Etc\Hosts

        La siguiente línea debe aparecer en el resultado:

        169.254.169.254 metadata.google.internal  # Added by Google

        Si el resultado no tiene la línea anterior, ejecuta el siguiente comando:

        echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts

Solucionar problemas con solicitudes fallidas al usar un proxy de red

Un servidor proxy de red impide que las máquinas virtuales accedan directamente a Internet. Todas las consultas enviadas desde una máquina virtual las gestiona el servidor proxy.

Cuando se usa una aplicación que obtiene credenciales del servidor de metadatos, como un token de autenticación, la VM requiere acceso directo al servidor de metadatos. Si la máquina virtual está detrás de un proxy, debes definir la configuración NO_PROXY tanto para la dirección IP como para el nombre de host.

Si no configuras NO_PROXY, es posible que veas errores al ejecutar comandos de la CLI de Google Cloud o al consultar el servidor de metadatos directamente, ya que las llamadas a metadata.google.internal se enviarán al proxy sin que se resuelvan localmente en la propia instancia.

A continuación, se muestra un ejemplo de error que puede aparecer:

ERROR 403 (Forbidden): Your client does not have permission to get URL

Para solucionar este problema de proxy, añade el nombre de host y la dirección IP del servidor de metadatos a la variable de entorno NO_PROXY siguiendo estos pasos:

Linux

  1. Conéctate a tu VM Linux.

  2. En tu máquina virtual Linux, ejecuta los siguientes comandos:

    export no_proxy=169.254.169.254,metadata,metadata.google.internal

    Para guardar los cambios, ejecuta el siguiente comando:

    echo no_proxy=169.254.169.254,metadata,metadata.google.internal >> /etc/environment

Windows

  1. Conéctate a tu VM de Windows.

  2. En tu VM de Windows, ejecuta los siguientes comandos:

    set NO_PROXY=169.254.169.254,metadata,metadata.google.internal

    Para guardar los cambios, ejecuta el siguiente comando:

    setx NO_PROXY 169.254.169.254,metadata,metadata.google.internal /m

Solucionar problemas de solicitudes fallidas al endpoint del servidor de metadatos HTTPS

En esta sección se tratan algunos de los errores que pueden aparecer al consultar el endpoint del servidor de metadatos HTTPS.

Los errores que se indican en esta sección se devuelven cuando se consulta con la herramienta cURL. Sin embargo, el mensaje de error devuelto es similar en otras herramientas.

Certificado de cliente incorrecto

Se producen los siguientes errores si proporciona un valor incorrecto para la -E marca.

  • curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate
required, errno 0
  • curl: (58)  unable to set private key file:
  • curl: (58) could not load PEM client certificate, OpenSSL error error:02001002:system library:fopen:No such file or directory

Para solucionar este problema, proporcione la ruta correcta al certificado de identidad del cliente. Para ver la ubicación de los certificados de identidad de cliente, consulta Certificados de identidad de cliente.

Nombre de host incorrecto

Se produce el siguiente error si el nombre de host usado para acceder al servidor de metadatos no se encuentra en el certificado.

curl: (60) SSL: no alternative certificate subject name matches target host name

Para solucionar este problema, compruebe que la URL raíz o el nombre de host de su consulta sean metadata.google.internal. Para obtener más información sobre la URL raíz del servidor de metadatos, consulta Partes de una solicitud de metadatos.

Certificado raíz o de cliente incorrecto

Es posible que veas el siguiente error al consultar el endpoint del servidor de metadatos HTTPS:

curl: (77) error setting certificate verify locations:

Esto puede ocurrir en los siguientes casos:

  • Es posible que la ruta de la marca --cacert tenga un formato incorrecto
  • Puede que falte el certificado raíz en el almacén de confianza

Para solucionar este problema, debe especificar tanto el certificado raíz como el certificado de cliente al consultar el endpoint HTTPS. Para consultar las ubicaciones de los certificados, consulta Dónde se almacenan los certificados.

Por ejemplo, para consultar la imagen de arranque de una VM, ejecuta la siguiente consulta:

user@myinst:~$ curl "https://metadata.google.internal/computeMetadata/v1/instance/image" \
    -E /run/google-mds-mtls/client.key \
    --cacert /run/google-mds-mtls/root.crt \
    -H "Metadata-Flavor: Google"

Solucionar problemas con el formato de encabezado incorrecto

El servidor de metadatos realiza comprobaciones de formato para asegurarse de que los encabezados cumplen la directriz de formato de encabezados RFC 7230, sección 3.2. Si el formato del encabezado no supera estas comprobaciones, ocurre lo siguiente:

  • Se acepta la solicitud. Sin embargo, recibirás recomendaciones sobre las VMs que envían solicitudes al servidor de metadatos con encabezados con un formato incorrecto. Las recomendaciones se envían una vez por cada máquina virtual. Puedes acceder a estas recomendaciones mediante la CLI de Google Cloud o la API REST Recommender.

    Una vez que hayas aplicado la recomendación, cambia su estado a succeeded.

  • A partir del 20 de enero del 2024, el servidor de metadatos rechazará cualquier solicitud con un encabezado con formato incorrecto.

A continuación, se muestran ejemplos de formatos de solicitud de encabezado válidos y no válidos.

No válido: contiene un espacio en blanco entre el nombre del encabezado y los dos puntos

Metadata-Flavor : Google

Válido: no hay espacios en blanco entre el nombre del encabezado y los dos puntos. El comprobador ignora los espacios en blanco que haya después de los dos puntos.

Metadata-Flavor: Google

Válido: no hay espacios en blanco en el encabezado

Metadata-Flavor:Google

Para obtener más información sobre cómo hacer consultas al servidor de metadatos, consulta Acceder a metadatos de máquinas virtuales.

Solucionar problemas al obtener un token

Es posible que aparezca uno de los siguientes errores al consultar el servidor de metadatos:

  • ERROR: gcloud crashed (MetadataServerException): HTTP Error 401: Unauthorized
  • curl: (22) The requested URL returned error: 401

Estos errores pueden producirse si la cuenta de servicio asociada a la VM está inhabilitada. Para solucionar estos errores, habilita la cuenta de servicio o adjunta otra cuenta de servicio.