Cloud Run ke VPN lokal: menyiapkan Direct VPC egress

Tunnel aktif, VM mencapai server lokal, tetapi layanan Cloud Run kehabisan waktu pada host yang sama. Itu titik awal yang normal untuk tugas ini, dan tunnel jarang menjadi penyebabnya. Revisi Cloud Run tidak berada di VPC Anda secara default, dan setelah berada di sana, revisi itu memakai alamat sumbernya sendiri, bukan subnet VM yang sudah Anda rutekan. Runbook berikut melampirkan layanan, merutekan rentang sumber sebenarnya, lalu membuktikan jalur dari revisi yang melayani permintaan. Jalankan dalam urutan itu, karena melewati langkah pertama adalah alasan begitu banyak kasus berakhir dengan perubahan VPN yang tidak memperbaiki apa pun.

Lampirkan revisi sebelum men-debug tunnel

Cloud Run mendukung Direct VPC egress, yang menaruh lalu lintas layanan pada subnet di VPC Anda tanpa konektor Serverless VPC Access. Untuk layanan yang sudah ada, pembaruannya terlihat seperti ini:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Ganti placeholder, tinjau apa yang dilakukan deployment terhadap lalu lintas langsung, dan pilih subnet di region layanan dengan kapasitas alamat yang cukup dan izin jaringan yang tepat.

Pilih mode egress yang sesuai dengan tujuan

private-ranges-only mengirim tujuan yang diklasifikasikannya sebagai privat melalui VPC. Itu tidak berarti «apa pun yang dapat dijangkau melalui VPN», dan celah itu muncul ketika layanan lokal berada di rentang yang tidak diklasifikasikan seperti itu oleh pengaturan. Jika tujuan tidak tercakup, all-traffic adalah mode terdokumentasi lainnya, dan ia mengirim semua melalui VPC, termasuk dependensi publik layanan. Pilih dengan sadar dan tulis konsekuensinya di catatan perubahan.

Layanan yang sudah memakai konektor memerlukan migrasi, bukan tombol, jadi rencanakan itu alih-alih mengonfigurasi keduanya.

Rutekan sumber Cloud Run, bukan sumber VM

Direct VPC egress mengalokasikan alamat sementara dari subnet yang dipilih, dan sisi lokal harus mengembalikan lalu lintas ke rentang itu. Rute balik atau izin firewall yang ditulis untuk subnet VM lain akan tampak benar di diagram dan gagal dalam praktik. Ambil CIDR subnet dari VPC, bukan dari ingatan, lalu pastikan ACL kripto atau tabel rute perangkat jarak jauh memuatnya.

Dengan perutean dinamis, verifikasi apa yang sebenarnya diiklankan Cloud Router dan apa yang diimpor VPC, termasuk kebijakan iklan khusus apa pun. Rute yang ada di konsol tetapi tidak dipilih untuk tujuan ini sama saja dengan tidak ada rute.

Tiga kondisi yang semuanya harus terpenuhi

Jalur yang berfungsi membutuhkan semua berikut, dan masing-masing gagal dengan caranya sendiri:

• Rute di VPC menuju prefiks lokal melalui koneksi Cloud VPN yang dimaksud.
• Rute balik di sisi lokal untuk subnet Cloud Run.
• Cakupan perlindungan firewall dan IPsec yang mengizinkan sumber, tujuan, dan port.

Rute yang hilang biasanya tampak seperti waktu tunggu habis tanpa bukti di sisi jarak jauh. Masalah rute balik tampak seperti permintaan yang datang dan balasan yang menghilang. Masalah firewall atau selector bisa tampak seperti penolakan atau seperti drop senyap, tergantung perangkat. Menentukan mana dari ketiganya yang Anda hadapi sangat mempersempit perintah berikutnya.

Jangan masukkan satu alamat Cloud Run sementara ke daftar izin. Gunakan rentang subnet dan desain otorisasi yang sesuai dengan aplikasi.

Uji revisi yang melayani permintaan

Periksa pengaturan jaringan yang diterapkan dan alokasi lalu lintas sebelum menguji, karena pembaruan dapat membuat revisi baru sementara permintaan masih mencapai revisi lama. Lalu jalankan operasi yang sama dengan yang dilakukan permintaan pengguna, dari revisi itu. Jika tujuan adalah nama host privat, periksa resolusinya di lingkungan itu dan alamat yang dihasilkannya, karena jawaban DNS korporat dari laptop Anda tidak membuktikan apa pun tentang namespace layanan. Pertahankan verifikasi nama host TLS dan autentikasi aplikasi jarak jauh itu sendiri.

Perkirakan penundaan koneksi awal Direct VPC yang terdokumentasi, dan beri klien strategi kesiapan atau coba ulang alih-alih mendiagnosis setiap cold start sebagai tunnel rusak.

Rollback dan apa yang tidak dilakukan ini

Untuk rollback, kembalikan pengaturan jaringan dan egress layanan ke nilai sebelumnya dan pastikan revisi sebelumnya masih melayani lalu lintas. Simpan perintah gcloud di catatan perubahan, karena kebalikan dari perubahan sebagian tidak jelas enam minggu kemudian. Melepas lampiran VPC mengembalikan layanan ke jalur egress sebelumnya, yang mungkin justru yang Anda inginkan selama insiden.

Desain ini mencakup koneksi yang dimulai Cloud Run dan balasannya. Ini tidak memberi jaringan lokal soket yang dapat dialamati di dalam layanan, karena paparan masuk adalah keputusan ingress.