Dayakan penghantaran IP pada gateway GCE VPN sedia ada

VM dicipta tanpa penghantaran IP, ia sudah menjalankan perisian VPN, dan naluri ialah membinanya semula daripada templat dengan bendera dihidupkan. Pembinaan semula itu tidak perlu. Compute Engine mendedahkan canIpForward sebagai sifat boleh dikemas kini, dan laluan kemas kini yang didokumenkan menggunakannya dengan refresh dan bukan mula semula. Apa yang sebenarnya dikawal oleh bendera itu sempit: tanpanya, platform menggugurkan paket yang tiba di instans tetapi tidak dialamatkan ke alamat instans itu sendiri. Gateway yang menghantar trafik mesin lain melakukan tepat perkara itu, jadi bendera itu mesti dihidupkan. Semua selepas itu ialah konfigurasi tetamu dan penghalaan, yang tidak disentuh oleh bendera itu.

Apa yang dibenarkan oleh bendera itu, dan apa yang tidak

Apabila penghantaran dilumpuhkan, platform menganggap instans sebagai titik akhir. Paket yang destinasinya ialah alamat instans itu sendiri dihantar; paket yang sepatutnya dihantar terus oleh instans bagi pihak orang lain tidak dihantar.

Apabila penghantaran dihidupkan, instans boleh bertindak sebagai hop seterusnya untuk laluan VPC, dan itulah peranan yang diperlukan oleh perkakas VPN. Bendera itu tidak berkata apa-apa tentang tembok api, penghalaan tetamu, konfigurasi terowong atau laluan balik, dan nilai true pada gateway yang rosak masih gateway yang rosak.

Baca sifat semasa

Periksa tetapan sebelum mengubah apa-apa, dengan describe baca-sahaja terhadap instans, projek dan zon yang dimaksudkan:

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

Nilai false hanya penting jika VM ini bertujuan menjadi hop seterusnya. Jika ya, seluruh laluan itu masih perlu diperiksa secara berasingan, kerana sifat itu satu baris dalam rantaian yang lebih panjang.

Kemas kini instans sedia ada

Prosedur kemas kini sifat instans Google mengeksport sumber semasa, mengubah sifat dan menyerahkan hasilnya. Itu aliran kerja yang berbeza daripada bendera --can-ip-forward semasa penciptaan, dan itulah yang berfungsi pada VM yang sedang berjalan.

Eksport definisi ke fail setempat dahulu, dan simpan salinan tidak berubah untuk perbandingan:

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

Dalam fail yang dieksport itu, tetapkan sifat dan jangan ubah apa-apa lagi:

canIpForward: true

Kekalkan seluruh sumber, termasuk cap jarinya. Menggantikan fail dengan dokumen YAML satu baris, atau menggabungkan suntingan tidak berkaitan pada jenis mesin, cakera atau antara muka ke dalam penghantaran yang sama, ialah cara perubahan sifat menjadi gangguan.

Minta mekanisme kemas kini mengesahkan fail dan melaporkan apa yang diperlukan, sebelum sebarang perubahan berkesan dibenarkan:

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

Larian pengesahan itu tidak menghidupkan penghantaran. Baca respons untuk sifat tidak sah dan untuk tindakan yang dikatakan diperlukan. Untuk perubahan terpencil ini, tindakan yang didokumenkan ialah REFRESH. Jika hasilnya meminta mula semula, fail itu mengandungi lebih daripada sifat yang anda mahu ubah, jadi periksanya dan bukannya meluluskan mula semula.

Gunakan fail yang telah disemak dengan had refresh:

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

Periksa bahawa operasi selesai dan jalankan arahan describe sekali lagi. Jika cap jari tidak lagi sepadan, orang lain telah mengubah instans semasa anda menyunting, jadi eksport salinan baharu dan semak semula perubahan itu dan bukannya memaksa fail lama anda.

Tetamu masih perlu menghalakan paket

Kebenaran awan tidak menjadikan perkakas itu penghala. Sahkan bahawa laluan VPC memilih VM ini sebagai hop seterusnya untuk awalan destinasi, dan tetamu menghalakan antara terowong dan antara muka yang betul dengan dasar penghantaran sendiri dihidupkan.

Dasar tembok api mesti membenarkan aliran dalam serta pendengar luar. Membuka hanya port VPN menerangkan pengangkutan disulitkan dan tidak berkata apa-apa tentang pertukaran aplikasi di dalamnya.

Akhir sekali, destinasi memerlukan laluan balik ke kumpulan klien, atau reka bentuk mesti menterjemah sumber secara sengaja. Jika destinasi melihat trafik terjemahan, periksa sumber terjemahan; jika reka bentuk mengekalkan kumpulan itu, periksa kumpulan itu dalam laluan balik dan peraturan akses. Menambah NAT sebelum memutuskan reka bentuk mana yang anda mahu menyembunyikan laluan yang hilang dan mengubah dasar yang dilihat oleh destinasi.

Pada gateway Linux, penghantaran kernel ialah sebahagian daripada konfigurasi tetamu. Perkakas pfSense mempunyai setara sendiri, dan menyalin arahan sysctl Linux ke dalamnya bukan langkah yang sepadan.

Sahkan daripada klien yang memerlukan akses

Uji daripada klien VPN ke satu perkhidmatan sasaran, bukan daripada gateway itu sendiri. Sambungan yang dimulakan pada gateway menggunakan sumber berbeza dan tidak pernah melaksanakan peraturan penghantaran yang baru anda hidupkan.

Catat sifat itu dalam apa sahaja yang mengurus perkakas. VM yang dibetulkan secara manual berfungsi sehingga penggantian seterusnya mengembalikan tetapan asal secara senyap, dan kegagalan itu akan kelihatan seperti regresi dalam perisian VPN.

Urutan kerja: baca sifat, eksport dan sunting satu baris, sahkan dengan NO_EFFECT, gunakan dengan REFRESH, pastikan tetamu menghantar, kemudian uji daripada klien.