VM dibuat tanpa penerusan IP, sudah menjalankan perangkat lunak VPN, dan dorongan pertama adalah membangunnya ulang dari templat dengan tanda diaktifkan. Pembangunan ulang itu tidak perlu. Compute Engine mengekspos canIpForward sebagai properti yang dapat diperbarui, dan jalur pembaruan yang didokumentasikan menerapkannya dengan refresh alih-alih mulai ulang. Yang sebenarnya dikendalikan tanda itu sempit: tanpanya, platform membuang paket yang tiba di instans tetapi tidak dialamatkan ke alamat instans itu sendiri. Gateway yang meneruskan lalu lintas mesin lain melakukan tepat itu, jadi tanda itu harus aktif. Semua setelah itu adalah konfigurasi tamu dan perutean, yang tidak disentuh tanda tersebut.

Apa yang diizinkan tanda itu, dan apa yang tidak

Saat penerusan dinonaktifkan, platform memperlakukan instans sebagai titik akhir. Paket yang tujuannya adalah alamat instans itu sendiri dikirimkan; paket yang seharusnya diteruskan instans atas nama pihak lain tidak.

Saat penerusan diaktifkan, instans dapat bertindak sebagai hop berikutnya untuk rute VPC, dan itulah peran yang dibutuhkan peralatan VPN. Tanda itu tidak mengatakan apa pun tentang firewall, perutean tamu, konfigurasi terowongan, atau jalur balik, dan nilai true pada gateway yang rusak tetap gateway yang rusak.

Baca properti saat ini

Periksa pengaturan sebelum mengubah apa pun, dengan describe hanya-baca terhadap instans, proyek, dan zona yang dimaksud:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Nilai false hanya penting jika VM ini dimaksudkan sebagai hop berikutnya. Jika ya, sisa jalurnya tetap harus diperiksa secara terpisah, karena properti ini satu baris dalam rantai yang lebih panjang.

Perbarui instans yang sudah ada

Prosedur pembaruan properti instans Google mengekspor sumber daya saat ini, mengubah properti, dan mengirimkan hasilnya. Itu alur kerja yang berbeda dari tanda --can-ip-forward saat pembuatan, dan itulah yang berfungsi pada VM yang sedang berjalan.

Ekspor definisi ke berkas lokal terlebih dahulu, dan simpan salinan tanpa perubahan untuk perbandingan:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

Di berkas yang diekspor itu, atur properti dan jangan ubah apa pun selain itu:

canIpForward: true

Pertahankan seluruh sumber daya, termasuk sidik jarinya. Mengganti berkas dengan dokumen YAML satu baris, atau menggabungkan perubahan tak terkait pada tipe mesin, disk, atau antarmuka ke dalam pengiriman yang sama, adalah cara perubahan properti menjadi gangguan layanan.

Minta mekanisme pembaruan memvalidasi berkas dan melaporkan apa yang diperlukan, sebelum perubahan efektif apa pun diizinkan:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Jalan validasi itu tidak mengaktifkan penerusan. Baca responsnya untuk properti yang tidak valid dan untuk tindakan yang dikatakannya diperlukan. Untuk perubahan terisolasi ini, tindakan yang didokumentasikan adalah REFRESH. Jika hasilnya meminta mulai ulang, berkas itu memuat lebih dari properti yang ingin Anda ubah, jadi periksa saja alih-alih mengabulkan mulai ulang.

Terapkan berkas yang telah ditinjau dengan batas refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Periksa bahwa operasi selesai dan jalankan perintah describe lagi. Jika sidik jari tidak lagi cocok, orang lain mengubah instans saat Anda menyunting, jadi ekspor salinan baru dan tinjau perubahannya lagi alih-alih memaksakan berkas lama Anda.

Tamu tetap harus merutekan paket

Izin cloud tidak membuat peralatan menjadi router. Pastikan rute VPC memilih VM ini sebagai hop berikutnya untuk prefiks tujuan, dan tamu merutekan antara terowongan dan antarmuka yang tepat dengan kebijakan penerusannya sendiri diaktifkan.

Kebijakan firewall harus mengizinkan aliran dalam serta pendengar luar. Membuka hanya port VPN menjelaskan transport terenkripsi dan tidak mengatakan apa pun tentang pertukaran aplikasi di dalamnya.

Akhirnya, tujuan memerlukan jalur balik ke kumpulan klien, atau desainnya harus menerjemahkan sumber dengan sengaja. Jika tujuan melihat lalu lintas yang diterjemahkan, periksa sumber yang diterjemahkan; jika desain mempertahankan kumpulan, periksa kumpulan itu di rute balik dan aturan akses. Menambahkan NAT sebelum memutuskan desain mana yang Anda inginkan menyembunyikan rute yang hilang dan mengubah kebijakan yang dilihat tujuan.

Pada gateway Linux, penerusan kernel adalah bagian dari konfigurasi tamu. Peralatan pfSense punya padanannya sendiri, dan menyalin perintah sysctl Linux ke dalamnya bukan langkah yang sesuai.

Verifikasi dari klien yang membutuhkan akses

Uji dari klien VPN ke satu layanan target, bukan dari gateway itu sendiri. Koneksi yang dimulai di gateway memakai sumber berbeda dan tidak pernah melatih aturan penerusan yang baru Anda aktifkan.

Catat properti itu di apa pun yang mengelola peralatan. VM yang dikoreksi secara manual berfungsi sampai penggantian berikutnya diam-diam mengembalikan pengaturan aslinya, dan kegagalan itu akan terlihat seperti regresi pada perangkat lunak VPN.

Urutan kerja: baca properti, ekspor dan sunting satu baris, validasi dengan NO_EFFECT, terapkan dengan REFRESH, pastikan tamu meneruskan, lalu uji dari klien.

Artikel terkait