Cloud SQL Auth Proxy berbanding laluan VPN terus ke pangkalan data
Auth Proxy dan laluan VPN terus menyelesaikan dua separuh masalah yang sama. Bandingkan dahulu kebenaran penyambung, port dan log masuk pangkalan data.
Terdapat dua cara wajar untuk mencapai instans Cloud SQL peribadi dari komputer riba di VPN. Satu ialah sambungan terus ke alamat peribadi instans melalui laluan yang anda sudah ada. Satu lagi ialah Cloud SQL Auth Proxy, yang mendengar pada loopback dan membuka sendiri sambungan ke Cloud SQL. Kedua-duanya bukan produk pesaing tetapi dua jawapan berbeza kepada soalan siapa memegang kelayakan dan siapa memegang laluan. Pilihan yang salah biasanya muncul sebagai ralat kebenaran yang dibaca seperti ralat rangkaian.
Berikut ialah perbandingan yang akan saya letakkan di hadapan pasukan, diikuti dengan semakan yang benar-benar memutuskannya.
Dua laluan ke instans yang sama
Laluan terus menggunakan laluan private-services-access dari rangkaian anda ke VPC projek. Klien anda bercakap PostgreSQL dengan alamat peribadi instans, dan sambungan hidup atau mati pada penghalaan, peraturan firewall dan kelayakan pangkalan data.
Laluan proksi menggunakan laluan yang sama tetapi menambah proses setempat. Proksi mengesahkan diri ke Google API dengan default credentials aplikasi anda, membuka sambungan ke instans melalui penyambung dan mendedahkan port loopback yang dianggap klien anda sebagai PostgreSQL. Dua lompatan menjadi tiga, dan yang di tengah membawa kebenaran IAM. Laluan VPN masih milik anda untuk diselenggara, dan proksi tidak pernah menganggapnya pengganti semakan itu.
Apa yang sebenarnya dibenarkan oleh setiap laluan
Perbezaan yang paling penting ialah apa yang boleh dibenarkan oleh setiap pilihan untuk anda:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
Semakan IAM proksi dan log masuk pangkalan data ialah dua pintu berasingan, dan melalui satu tidak membuka yang lain. Pasukan yang mengaktifkan proksi dan menganggap akaun aplikasi tidak lagi diperlukan akan menghabiskan sebelah petang pada kegagalan kata laluan yang tiada kaitan dengan rangkaian.
Port dan laluan, bersebelahan
Proksi memerlukan TCP 443 keluar untuk API dan TCP 3307 untuk sambungan instans, kedua-duanya diterangkan dalam gambaran keseluruhan Auth Proxy Google. Laluan VPN anda meliputi yang kedua; yang pertama biasanya keluar melalui laluan biasa.
Sambungan terus memerlukan port PostgreSQL instans boleh dicapai melalui laluan peribadi, yang merupakan perbualan firewall yang sama sekali berbeza. Jika pasukan rangkaian anda hanya membenarkan 443 keluar dari subnet klien, proksi sesuai tanpa perubahan peraturan dan laluan terus tidak. Satu fakta itu menentukan pilihan lebih kerap daripada mana-mana keutamaan seni bina.
Tiada satu pun laluan memerlukan instans mempunyai alamat awam, dan tiada satu pun yang mewajarkan menambah satu.
Di mana proksi tidak membantu
Proksi tidak membaiki laluan yang hilang. Jika laluan private-services-access tiada, atau VPN tidak membawanya, penyambung gagal sementara pendengar setempat masih duduk di situ mendengar, dan itulah bahagian yang mengelirukan.
Ia juga tidak melindungi bahagian antara aplikasi anda dan proksi. Pada satu komputer riba bahagian itu ialah loopback dan ia baik. Jika anda mengikat pendengar ke alamat wildcard supaya rakan sekerja boleh mencapainya, anda telah membina get laluan pangkalan data tanpa pengesahan dan memanggilnya kemudahan. Biarkan ia pada loopback dan biarkan rakan sekerja memperoleh kelayakannya sendiri.
Dan ia tidak menjadikan Private Service Connect dan private services access boleh ditukar ganti. Instans PSC memerlukan susunan DNS sendiri dan panggilan --psc dan bukannya bentuk --private-ip.
Memilih, kemudian mengesahkan dalam apa jua cara
Pilih proksi apabila anda mahu IAM dalam laluan, kelayakan jangka pendek dan tiada perubahan firewall masuk.
Pilih laluan terus apabila klien yang disokong sudah memegang kelayakan pangkalan data yang kukuh dan pasukan rangkaian selesa membuka port. Dalam apa jua cara, sahkan dengan pertanyaan sebenar dan bukannya sambungan berjaya: sambung, jalankan satu bacaan pada jadual yang diketahui dan periksa apa yang pelayan lihat tentang sesi anda.
Selepas VPN disambung semula, layan kelayakan yang tamat tempoh, laluan peribadi yang hilang dan penolakan log masuk pangkalan data sebagai tiga kegagalan berbeza. Hanya satu daripadanya masalah rangkaian, dan hanya satu yang sepatutnya membawa kepada perubahan peraturan firewall.