IP privat Cloud SQL lewat VPN: rute yang tidak diekspor siapa pun

Banyak tim percaya IP privat Cloud SQL hanya berfungsi dari dalam VPC, dan keyakinan itu bertahan karena kegagalannya terlihat seperti masalah basis data. Google mendokumentasikan akses dari jaringan yang terhubung melalui Cloud VPN atau Cloud Interconnect. Yang dibutuhkan jaringan itu bukan fitur basis data khusus, melainkan dua pertukaran rute yang mudah dibiarkan setengah terkonfigurasi. Tunnel menyala, instans komputasi menjawab, dan koneksi basis data habis waktu — persis kombinasi yang mengirim orang ke konsol yang salah.

Mitos: IP privat berarti privat bagi VPC

Akses layanan privat adalah peering VPC antara jaringan Anda dan jaringan produsen milik Google. Rentang yang dialokasikan untuk layanan berada di sisi produsen, dan alamat instans ada di dalamnya. Peering itulah sebabnya basis data di proyek Anda bisa berada di alamat yang dirutekan VPC Anda tanpa ada subnet eksplisit Anda yang memuatnya.

Karena ini peering, ia juga punya perilaku peering, termasuk bagian di mana rute kustom tidak menyeberang secara otomatis.

Mitos: tunnel yang berfungsi membawa rute basis data bersamanya

Dua rentang harus selamat dalam perjalanan. Yang pertama adalah prefiks klien: jaringan lokal Anda harus dikenal Cloud Router dengan prefiks tertentu, karena rute default tidak dapat memasok impor yang dibutuhkan jaringan produsen untuk jalur balik. Yang kedua adalah rentang layanan yang dialokasikan, yang harus dipelajari sisi eksternal agar paketnya menuju basis data punya tujuan. Keduanya rute berbeda yang dipelihara di batas berbeda, dan memperbaiki satu meninggalkan yang lain rusak.

Di sisi Google, itu berarti mengaktifkan Export custom routes pada koneksi peering yang relevan dan menambahkan rentang layanan yang dialokasikan ke rute yang diiklankan Cloud Router untuk tunnel.

Pertahankan iklan yang sudah ada. Menambahkan rentang layanan tidak boleh menghapus rute VPC yang dibawa sesi BGP yang sama untuk lalu lintas lain, dan kumpulan iklan yang diganti seluruhnya adalah gangguan kedua yang bersembunyi di balik yang pertama. Periksa juga rute efektif di perangkat eksternal, karena bisa mencapai gateway VPN atau subnet lain hanya membuktikan transport.

Mitos: Cloud SQL Auth Proxy menyelesaikan masalah jaringan

The Auth Proxy menyediakan autentikasi yang didukung dan transport terenkripsi antara aplikasi Anda dan instans. Ia tidak membuat rute. Proksi yang dijalankan pada host tanpa jalur ke jaringan privat akan gagal persis seperti koneksi langsung, dan lognya kurang membantu soal penyebabnya. Memindahkan proksi ke host yang punya konektivitas mengubah bagian jalur mana yang harus berfungsi, dan itu keputusan desain nyata, bukan akal-akalan.

Yang tidak dilakukannya adalah membuat laptop yang terputus bisa mencapai instans yang hanya privat.

Mitos: Private Service Connect mengikuti aturan yang sama

Private Service Connect memakai endpoint di subnet Anda sendiri dan pengaturan DNS yang Anda kendalikan, jadi rute ke sana adalah rute biasa ke alamat yang Anda miliki. Pengaturan ekspor peering tidak berlaku untuk desain itu, dan menyalin perubahan peering ke penerapan PSC menambah risiko tanpa menambah keterjangkauan.

Keduanya memberi Anda alamat privat; kemiripannya berhenti di situ.

Uji jalur dalam urutan yang benar

Dari klien eksternal, uji endpoint TCP basis data lebih dulu. Jabat tangan TCP yang selesai berarti perutean, firewall, dan pendengar semuanya ada, dan uji berikutnya adalah operasi terautentikasi yang diizinkan. Penolakan autentikasi justru kabar baik pada titik itu, karena membuktikan pendengar basis data menjawab. Timeout ICMP hampir tidak mengatakan apa pun tentang akses basis data, sebab banyak jalur membuangnya sambil meneruskan TCP dengan lancar.

Jika rentang klien Anda di luar RFC 1918, tinjau persyaratan tambahan ekspor rute dan otorisasi jaringan sebelum menyimpulkan bahwa desainnya tidak didukung.

Catat empat objek bersama koneksi: prefiks eksternal, rentang layanan yang dialokasikan, koneksi peering yang terlibat, dan router yang mengiklankan. Keempatnya menjelaskan seluruh jalur privat, dan menggantikan mitos bahwa Cloud SQL selalu butuh proksi atau sama sekali tidak terjangkau lewat VPN.