Batas Cloud VPN yang tidak bisa Anda setel: masa hidup IKE dan NAT peer

Cloud VPN menegosiasikan masa hidup IKE dalam batas tetap dan memerlukan NAT satu-ke-satu di peer. Rencanakan perangkat jarak jauh berdasarkan itu, bukan berdasarkan sisi Google.

Beri perangkat jarak jauh masa hidup fase 1 selama 24 jam dan tunnel Cloud VPN tetap mati, padahal semua di sisi Google sudah dikonfigurasi dengan benar. Peer mengusulkan nilai yang tidak akan diterima responder, sehingga negosiasi gagal sepenuhnya atau terus dimulai ulang. Cloud VPN membatasi fase 1 pada 36,000 detik, sepuluh jam, dan batas itu bukan pengaturan yang bisa Anda naikkan. Perubahannya ada pada perangkat jarak jauh.

Peer bertanya, responder memutuskan

IKE adalah latihan pencocokan antara dua kumpulan proposal. Tunnel hanya terbentuk di tempat kumpulan itu saling tumpang tindih di dalam batas yang diterima responder, itulah sebabnya masa hidup di luar rentang tidak menghasilkan tunnel parsial sama sekali. Kesalahan umum adalah memperlakukan konfigurasi peer sebagai daftar keinginan, bukan sebagai proposal. Irisan kosong membuat tunnel tetap mati, seberapa pun benar routing dan selectornya.

Baca status tunnel itu sendiri sebelum membuka kasus, karena status terperinci biasanya menyebut tahap yang gagal:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Bandingkan hasil yang kembali dengan kumpulan yang didukung untuk jenis gateway dan versi IKE Anda, dan catat kedua traffic selector selagi Anda di sana. Ketidakcocokan selector memberi gejala tunnel mati yang sama seperti ketidakcocokan algoritme, dan berbeda dari algoritme, yang ini harus Anda perbaiki sendiri.

36,000 detik adalah plafonnya

Fase 1 berhenti pada 36,000 detik. Perangkat yang disetel ke 86,400 meminta sesuatu yang tidak akan pernah disetujui responder, dan mencoba lagi tidak mengubah pikirannya. Putar kembali proposal jarak jauh ke dalam rentang dan konfigurasi yang sama akan terbentuk; asimetri inilah seluruh pelajarannya, karena Anda dapat menurunkan nilai Anda sendiri dan tidak dapat menaikkan nilai Google.

Tulis nilai yang dipilih ke catatan desain. Jika tidak, insinyur berikutnya mengulang eksperimen 24 jam dan menabrak dinding yang sama.

Kumpulan yang didukung diterbitkan per jenis gateway dan versi IKE di ringkasan Cloud VPN, jadi bacalah bagian untuk topologi Anda, bukan panduan IKE umum.

Tunnel yang jatuh sesuai jadwal

Fase 2 berperilaku berbeda: bila kedua ujung tidak sepakat, pembaruan kunci mengikuti interval yang lebih pendek. Peer yang menganggap ketidakcocokan sebagai fatal justru menjatuhkan tunnel, sehingga satu ketidakcocokan bisa tampak seperti dua gangguan yang tidak terkait. Perhatikan irama pembaruan kunci, bukan hanya koneksi pertama. Tunnel yang naik lalu jatuh dengan ketukan teratur lebih sering merupakan ketidakcocokan masa hidup daripada cacat routing.

Korelasikan stempel waktu jatuh itu dengan log peer sendiri sebelum mengubah apa pun, karena perubahan selector atau rute dapat meniru irama yang sama. Jika ketukan cocok dengan pengatur waktu fase 2, penyebabnya sudah ditemukan tanpa menyentuh proposal.

Suite berasal dari jenis gateway

Suite cipher dan integritas bukan profil per tunnel yang Anda edit seperti yang diizinkan strongSwan. Anda memilihnya berdasarkan jenis gateway dan versi IKE, dan berburu profil yang tidak ada hanya membuang satu sore.

Perangkat lama yang tidak menawarkan apa pun di dalam kumpulan yang didukung menyisakan dua jalan jujur: ganti perangkat, atau akhiri di gateway perangkat lunak yang Anda kendalikan dan rutekan ke VPC dari sana. Apa pun selain itu adalah akal-akalan yang akan gagal pada tinjauan berikutnya.

Satu alamat eksternal per perangkat

Alamat eksternal peer harus dipetakan satu-ke-satu ke alamat internalnya. Kumpulan PAT yang kelebihan beban tidak dapat bekerja, karena beberapa host di belakang satu alamat publik tidak memberi responder cara untuk memisahkan mereka. Bila beberapa host harus berbagi alamat, tunnel harus berakhir di tempat yang dapat membedakan mereka.

Jaga juga alamat eksternal itu tetap stabil. Pindahkan perangkat ke belakang NAT lain dan asosiasinya putus meski setiap proposal masih cocok. Layak dicatat nilai mana milik Google dan mana milik Anda: masa hidup, suite, dan NAT satu-ke-satu tetap di sisi mereka, sedangkan proposal, selector, routing, dan prioritas BGP milik Anda.

Artikel terkait