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
  • Una de las siguientes opciones bloquea la conexión al servidor de metadatos:
    • Configuración de 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 más información sobre cómo solucionar problemas de gke-metadata-server, consulta Soluciona problemas de autenticación de GKE.

Antes de comenzar

  • Configura la autenticación si aún no lo hiciste. 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 de la siguiente manera

    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.

Errores de servidor

El servidor de metadatos puede mostrar el código de estado Error 503 en las siguientes circunstancias:

  • El servidor no está disponible en este momento
  • El host realiza un evento de mantenimiento

Si la aplicación recibe un código de error 503, vuelve a intentar la solicitud.

Solicitudes con errores 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

Soluciona problemas de solicitudes fallidas al servidor de metadatos

Si la VM perdió 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 verificarlo, 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 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, 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. Comprueba que exista la asignación entre el nombre de dominio del servidor de metadatos y la dirección IP:

        cat /etc/hosts

        La línea siguiente debería 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" >> /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 mediante 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 la dirección IP:

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

        La línea siguiente debería 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

Solicitudes fallidas mientras se usa un proxy de red

Un servidor proxy de red impide el acceso directo de la VM a Internet. 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 establecer la configuración de 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 con el proxy, agrega el nombre de host del servidor de metadatos y la dirección IP a la variable de entorno NO_PROXY mediante los siguientes pasos:

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"

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.