API Google lewat VPN: rutekan VIP, bukan hanya subnet

Masuk ke server lokal lewat SSH, naikkan tunnel, dan VM privat menjawab; kemudian panggilan pertama ke API Google gagal tanpa rute. Subnet VM dan alamat VIP API adalah tujuan yang berbeda, jadi rute untuk yang satu tidak memilih yang lain. Tiga syarat harus terpenuhi sebelum panggilan API privat bisa bekerja. Nama API harus diselesaikan menjadi VIP, prefiks VIP harus diiklankan melewati tunnel, dan VPC harus tahu cara mengirim balasan kembali. Ping tidak memberi tahu Anda hal itu, dan sesi SSH yang berfungsi ke mesin di subnet juga tidak.

Alamat VIP API adalah tujuan terpisah

Google menerbitkan VIP khusus untuk akses API dari jaringan lokal, dan itulah alamat yang harus dikembalikan DNS Anda untuk nama API. Keduanya prefiks kecil dan tidak satu pun merupakan ruang RFC 1918:

Alamat yang tampak publik tidak berarti rute harus keluar dari tunnel untuk internet biasa. Prefiks itu ada agar klien lokal dapat mencapai front end Google melalui jalur yang didukung, bukan lewat titik keluar sembarangan. Perlakukan sebagai tujuan yang termasuk tunnel, bukan sebagai host untuk dipindai. Aturan firewall yang ditulis untuk keluar internet biasanya membuangnya, dan itu alasan umum panggilan gagal sebelum dimulai.

DNS menentukan endpoint yang Anda capai

Arahkan resolver lokal ke record yang didokumentasikan Google untuk endpoint terpilih, agar nama yang dibutuhkan aplikasi dijawab dengan VIP tersebut. Hanya memetakan googleapis.com bukan inventaris: registry paket, registry kontainer, dan konektor migrasi punya nama terdokumentasi sendiri. VIP terbatas juga tidak membawa setiap layanan, jadi nama yang berhasil diselesaikan bisa tetap tidak didukung. Catat domain yang benar-benar dihubungi aplikasi sebelum Anda menyentuh resolver.

Menebak alamat VM di VPC sebagai pengganti nama layanan bukan perbaikan, dan biasanya menyembunyikan celah DNS sampai klien lain gagal.

Iklankan prefiks VIP, pertahankan sisanya

Dengan koneksi berbasis BGP, Cloud Router harus mengiklankan prefiks VIP terpilih agar router lokal mempelajari rentang itu melalui sesi yang dimaksud. Mengiklankan subnet VPC saja tidak menambahkan rentang itu, dan router lokal terus memakai jalur bawaannya untuk alamat tersebut. Prefiks di tabel routing adalah satu-satunya bukti bahwa iklan melewati sesi.

Pertahankan iklan yang ada saat menambahkan yang baru, karena opsi tingkat router dan tingkat peer punya jangkauan berbeda, dan menukar set dapat menarik jaringan yang sudah bekerja. Lalu periksa iklan efektif pada setiap sesi, bukan pada router secara keseluruhan. Prefiks yang hilang dan prefiks yang ditarik tampak sama dari sisi lokal, jadi tampilan sesi itulah yang memisahkan kelalaian dari regresi.

Sisi VPC perlu rute dan jalur balik sendiri

Di dalam VPC, jalur VIP harus memakai gateway internet bawaan sebagai hop berikutnya, dan meski namanya demikian trafik itu tetap di dalam jaringan Google. VPC juga perlu rute balik ke sumber lokal melalui VPN, yang merupakan objek terpisah dari prefiks yang diiklankan. Pertimbangkan persyaratan perutean regional yang didokumentasikan saat tunnel dan klien tidak berada di region yang sama.

Periksa jalur balik secara terpisah, karena arah permintaan yang bekerja dapat menyembunyikan arah balasan yang rusak. Dua arah, dua rute, dan masing-masing gagal dengan gejalanya sendiri.

Uji permintaan, lalu baca penolakannya

Gema ICMP tidak mendapat jawaban dari VIP ini, jadi ping yang gagal tidak membuktikan apa pun dan yang berhasil sangat sedikit. Dari klien sebenarnya, periksa jawaban nama dan rute yang dipilih, lalu buat permintaan HTTPS yang diizinkan ke layanan yang Anda pedulikan. Jika permintaan mencapai layanan dan ditolak, periksa kredensial, IAM, dan kebijakan perimeter layanan yang berlaku.

Perutean privat tidak memberikan otorisasi API dan tidak mengubah apa yang boleh dilakukan identitas. Keberhasilan transport dan balasan yang diotorisasi adalah hasil terpisah, dan Anda perlu keduanya. Jaga jalur IPv6 tetap eksplisit juga, karena mengonfigurasi prefiks IPv4 tidak mengatakan apa pun tentang klien yang memilih IPv6.

Panduan Google tentang Private Google Access dari jaringan lokal mencakup record DNS dan persyaratan perutean sekaligus, jadi bandingkan pengaturan resolver dan iklan Anda dengannya, bukan dengan kiriman forum. Lalu jalankan ulang permintaan yang sama dan catat jawaban serta rute di tiket yang sama.