API Google melalui VPN: halakan VIP, bukan subnet sahaja
Laluan ke subnet VPC tidak memilih alamat VIP API. Selesaikan nama yang betul, iklankan awalan VIP, kekalkan laluan balik dalam VPC, kemudian uji HTTPS.
Masuk ke pelayan tempatan melalui SSH, naikkan terowong dan VM persendirian menjawab; kemudian panggilan pertama ke API Google gagal tanpa laluan. Subnet VM dan alamat VIP API ialah destinasi berbeza, jadi laluan untuk satu tidak memilih yang lain. Tiga syarat mesti dipenuhi sebelum panggilan API persendirian boleh berfungsi. Nama API mesti diselesaikan kepada VIP, awalan VIP mesti diiklankan merentas terowong, dan VPC mesti tahu cara menghantar balasan kembali. Ping tidak memberitahu anda apa-apa tentang itu, dan sesi SSH yang berfungsi ke mesin dalam subnet juga tidak.
Alamat VIP API ialah destinasi berasingan
Google menerbitkan VIP khusus untuk akses API dari rangkaian tempatan, dan itulah alamat yang DNS anda mesti kembalikan untuk nama API. Kedua-duanya awalan kecil dan tiada satu pun ruang RFC 1918:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
Alamat yang kelihatan awam tidak bermakna laluan harus meninggalkan terowong untuk internet biasa. Awalan itu wujud supaya klien tempatan dapat mencapai bahagian hadapan Google melalui laluan yang disokong dan bukan titik keluar sewenang-wenangnya. Anggap ia destinasi yang tergolong dalam terowong, bukan hos untuk diuji. Peraturan tembok api yang ditulis untuk keluar internet biasanya membuangnya, dan itulah sebab biasa panggilan gagal sebelum bermula.
DNS menentukan titik akhir yang anda capai
Halakan penyelesai tempatan ke rekod yang didokumenkan Google untuk titik akhir dipilih, supaya nama yang diperlukan aplikasi menjawab dengan VIP itu. Semata-mata googleapis.com bukan inventori: daftar pakej, daftar kontena dan penyambung migrasi mempunyai nama terdokumen mereka sendiri. VIP terhad juga tidak membawa setiap perkhidmatan, jadi nama yang diselesaikan mungkin masih tidak disokong. Catat domain yang benar-benar dihubungi aplikasi sebelum anda menyentuh penyelesai.
Meneka alamat VM dalam VPC sebagai pengganti nama perkhidmatan bukan pembaikan, dan ia biasanya menyembunyikan jurang DNS sehingga klien lain gagal.
Iklankan awalan VIP, kekalkan selebihnya
Dengan sambungan berasaskan BGP, Cloud Router mesti mengiklankan awalan VIP yang dipilih supaya penghala tempatan mempelajari julat itu melalui sesi yang dimaksudkan. Mengiklankan subnet VPC sahaja tidak menambah julat itu, dan penghala tempatan terus menggunakan laluan lalainya untuk alamat tersebut. Awalan dalam jadual penghalaan ialah satu-satunya bukti bahawa iklan merentasi sesi.
Kekalkan iklan sedia ada semasa menambah yang baharu, kerana pilihan peringkat penghala dan peringkat rakan mempunyai jangkauan berbeza, dan menukar set boleh menarik balik rangkaian yang sudah berfungsi. Kemudian periksa iklan berkesan pada setiap sesi dan bukan pada penghala keseluruhan. Awalan yang hilang dan awalan yang ditarik balik kelihatan sama dari sisi tempatan, jadi paparan sesi itulah yang memisahkan kelalaian daripada regresi.
Sisi VPC perlu laluan dan laluan balik sendiri
Di dalam VPC, laluan VIP mesti menggunakan get laluan internet lalai sebagai hop seterusnya, dan walaupun namanya begitu trafik itu kekal dalam rangkaian Google. VPC juga perlu laluan balik ke sumber tempatan melalui VPN, yang merupakan objek berasingan daripada awalan yang diiklankan. Ambil kira keperluan penghalaan serantau yang didokumenkan apabila terowong dan klien tidak berada di rantau yang sama.
Periksa laluan balik secara berasingan, kerana arah permintaan yang berfungsi boleh menyembunyikan arah balasan yang rosak. Dua arah, dua laluan, dan setiap satu gagal dengan simptomnya sendiri.
Uji permintaan, kemudian baca penolakan
Gema ICMP tidak mendapat balasan daripada VIP ini, jadi ping yang gagal tidak membuktikan apa-apa dan yang berjaya membuktikan sangat sedikit. Daripada klien sebenar, periksa jawapan nama dan laluan yang dipilih, kemudian buat permintaan HTTPS yang dibenarkan kepada perkhidmatan yang anda ambil berat. Jika permintaan sampai ke perkhidmatan dan ditolak, lihat kelayakan, IAM dan mana-mana dasar perimeter perkhidmatan yang terpakai.
Penghalaan persendirian tidak memberi kebenaran API dan tidak mengubah apa yang dibenarkan untuk identiti lakukan. Kejayaan pengangkutan dan balasan yang dibenarkan ialah hasil berasingan, dan anda perlukan kedua-duanya. Kekalkan laluan IPv6 juga eksplisit, kerana mengkonfigurasi awalan IPv4 tidak berkata apa-apa tentang klien yang mengutamakan IPv6.
Panduan Google tentang Private Google Access dari rangkaian tempatan merangkumi rekod DNS dan keperluan penghalaan sekali gus, jadi bandingkan tetapan penyelesai dan iklan anda dengannya dan bukan dengan kiriman forum. Kemudian jalankan semula permintaan yang sama dan catat jawapan serta laluan dalam tiket yang sama.