Memecahkan masalah akses Server Metadata

Linux Windows

Dokumen ini menunjukkan cara menyelesaikan masalah dengan server metadata Compute Engine.

VM Compute Engine menyimpan metadata di server metadata. VM akan otomatis memiliki akses ke API server metadata tanpa otorisasi tambahan. Namun, terkadang VM dapat kehilangan akses ke server metadata karena salah satu penyebab berikut:

Kegagalan me-resolve nama domain server metadata
Koneksi ke server metadata diblokir oleh salah satu dari hal berikut:
- Konfigurasi firewall tingkat OS
- Penyiapan proxy
- Pemilihan rute kustom

Jika VM tidak dapat mengakses server metadata, beberapa proses mungkin akan gagal.

Sebelum memulai

Siapkan autentikasi, jika Anda belum melakukannya. Autentikasi adalah proses verifikasi identitas Anda untuk akses ke layanan dan API Google Cloud. Untuk menjalankan kode atau contoh dari lingkungan pengembangan lokal, Anda dapat melakukan autentikasi ke Compute Engine sebagai berikut.

Pilih tab untuk melihat bagaimana Anda berencana menggunakan contoh di halaman ini:
Konsol

Saat menggunakan Konsol Google Cloud untuk mengakses API dan layanan Google Cloud, Anda tidak perlu menyiapkan autentikasi.
gcloud
1. Instal Google Cloud CLI, lalu initialize dengan menjalankan perintah berikut:
```
gcloud init
```
  Catatan: Jika Anda telah menginstal gcloud CLI sebelumnya, pastikan Anda memiliki versi baru dengan menjalankan gcloud components update.
2. Menetapkan region dan zona default.
REST

Untuk menggunakan contoh REST API di halaman ini dalam lingkungan pengembangan lokal, gunakan kredensial yang Anda berikan ke gcloud CLI.

Error yang biasa terjadi

Berikut adalah contoh hal yang mungkin Anda alami jika VM gagal menjangkau server metadata:

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

Memecahkan masalah permintaan yang gagal ke server metadata

Jika VM Anda kehilangan akses ke server metadata, lakukan hal berikut:

Linux

Hubungkan ke VM Linux.
Dari VM Linux, jalankan perintah berikut untuk menguji konektivitas ke server metadata:
1. Membuat kueri Server Nama Domain:
```
nslookup metadata.google.internal
```
  Output-nya akan terlihat seperti berikut:
```
Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   metadata.google.internal
Address: 169.254.169.254
```
2. Periksa apakah server metadata dapat dijangkau. Untuk memverifikasi, jalankan perintah berikut:
```
ping -c 3 metadata.google.internal
```
  Output-nya akan terlihat seperti berikut:
```
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
```
  Output-nya akan terlihat seperti berikut:
```
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. Jika output dari perintah sebelumnya cocok dengan output yang disarankan, VM Anda akan terhubung ke server metadata dan tidak diperlukan tindakan lebih lanjut. Jika perintah gagal, lakukan hal berikut:
  1. Pastikan server nama telah dikonfigurasi ke server Metadata:
```
cat /etc/resolv.conf
```
    Output-nya akan terlihat seperti berikut:
```
domain ZONE.c.PROJECT_ID.internal
search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254
```
    Jika output tidak memiliki baris sebelumnya, lihat dokumentasi sistem operasi Anda untuk mengetahui informasi tentang cara mengedit Kebijakan DHCP untuk mempertahankan konfigurasi server nama ke 169.254.169.254. Hal ini karena perubahan pada /etc/resolv.conf akan ditimpa dalam waktu satu jam jika setelan DNS zona diterapkan ke VM dalam project Anda. Jika project Anda masih menggunakan DNS global, file resolv.conf akan dikembalikan ke DHCP default dalam waktu 24 jam.
  2. Pastikan ada pemetaan antara nama domain server metadata dan alamat IP-nya:
```
cat /etc/hosts
```
    Baris berikut akan muncul dalam output:
```
169.254.169.254 metadata.google.internal  # Added by Google
```
    Jika output tidak memiliki baris sebelumnya, jalankan perintah berikut:
```
echo "169.254.169.254 metadata.google.internal" >> /etc/hosts
```

Windows

Hubungkan ke VM Windows Anda.

Dari VM Windows Anda, jalankan perintah berikut:

Membuat kueri Server Nama Domain:

nslookup metadata.google.internal

Output-nya akan terlihat seperti berikut:

Server:  UnKnown
Address:  10.128.0.1

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

Periksa apakah server metadata dapat dijangkau. Untuk memverifikasi, jalankan perintah berikut:

ping -n 3 metadata.google.internal

Output-nya akan terlihat seperti berikut:

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

Output-nya akan terlihat seperti berikut:

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

Jika output perintah sebelumnya cocok dengan output yang disarankan, VM Anda akan terhubung ke server metadata dan tidak diperlukan tindakan lebih lanjut. Jika perintah gagal, lakukan hal berikut:
1. Pastikan ada rute yang persisten ke server metadata dengan menjalankan perintah:
```
route print
```
  Output harus berisi hal berikut:
```
Persistent Routes:
Network Address          Netmask  Gateway Address  Metric
169.254.169.254  255.255.255.255         On-link        1
```
  Jika output tidak memiliki baris sebelumnya, tambahkan rute menggunakan perintah berikut:
```
$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. Pastikan ada pemetaan antara nama domain server metadata dan alamat IP-nya:
```
type %WINDIR%\System32\Drivers\Etc\Hosts
```
  Baris berikut akan muncul dalam output:
```
169.254.169.254 metadata.google.internal  # Added by Google
```
  Jika output tidak memiliki baris sebelumnya, jalankan perintah berikut:
```
echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts
```

Memecahkan masalah permintaan yang gagal saat menggunakan proxy jaringan

Server proxy jaringan mencegah akses langsung VM ke Internet. Semua kueri yang dikirim dari dalam VM ditangani oleh server proxy.

Saat menggunakan aplikasi yang mendapatkan kredensial dari server metadata, seperti token autentikasi, VM memerlukan akses langsung ke server metadata. Jika VM berada di belakang proxy, Anda harus menetapkan konfigurasi NO_PROXY untuk alamat IP dan Nama Host.

Jika tidak menetapkan konfigurasi NO_PROXY, Anda mungkin akan melihat error saat menjalankan perintah Google Cloud CLI atau membuat kueri server metadata secara langsung karena panggilan ke metadata.google.internal akan dikirim ke proxy tanpa di-resolve secara lokal pada instance itu sendiri.

Berikut adalah contoh error yang mungkin Anda lihat:

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

Untuk mengatasi masalah proxy ini, tambahkan nama host server metadata dan alamat IP ke variabel lingkungan NO_PROXY dengan melakukan hal berikut:

Linux

Hubungkan ke VM Linux.

Dari VM Linux, jalankan perintah berikut:

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

Untuk menyimpan perubahan, jalankan perintah berikut:

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

Windows

Hubungkan ke VM Windows Anda.

Dari VM Windows Anda, jalankan perintah berikut:

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

Untuk menyimpan perubahan, jalankan perintah berikut:

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

Format tajuk salah

Server metadata melakukan pemeriksaan pemformatan untuk memastikan bahwa header mematuhi panduan pemformatan header RFC 7230 Bagian 3.2. Jika format header gagal, pemeriksaan berikut akan terjadi:

Permintaan diterima. Namun, Anda akan menerima rekomendasi bahwa Anda memiliki VM yang membuat permintaan ke server metadata dengan header yang tidak diformat dengan benar. Rekomendasi dikirim sekali per VM. Anda dapat mengakses rekomendasi ini dengan menggunakan Google Cloud CLI atau Recommender REST API.

Setelah Anda menerapkan rekomendasi, tetapkan status rekomendasi ke succeeded.
Mulai 20 Januari 2024, server metadata akan menolak permintaan apa pun yang memiliki header yang tidak diformat dengan benar.

Berikut ini contoh format permintaan header yang valid dan tidak valid.

Tidak valid: berisi spasi kosong antara nama header dan titik dua

Metadata-Flavor : Google

Valid: tidak ada spasi kosong antara nama header dan titik dua, spasi kosong setelah titik dua diabaikan oleh pemeriksa

Metadata-Flavor: Google

Valid: tidak ada spasi kosong di header

Metadata-Flavor:Google

Untuk mengetahui informasi lebih lanjut mengenai cara membuat kueri ke server metadata, baca Mengakses metadata VM.

Memecahkan masalah akses Server Metadata

Sebelum memulai

Konsol

gcloud

REST

Error yang biasa terjadi

Memecahkan masalah permintaan yang gagal ke server metadata

Linux

Windows

Memecahkan masalah permintaan yang gagal saat menggunakan proxy jaringan

Linux

Windows

Format tajuk salah