Soluciona problemas de acceso del servidor de metadatos

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

Las VMs de Compute Engine almacenan metadatos en un servidor de metadatos. Las VMs tienen acceso a la API del servidor de metadatos de forma automática sin ninguna autorización adicional. Sin embargo, a veces las VMs 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 una de las siguientes opciones:
    • Configuración del firewall a nivel del SO
    • Configuración de proxy
    • Enrutamiento personalizado

Cuando las VMs no pueden acceder al servidor de metadatos, algunos procesos pueden fallar.

Para obtener información sobre cómo solucionar problemas de gke-metadata-server, consulta Soluciona problemas de autenticación de GKE.

Antes de comenzar

  • Si aún no lo hiciste, configura la autenticación. La autenticación es el proceso mediante el cual se verifica tu identidad para acceder a los servicios y las API de Google Cloud. 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. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    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.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

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

Cómo solucionar problemas con los códigos del servidor

Los siguientes códigos de servidor se muestran cuando realizas llamadas al servidor de metadatos de Compute Engine. Revisa esta sección para ver cómo responder a cada código de servidor que muestra el servidor de metadatos.

Códigos de servidor comunes

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

Código del servidor Descripción Solución
200 OK: La solicitud se realizó correctamente. N/A
400 Solicitud incorrecta: Este estado de error se muestra en muchos casos diferentes, por ejemplo, cuando una solicitud tiene parámetros de consulta incorrectos o no se cumplen los requisitos de ese extremo. Revisa el mensaje de error para obtener sugerencias sobre cómo corregirlo.
404 No se encontró: El extremo solicitado no existe. Corrige la ruta de la solicitud
429 Demasiadas solicitudes: Esto ocurre porque algunos extremos usan el límite de frecuencia para evitar la sobrecarga en el servicio de respaldo. Espera unos segundos y vuelve a realizar la llamada.
503 Servicio no disponible: El servidor de metadatos no está listo para publicarse. El servidor de metadatos puede mostrar 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 anfitrión está realizando un evento de mantenimiento.
 Los errores 503 son transitorios y deberían resolverse después de unos pocos segundos como máximo. Para resolver el problema, espera unos segundos y vuelve a intentar la llamada.

Códigos de servidor poco comunes

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

Código del servidor Descripción Solución
301 Se movió de forma permanente: Se proporciona para las rutas que tienen redireccionamientos. Actualiza la ruta de la solicitud
403 Forbidden: Se muestra si el servidor de metadatos considera que la solicitud no es segura. Esto puede ocurrir si se cerró tu conexión TCP al servidor en la capa de red. Verifica la configuración de red
405 No se permite: Se muestra este código de error si se solicita un método no compatible.

El servidor de metadatos solo admite operaciones GET, con la excepción de los metadatos que se pueden escribir como invitado, que permiten operaciones SET.		 Actualiza el método en la ruta de la solicitud

Orientación para volver a intentarlo

El servidor de metadatos muestra códigos de error 503 y 429 de forma rutinaria. Para que tus aplicaciones sean resilientes, te recomendamos que implementes la lógica de reintento para las aplicaciones que consultan el servidor de metadatos. También te sugerimos que implementes la retirada exponencial en tus secuencias de comandos para tener en cuenta cualquier límite de frecuencia posible.

Soluciona problemas de solicitudes fallidas al servidor de metadatos

Los siguientes son errores de ejemplo que puedes encontrar si la VM no llega 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 perdió el acceso al servidor de metadatos, haz lo siguiente:

Linux

  1. Conéctate a tu VM de Linux.

  2. Desde tu VM de Linux, ejecuta los siguientes comandos para probar la conectividad al 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. Verifica que se pueda acceder al servidor de metadatos. Para verificar, ejecuta 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, la VM se conecta al servidor de metadatos y no es necesario que realices ninguna otra acción. Si los comandos fallan, haz lo siguiente:

      1. Verifica que el servidor de nombres esté configurado en 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, consulta la documentación de tu sistema operativo para obtener información para editar la Política de DHCP para conservar el servidor de nombres. la configuración como 169.254.169.254. Esto se debe a que los cambios en /etc/resolv.conf se reemplazarán en una hora si se aplica la configuración de DNS zonal a las VMs de tu proyecto. En caso de que tu proyecto aún use un DNS global, el archivo resolv.conf se revertirá al DHCP predeterminado en 24 horas.

      2. Verifica 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 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" >> /etc/hosts

Windows

  1. Conéctate a tu VM de Windows.

  2. Desde la VM de Windows, ejecuta 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. Verifica que se pueda acceder al servidor de metadatos. Para verificar, ejecuta 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, la VM se conecta al servidor de metadatos y no es necesario que realices ninguna otra acción. Si los comandos fallan, haz lo siguiente:

      1. Ejecuta el siguiente comando para verificar que haya una ruta persistente al servidor de metadatos:

        route print

        El resultado debería 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, agrega 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. Verifica 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 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

Soluciona problemas relacionados con las solicitudes fallidas cuando usas un proxy de red

Un servidor proxy de red evita el acceso directo de la VM a Internet. En cambio, el servidor proxy controla todas las consultas que se envían desde una VM.

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 VM está detrás de un proxy, debes configurar NO_PROXY para la dirección IP y el nombre de host.

Si no configuras NO_PROXY es posible que veas errores cuando ejecutes comandos de Google Cloud CLI o consultes el servidor de metadatos directamente desde las llamadas a metadata.google.internal se enviarán al proxy sin que se resuelvan de forma local en la instancia.

Se muestra un ejemplo de un error que podrías ver, a continuación:

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

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

Linux

  1. Conéctate a tu VM de Linux.

  2. Desde tu VM de 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. Desde la 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

Soluciona problemas relacionados con las solicitudes fallidas al extremo del servidor de metadatos HTTPS

En esta sección, se abordan algunos de los errores que puedes ver cuando consultas el extremo del servidor de metadatos HTTPS.

Los errores que se enumeran en esta sección se muestran cuando realizas una consulta con la herramienta cURL. Sin embargo, el mensaje de error que se muestra es similar para otras herramientas.

Certificado de cliente incorrecto

Se producen los siguientes errores si proporcionas un valor incorrecto para la marca -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, proporciona la ruta de acceso 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

El siguiente error se produce si el nombre de host que se usa 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, verifica que la URL raíz o el nombre de host de tu consulta sea 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 cuando consultes el extremo del servidor de metadatos HTTPS:

curl: (77) error setting certificate verify locations:

Esto puede suceder en las siguientes situaciones:

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

Para resolver este problema, debes especificar el certificado raíz y el certificado del cliente cuando consultes el extremo HTTPS. Para conocer las ubicaciones de los certificados, consulta Dónde se almacenan los certificados.

Por ejemplo, si quieres 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"

Soluciona problemas relacionados con el formato de encabezado incorrecto

El servidor de metadatos realiza verificaciones de formato para garantizar que los encabezados cumplan con el lineamiento de formato de encabezado RFC 7230 Sección 3.2. Si el formato del encabezado falla, se produce lo siguiente:

  • Se acepta la solicitud. Sin embargo, recibirás recomendaciones en las que se solicitan VMs que se envían al servidor de metadatos con encabezados con formato incorrecto. Las recomendaciones se envían una vez por VM. Puedes acceder a estas recomendaciones mediante Google Cloud CLI o la API de REST del recomendador.

    Después de aplicar la recomendación, establece el estado de la recomendación en succeeded.

  • A partir del 20 de enero de 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 espacios 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 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 en el servidor de metadatos, consulta Accede a metadatos de VM.