Akses pengembang jarak jauh ke VPC Google Cloud: pilih jalurnya

Seorang pengembang membutuhkan satu sesi SSH, satu port basis data, atau akses luas ke selusin layanan privat, dan setiap permintaan itu tampak seperti pertanyaan yang sama. Tidak. Tujuan, protokol, dan identitas yang terlibat menentukan jalur akses Google Cloud mana yang cocok, dan memilih yang terluas secara default menciptakan pekerjaan yang tidak perlu Anda miliki.

Tuliskan tujuan dan protokolnya

Buat daftar alamat privat, port, dan protokol yang benar-benar dibutuhkan pekerjaan, lalu tandai identitas mana yang harus diautentikasi secara terpisah. Port basis data dan zona DNS privat adalah persyaratan yang berbeda, dan layanan UDP sepenuhnya menyingkirkan salah satu opsi di bawah. Daftar tertulis juga menunjukkan apa yang tidak Anda berikan. Itulah bagian yang ditanyakan pengulas.

Lakukan ini sebelum membuka listener. Daftar itu nanti menjadi uji penerimaan, dan itulah satu-satunya cara andal untuk membedakan terowongan sempit dari terowongan luas yang kebetulan berfungsi.

IAP untuk beberapa layanan TCP

Penerusan TCP Identity-Aware Proxy memberikan terowongan terautentikasi ke resource VM yang memenuhi syarat tanpa mengekspos layanan ke internet. Bentuk sehari-harinya adalah gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, dan satu port dapat diteruskan secara lokal dengan gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Tiga hal harus selaras: pemanggil memerlukan peran akses terowongan IAP, firewall harus mengizinkan rentang sumber IAP, dan tujuan harus dapat dijangkau pada instance. Otorisasi untuk membuat terowongan bukanlah kredensial basis data, login SSH, atau sesi RDP, jadi simpan autentikasi aplikasi di tempat yang semestinya.

Penerusan TCP IAP bukan VPN lapisan tiga. Ia membawa TCP ke tujuan yang dipilih, bukan lalu lintas IP sembarang atau UDP, dan kurang cocok ketika aplikasi membutuhkan DNS privat di banyak layanan.

VPN akses jarak jauh untuk jangkauan yang lebih luas

Ketika beberapa tujuan, protokol, atau zona DNS privat diperlukan, bentuk yang lebih baik adalah VPN akses jarak jauh yang dikelola secara eksplisit pada VM atau perangkat yang didukung. Penerapan itu terpisah dari Cloud VPN yang dikelola Google: Anda memiliki pendaftaran identitas klien, pembaruan perangkat lunak, rute klien, dan rute balik VPC.

Rencanakan seluruh daftar, bukan hanya listener publik. Sertakan kumpulan terowongan, rute VPC kembali ke sana, kontrol penerusan, resolusi DNS, dan kebijakan akses per layanan. VPN yang terhubung tetapi tidak dapat menyelesaikan nama internal menggagalkan alur kerja pengembang sama tuntasnya dengan VPN yang tidak pernah terhubung.

Cloud VPN adalah gateway situs, bukan profil laptop

Google Cloud VPN menghubungkan gateway rekan melalui IPsec, dan pertanyaan umum-nya memisahkan peran situs-ke-situs itu dari akses klien-ke-gateway. Membuat terowongan tidak menghasilkan profil yang diimpor karyawan di laptop. Perbedaannya penting ketika seseorang meminta profil Cloud VPN. Jawabannya adalah produk lain.

Yang dilakukan gateway dengan baik adalah memberi mesin di belakang jaringan kantor rute masuk ke VPC. Gateway tidak mengautentikasi setiap karyawan atau memberi izin aplikasi, jadi kebijakan itu tetap berada di lapisan jaringan dan aplikasi tempat kebijakan dapat ditegakkan per identitas.

Verifikasi dan catat

Uji tujuan tersempit terlebih dahulu, lalu yang memerlukan DNS, lalu tujuan yang harus tetap ditolak. Jalankan setiap uji dari klien yang sama yang akan memakai jalur itu di produksi, karena uji yang berhasil dari stasiun kerja administrator tidak membuktikan banyak tentang laptop pengembang dengan jaringan berbeda.

Catat model yang dipilih, tujuan yang dicakupnya, identitas yang diautentikasinya, dan perilaku kegagalan saat jalur tidak tersedia. Catatan itulah yang mencegah permintaan berikutnya diam-diam memperlebar terowongan alih-alih menambahkan satu tujuan ke desain yang terdokumentasi.