GCP HA VPN menolak FortiGate: tipe ID lokal tidak cocok
Google membandingkan identitas yang diklaim FortiGate, bukan hanya kunci yang dibagikan sebelumnya. ID lokal bertipe FQDN gagal pada pemeriksaan itu sementara log masih menyebut autentikasi.
AUTHENTICATION_FAILED dari Google Cloud HA VPN biasanya mengembalikan orang ke kunci yang dibagikan sebelumnya, dan kuncinya biasanya benar. Tunnel tersendat di fase 1 karena Google juga membandingkan hal lain: identitas yang diklaim peer selama pertukaran IKE. Pada FortiGate identitas itu bisa berubah tipe tanpa ada yang menyunting alamat. Bacalah log sebagai ketidakcocokan identitas setelah kunci dimasukkan ulang dua kali.
Satu kegagalan, dua pemeriksaan
IKE memverifikasi peer dalam dua langkah terpisah. Kunci yang dibagikan sebelumnya membuktikan kedua ujung memegang rahasia yang sama, dan identitas yang diklaim memberi tahu penjawab siapa yang diklaim peer. Google memeriksa identitas itu terhadap peer yang dikonfigurasi. Jika dibiarkan, FortiGate mengirim identitas berbasis alamat yang diturunkan dari antarmuka keluarnya, dan perbandingannya lolos tanpa ada yang menyadarinya.
Kedua langkah jatuh ke keranjang yang sama di log, yang menjelaskan putaran akrab mengetik ulang kunci empat kali sebelum ada yang membaca muatan identitas.
Apa yang FortiGate taruh dalam muatan identitas
Masalahnya mulai ketika seseorang menyetel ID lokal agar kedua sisi sepakat. Build FortiOS terbaru menandai identitas itu sebagai nama domain berkualifikasi penuh bahkan ketika nilai yang diketik adalah alamat bertitik. Karena itu Google menerima identitas FQDN sementara mengharapkan alamat, dan menolak sesi. Tidak ada dalam pesan yang menyebut separuh mana yang gagal, jadi laporan terbaca sebagai kegagalan autentikasi.
Reproduksi sekali dengan penelusuran IKE aktif dan bacalah muatan identitas yang benar-benar dikirim firewall.
Pada putaran yang sama, pastikan tiga fakta murah: versi IKE yang dipakai kedua ujung, kunci persisnya termasuk karakter tak terlihat di ujungnya, dan alamat peer yang diharapkan Google. Semuanya menjawab pertanyaan berbeda, dan kunci yang cocok tidak mengatakan apa pun tentang identitas.
Opsi, dan biaya masing-masing
Setiap jalan keluar memperbaiki lapisan berbeda, dan tidak satu pun tersedia untuk semua penerapan.
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
Memperbaiki identitas di firewall adalah jawaban terbersih bila firmware mengizinkan Anda memilih tipe dan mempertahankan nilainya. Kolom itu ada di sejumlah build dan mengisi tipe dengan salah di build lain, jadi ujilah versi Anda daripada memercayai catatan rilis.
Alamat publik yang dapat dirutekan pada antarmuka perundingan adalah jalan pintas yang terdokumentasi, karena identitas bawaannya lalu cocok dengan yang diharapkan Google dan tidak perlu penimpaan. Di situlah sebagian besar penerapan berakhir, jika firewall memang dapat memegang alamat semacam itu.
Mengakhiri pada peer yang memvalidasi apa yang Anda hasilkan adalah perubahan topologi. Perlakukan itu sebagai keputusan desain, bukan jalan pintas dengan deskripsi yang lebih ramah.
Ketika NAT menghapus satu opsi
Di balik NAT jalan keluar melalui alamat publik hilang, dan yang tersisa bergantung pada perilaku firmware yang tidak Anda kendalikan. Di situlah titik untuk memilih dengan sadar antara meningkatkan versi, memindahkan peer, atau menerima titik akhir cloud yang lain. Itu tiga anggaran berbeda, dan memilih salah satunya secara kebetulan adalah cara jalan pintas sementara berubah menjadi arsitektur. Tuliskan pilihan dan alasannya di samping tunnel.
Sebelum menafsirkan apa pun dari ini, pastikan status tunnel di sisi Google dan bahwa IKE tidak sekadar dijatuhkan di jalan. Paket yang dijatuhkan habis waktu; ia tidak menghasilkan penolakan.
Apa yang dicatat selama masih berfungsi
Catat tipe identitas, nilainya, versi firmware, dan alamat peer yang berlaku saat tunnel terakhir naik. Pembaruan firmware dapat mengubah nilai bawaan lagi, dan kegagalan berikutnya akan tampak persis seperti ketidakcocokan kunci. Dengan identitas tersimpan di samping kunci dan alamat peer, orang berikutnya mulai dari pemeriksaan murah.
Catatan itu juga satu-satunya cara mengetahui apakah jalan pintas masih diperlukan setelah peningkatan berikutnya.