Solución de problemas de acceso al servidor de metadatos

Este documento le muestra 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 máquinas virtuales tienen acceso automáticamente a la API del servidor de metadatos sin ninguna autorización adicional. Sin embargo, a veces las máquinas virtuales pueden perder el acceso al servidor de metadatos debido a una de las siguientes causas:

  • No se pudo resolver el nombre de dominio del servidor de metadatos
  • La conexión al servidor de metadatos está bloqueada por uno de los siguientes:
    • Configuración del firewall a nivel del sistema operativo
    • Configuración de proxy
    • Enrutamiento personalizado

Cuando las máquinas virtuales no pueden acceder al servidor de metadatos, algunos procesos pueden fallar.

Para obtener información sobre cómo solucionar problemas del gke-metadata-server , consulte Solucionar problemas de autenticación de GKE .

Antes de comenzar

  • Si aún no lo has hecho, configura la autenticación. La autenticación es el proceso mediante el cual se verifica su identidad para acceder a Google Cloud servicios y API. Para ejecutar código o muestras 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. After installing the Google Cloud CLI, initialize it by running the following command: 

      gcloud init

      If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

    2. Set a default region and zone.

      3. REST

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

        After installing the Google Cloud CLI, initialize it by running the following command: 

        gcloud init

        If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      Para obtener más información, consulta Autentica para usar REST en la documentación de autenticación de Google Cloud .

Solucionar problemas de códigos de servidor

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

Códigos de servidor comunes

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 fue exitosa N / A
400 Solicitud incorrecta: este estado de error se devuelve en muchos escenarios diferentes, como cuando una solicitud tiene parámetros de consulta incorrectos o no se han cumplido los requisitos para ese punto final. Revise el mensaje de error para obtener sugerencias sobre cómo solucionar el error.
403 Prohibido: este estado de error se devuelve en los siguientes escenarios:
  • El punto final solicitado está deshabilitado por la configuración del proyecto o de las instancias.
  • La solicitud no pasa los controles de seguridad. Este problema puede ocurrir si su conexión TCP con el servidor se cerró en la capa de red.
 Verifique la configuración de su proyecto e instancia para asegurarse de que el punto final esté habilitado, o verifique la configuración de su red
404 No encontrado: el punto final solicitado no existe Corregir la ruta de la solicitud
429 Demasiadas solicitudes: esto ocurre porque algunos puntos finales utilizan limitación de velocidad para evitar la sobrecarga en el servicio de respaldo. Se recomienda encarecidamente volver a intentarlo con un retroceso exponencial. Para obtener más información, consulte la lista de puntos finales de tasa limitada . Espera unos segundos y vuelve a intentar la llamada.
503 Servicio no disponible: el servidor de metadatos no está listo para funcionar. El servidor de metadatos puede devolver el código de estado Error 503 en cualquiera de las siguientes circunstancias:
  • El servidor de metadatos todavía 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
 Los errores 503 son transitorios y deberían resolverse después de, como máximo, unos segundos. Para resolverlo, espera unos segundos y vuelve a intentar la llamada .

Códigos de servidor raros

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

código de servidor Descripción Resolución
301 Movido permanentemente: esto se proporciona para rutas que tienen redirecciones Actualizar la ruta de la solicitud
405 No permitido: este código de error se devuelve si se solicita un método no compatible.

El servidor de metadatos solo admite operaciones GET , con la excepción de metadatos que pueden ser escritos por invitados, que permiten operaciones SET .		 Actualice el método en su ruta de solicitud

Calificar códigos de error de puntos finales limitados

Los siguientes puntos finales enumerados tienen una velocidad limitada y pueden devolver códigos de error. Para manejar estos códigos de error devueltos, consulte Guía de reintento .

Puntos finales Código de estado Descripción
oslogin/ 429 Los límites de la tasa de inicio de sesión del sistema operativo se comparten entre solicitudes de usuario, autorización y grupo.
instance/service-accounts/identity 429 , 503 El punto final de firma de identidad puede devolver códigos de respuesta 429 o 503 para indicar una respuesta de velocidad limitada.
instance/service-accounts/default/token 429 Los tokens almacenados en caché en el servidor de metadatos no tienen límite de velocidad. Los tokens no almacenados en caché están sujetos a limitaciones de velocidad.
instance/guest-attributes/ 429 , 503 Las solicitudes de atributos de invitados pueden verse limitadas si excede 3 QPS o 10 QPM. Si se produce una limitación, se devuelven los códigos de error 429 o 503 .

Reintentar guía

El servidor de metadatos devuelve habitualmente códigos de error 503 y 429. Para que sus aplicaciones sean resistentes, le recomendamos que implemente una lógica de reintento para las aplicaciones que consultan el servidor de metadatos. También le sugerimos que implemente un retroceso exponencial en sus secuencias de comandos para tener en cuenta cualquier posible limitación de velocidad.

Solucionar problemas de solicitudes fallidas al servidor de metadatos

Los siguientes son ejemplos de errores que puede encontrar si su VM no logra llegar 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 su VM ha perdido el acceso al servidor de metadatos, haga lo siguiente:

linux

  1. Conéctese a su máquina virtual Linux.

  2. Desde su máquina virtual Linux, ejecute los siguientes comandos para probar la conectividad con el servidor de metadatos:

    1. Consulta el servidor de nombres de dominio:

      nslookup metadata.google.internal

      El resultado debería ser similar al 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. Compruebe que se pueda acceder al servidor de metadatos. Para verificar, ejecute los siguientes comandos:

      ping -c 3 metadata.google.internal

      El resultado debería ser similar al 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

      El resultado debería ser similar al 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, su VM está conectada al servidor de metadatos y no se requiere ninguna otra acción. Si los comandos fallan, haga lo siguiente:

      1. Verifique que el servidor de nombres esté configurado para el servidor de metadatos:

        cat /etc/resolv.conf

        El resultado debería ser similar al 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, consulte la documentación de su sistema operativo para obtener información sobre cómo editar la política 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 configuraciones de DNS zonales a las máquinas virtuales dentro de su proyecto. En caso de que su proyecto todavía utilice un DNS global , el archivo resolv.conf se revertirá al DHCP predeterminado en 24 horas.

      2. Verifique 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 debería estar en la salida: 

        169.254.169.254 metadata.google.internal  # Added by Google

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

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

ventanas

  1. Conéctese a su máquina virtual Windows.

  2. Desde su máquina virtual Windows, ejecute los siguientes comandos:

    1. Consulta el servidor de nombres de dominio: 

      nslookup metadata.google.internal

      El resultado debería ser similar al siguiente: 

      Server:  UnKnown
Address:  10.128.0.1

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

    2. Compruebe que se pueda acceder al servidor de metadatos. Para verificar, ejecute los siguientes comandos: 

      ping -n 3 metadata.google.internal

      El resultado debería ser similar al 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

      El resultado debería ser similar al 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, su VM está conectada al servidor de metadatos y no se requiere ninguna otra acción. Si los comandos fallan, haga lo siguiente:

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

        route print

        La salida 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 tiene la línea anterior, agregue la ruta usando 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. Verifique 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 debería estar en la salida: 

        169.254.169.254 metadata.google.internal  # Added by Google

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

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

Solucionar problemas de solicitudes fallidas al utilizar un proxy de red

Un servidor proxy de red impide el acceso directo de la VM a Internet. Todas las consultas enviadas desde una máquina virtual son manejadas por el servidor proxy.

Cuando se utiliza 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 VM está detrás de un proxy, debe establecer la configuración NO_PROXY tanto para la dirección IP como para el nombre de host.

Si no establece la configuración NO_PROXY , es posible que vea errores al ejecutar los comandos 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 instancia misma.

El siguiente es un ejemplo de un error que podría ver: 

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

Para resolver este problema de proxy, agregue el nombre de host del servidor de metadatos y la dirección IP a la variable de entorno NO_PROXY haciendo lo siguiente:

linux

  1. Conéctese a su máquina virtual Linux.

  2. Desde su máquina virtual Linux, ejecute los siguientes comandos: 

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

    Para guardar los cambios, ejecute el siguiente comando: 

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

ventanas

  1. Conéctese a su máquina virtual Windows.

  2. Desde su máquina virtual Windows, ejecute los siguientes comandos: 

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

    Para guardar los cambios, ejecute el siguiente comando: 

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

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

Esta sección cubre algunos de los errores que puede ver al consultar el punto final del servidor de metadatos HTTPS .

Los errores enumerados en esta sección se devuelven cuando realiza una consulta utilizando la herramienta cURL para realizar consultas; sin embargo, el mensaje de error devuelto es similar para otras herramientas.

Certificado de cliente incorrecto

Se producen los siguientes errores si proporciona un valor incorrecto para el indicador -E . 

  • 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 resolver este problema, proporcione la ruta correcta al certificado de identidad del cliente. Para ver la ubicación de los certificados de identidad del cliente, consulte Certificados de identidad del cliente .

Nombre de host incorrecto

Se produce el siguiente error si el nombre de host utilizado 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 resolver este problema, verifique que la URL raíz o el nombre de host en su consulta sea metadata.google.internal . Para obtener más información sobre la URL raíz del servidor de metadatos, consulte Partes de una solicitud de metadatos .

Certificado raíz o de cliente incorrecto

Es posible que vea el siguiente error al consultar el punto final del servidor de metadatos HTTPS: 

curl: (77) error setting certificate verify locations:

Esto podría suceder en los siguientes escenarios:

  • La ruta para la bandera --cacert puede estar mal formada
  • Es posible que falte el certificado raíz en el almacén de confianza

Para resolver este problema, debe especificar tanto el certificado raíz como el certificado del cliente al consultar el punto final https. Para conocer las ubicaciones de los certificados, consulte ¿Dónde se almacenan los certificados ?

Por ejemplo, para consultar la imagen de inicio de una VM, ejecute 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 de formato de encabezado incorrecto

El servidor de metadatos realiza comprobaciones de formato para garantizar que los encabezados cumplan con la directriz de formato de encabezado 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á recomendaciones de que tiene máquinas virtuales que realizan solicitudes al servidor de metadatos con encabezados con formato incorrecto. Las recomendaciones se envían una vez por máquina virtual. Puede acceder a estas recomendaciones mediante la CLI de Google Cloud o la API REST del recomendador.

    Después de haber aplicado la recomendación, establezca el estado de la recomendación en succeeded .

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

A continuación se muestran ejemplos de formatos de solicitud de encabezado válidos e inválidos.

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

Metadata-Flavor : Google

Válido : no hay espacios en blanco entre el nombre del encabezado y los dos puntos, el verificador ignora los espacios en blanco después de los dos puntos 

Metadata-Flavor: Google

Válido : sin espacios en blanco en el encabezado 

Metadata-Flavor:Google

Para obtener más información sobre cómo realizar consultas al servidor de metadatos, consulte Acceso a metadatos de VM .