メタデータ サーバーへのアクセスに関する問題のトラブルシューティング

このドキュメントでは、Compute Engine メタデータ サーバーの問題を解決する方法について説明します。

Compute Engine VM は、メタデータ サーバーにメタデータを保存します。VM は、追加の承認なしで自動的にメタデータ サーバー API にアクセスできます。ただし、次のいずれかの原因で VM がメタデータ サーバーにアクセスできなくなることがあります。

  • メタデータ サーバーのドメイン名を解決できない
  • メタデータ サーバーへの接続が、次のいずれかによってブロックされている
    • OS レベルのファイアウォール構成
    • プロキシの設定
    • カスタム ルーティング

VM がメタデータ サーバーにアクセスできない場合、一部のプロセスが失敗する可能性があります。

gke-metadata-server のトラブルシューティングについては、GKE の認証に関する問題のトラブルシューティングをご覧ください。

始める前に

  • まだ設定していない場合は、認証を設定します。認証とは、Google Cloud サービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のいずれかのオプションを選択して Compute Engine に対する認証を行います。

    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

      このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

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

        gcloud init

      詳細については、Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。

サーバーコードのトラブルシューティング

Compute Engine メタデータ サーバーを呼び出すと、次のサーバーコードが返されます。このセクションでは、メタデータ サーバーから返された各サーバーコードに応答する方法について説明します。

一般的なサーバーコード

これらのサーバーコードは、メタデータ サーバーから頻繁に返されます。

サーバーコード 説明 解決策
200 OK: リクエストが成功しました なし
400 Bad Request: このエラー ステータスは、リクエストに不適切なクエリ パラメータが含まれている場合や、そのエンドポイントの要件が満たされていない場合など、さまざまなシナリオで返されます。 エラー メッセージを確認して、エラーの修正方法の候補を確認する
404 Not Found: リクエストされたエンドポイントが存在しない リクエストパスを修正する
429 リクエストが多すぎる: バックエンド サービスの過負荷を防ぐため、一部のエンドポイントではレート制限が使用されています。このため、このようなエラーが発生します。 数秒待ってから、呼び出しを再試行します。
503 サービスが利用不可: メタデータ サーバーがサービスを提供できる状態になっていません。メタデータ サーバーは、次のいずれかの状況で Error 503 ステータス コードを返すことがあります。
  • メタデータ サーバーがまだ起動中である
  • メタデータ サーバーが移行中である
  • メタデータ サーバーが一時的に利用不可になっています
  • ホストがメンテナンス イベントで動作している
 503 は一時的なもので、ほとんどの場合、数秒以内に解決します。解決するには、数秒待ってから呼び出しを再試行します。

まれなサーバーコード

次のサーバーコードは、まれですが、メタデータ サーバーからも返されることがあります。

サーバーコード 説明 解決策
301 永続的に移動: リダイレクトがあるパスに使用されます リクエストパスを更新する
403 Forbidden: リクエストが安全でないとメタデータ サーバーが判断した場合に返されます。これは、サーバーへの TCP 接続がネットワーク レイヤで閉じられた場合に発生することがあります。 ネットワーク構成を確認する
405 Not Allowed: サポートされていないメソッドがリクエストされた場合に返されるエラーコードです。

メタデータ サーバーは、SET オペレーションを許可するゲスト書き込みメタデータを除き、GET オペレーションのみをサポートします。		 リクエストパスのメソッドを更新する

再試行のガイダンス

メタデータ サーバーは、503 エラーコードと 429 エラーコードを定期的に返します。アプリケーションを復元力のあるものにするには、メタデータ サーバーをクエリするアプリケーションに再試行ロジックを実装することをおすすめします。また、レート制限を考慮して、スクリプトに指数バックオフを実装することをおすすめします。

メタデータ サーバーへのリクエストに失敗した場合のトラブルシューティング

VM がメタデータ サーバーに到達できない場合に発生するエラーの例を次に示します。

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

VM がメタデータ サーバーにアクセスできなくなった場合は、次の操作を行います。

Linux

  1. Linux VM に接続します。

  2. Linux VM から、次のコマンドを実行してメタデータ サーバーへの接続性をテストします。

    1. ドメイン ネームサーバーに対してクエリを実行します。

      nslookup metadata.google.internal

      出力は次のようになります。

      Server:         169.254.169.254
Address:        169.254.169.254#53

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

    2. メタデータ サーバーに到達可能であることを確認します。これを確認するには、次のコマンドを実行します。

      ping -c 3 metadata.google.internal

      出力は次のようになります。

      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

      出力は次のようになります。

      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. 上記のコマンドの出力が推奨出力と一致する場合、VM はメタデータ サーバーに接続されるため、それ以上の操作は必要ありません。コマンドが失敗した場合は、次の操作を行います。

      1. ネームサーバーがメタデータ サーバーに構成されていることを確認します。

        cat /etc/resolv.conf

        出力は次のようになります。

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

        出力に上記の行がない場合、DHCP ポリシーを編集してネームサーバー構成を 169.254.169.254 に保持する方法についてオペレーティング システムのドキュメントをご覧ください。これは、ゾーン DNS 設定がプロジェクト内の VM に適用されている場合、/etc/resolv.conf への変更が 1 時間以内に上書きされるためです。プロジェクトでまだグローバル DNS を使用している場合、resolv.conf ファイルは 24 時間以内にデフォルトの DHCP に戻されます。

      2. メタデータ サーバーのドメイン名とその IP アドレス間のマッピングが存在することを確認します。

        cat /etc/hosts

        出力に次の行があります。

        169.254.169.254 metadata.google.internal  # Added by Google

        出力に上記の行がない場合は、次のコマンドを実行します。

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

Windows

  1. Windows VM に接続します。

  2. Windows VM から、次のコマンドを実行します。

    1. ドメイン ネームサーバーに対してクエリを実行します。

      nslookup metadata.google.internal

      出力は次のようになります。

      Server:  UnKnown
Address:  10.128.0.1

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

    2. メタデータ サーバーに到達可能であることを確認します。これを確認するには、次のコマンドを実行します。

      ping -n 3 metadata.google.internal

      出力は次のようになります。

      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

      出力は次のようになります。

      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. 上記のコマンドの出力が推奨出力と一致する場合、VM はメタデータ サーバーに接続されるため、それ以上の操作は必要ありません。コマンドが失敗した場合は、次の操作を行います。

      1. 次のコマンドを実行して、メタデータ サーバーへの永続的なルートがあることを確認します。

        route print

        出力に次の内容が含まれているはずです。

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

        出力に上記の行がない場合は、次のコマンドを使用してルートを追加します。

        $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. メタデータ サーバーのドメイン名とその IP アドレス間のマッピングが存在することを確認します。

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

        出力に次の行があります。

        169.254.169.254 metadata.google.internal  # Added by Google

        出力に上記の行がない場合は、次のコマンドを実行します。

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

ネットワーク プロキシ使用中にリクエストが失敗した場合のトラブルシューティング

ネットワーク プロキシ サーバーは、VM がインターネットに直接アクセスできないようにします。VM 内から送信されるクエリはすべてプロキシ サーバーによって処理されます。

認証トークンなど、メタデータ サーバーから認証情報を取得するアプリケーションを使用する場合、VM はメタデータ サーバーに直接アクセスする必要があります。VM がプロキシの背後にある場合は、IP アドレスとホスト名の両方に NO_PROXY 構成を設定する必要があります。

NO_PROXY 構成を設定しない場合、Google Cloud CLI コマンドを実行したり、メタデータ サーバーに対して直接クエリを実行すると、エラーが表示されることがあります。metadata.google.internal の呼び出しが、インスタンス上でローカルに解決されることなく、プロキシに送信されるためです。

次のようなエラーが表示される場合があります。

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

このプロキシの問題を解決するには、メタデータ サーバーのホスト名と IP アドレスを環境変数 NO_PROXY に追加します。手順は次のとおりです。

Linux

  1. Linux VM に接続します。

  2. Linux VM から、次のコマンドを実行します。

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

    変更を保存するには、次のコマンドを実行します。

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

Windows

  1. Windows VM に接続します。

  2. Windows VM から、次のコマンドを実行します。

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

    変更を保存するには、次のコマンドを実行します。

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

HTTPS メタデータ サーバー エンドポイントへのリクエストに失敗した場合のトラブルシューティング

このセクションでは、HTTPS メタデータ サーバー エンドポイントをクエリする際に発生する可能性のあるエラーについて説明します。

このセクションに記載されているエラーは、cURL ツールを使用してクエリを実行したときに返されますが、返されるエラー メッセージの内容は他のツールでも同様です。

クライアント証明書が正しくない

-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

この問題を解決するには、クライアント ID 証明書の正しいパスを指定します。クライアント ID 証明書の場所を確認するには、クライアント ID 証明書をご覧ください。

ホスト名が正しくない

メタデータ サーバーにアクセスするために使用されるホスト名が証明書にない場合、次のエラーが発生します。

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

この問題を解決するには、クエリのルート URL またはホスト名が metadata.google.internal であることを確認します。メタデータ サーバーのルート URL の詳細については、メタデータ リクエストの部分をご覧ください。

ルート証明書またはクライアント証明書が正しくない

HTTPS メタデータ サーバー エンドポイントにクエリを実行すると、次のエラーが表示されることがあります。

curl: (77) error setting certificate verify locations:

これは、次のような場合に発生する可能性があります。

  • --cacert フラグのパスが正しい形式でない
  • ルート証明書が信頼ストアにない

この問題を解決するには、https エンドポイントをクエリするときに、ルート証明書とクライアント証明書の両方を指定します。証明書の場所については、証明書の保存場所をご覧ください。

たとえば、VM のブートイメージにクエリを実行するには、次のクエリを実行します。

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"

ヘッダー形式が正しくない問題のトラブルシューティング

メタデータ サーバーは、ヘッダーがヘッダーの形式設定ガイドライン RFC 7230 セクション 3.2 に準拠していることを確認するために、形式チェックを行います。ヘッダー形式がこのチェックに失敗すると、次のようになります。

  • リクエストが受け入れられます。ただし、形式が正しくないヘッダーで VM からメタデータ サーバーへのリクエストが行われると、推奨事項が表示されます。推奨事項は VM ごとに 1 回送信されます。これらの推奨事項にアクセスするには、Google Cloud CLI または Recommender REST API を使用します。

    推奨事項を適用したら、推奨事項の状態を succeeded に設定します。

  • 2024 年 1 月 20 日以降、メタデータ サーバーは、ヘッダーの形式が正しくないリクエストをすべて拒否します。

有効なヘッダー リクエストと無効なヘッダー リクエストの形式の例を次に示します。

無効: ヘッダー名とコロンの間に空白文字が含まれています。

Metadata-Flavor : Google

有効: ヘッダー名とコロンの間に空白文字はありません。コロンの後の空白はチェッカーには無視されます。

Metadata-Flavor: Google

有効: ヘッダーに空白文字が使用されていません。

Metadata-Flavor:Google

メタデータ サーバーへのクエリの実行の詳細については、VM メタデータにアクセスするをご覧ください。