Google HA VPN ke Router Cisco: Rencanakan Sumber Daya Peer Terlebih Dahulu
Sebutkan kedua antarmuka Google, sumber daya peer, kontrak IKEv2, dan setiap sesi BGP sebelum mengonfigurasi router Cisco, lalu pilih satu peer atau dua.
Keputusan pertama dalam HA VPN dari Cisco ke Google bukanlah profil kripto mana yang dipakai, melainkan apakah satu perangkat lokal atau dua yang akan mengakhiri tunnel. Gateway HA VPN Google memiliki dua antarmuka, dan masing-masing mengharapkan tunnel peer yang sesuai. Itu memberi Anda dua tunnel terlepas dari apakah Anda memiliki dua router, dan perbedaannya adalah apakah satu catu daya atau peningkatan perangkat lunak dapat menjatuhkan seluruh desain.
Keputusannya adalah satu perangkat peer atau dua
Pilih tata letak berdasarkan tiga kondisi: apakah Anda dapat menerima titik kegagalan lokal, apakah kedua antarmuka cloud harus digunakan, dan seberapa banyak rekonvergensi yang ditoleransi beban kerja Anda. Jika salah satu dari ketiganya merupakan persyaratan keras, dua perangkat peer adalah jawaban yang jujur.
Putuskan itu sebelum membuka konsol, karena jawabannya mengubah berapa banyak tunnel dan sesi BGP yang harus dijelaskan lembar kerja.
Tulis lembar kerja sebelum perintah apa pun
Lembar kerja memiliki lima baris, dan masing-masing membutuhkan pemilik:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
Sumber daya peer eksternal menjelaskan antarmuka Anda di dalam Google Cloud, dan membuatnya tidak mengonfigurasi router Cisco. Asimetri itu mengejutkan orang yang mengharapkan konsol cloud menjadi sumber kebenaran untuk kedua ujung. Itu adalah deklarasi tentang apa yang seharusnya diharapkan Google, dan router tetap harus cocok dengannya. panduan gateway peer Google memetakan deklarasi itu ke pekerjaan tunnel, BGP, firewall, dan IKE yang masih Anda utang.
Jika sebuah baris tidak memiliki pemilik, baris itu akan diisi oleh siapa pun yang bertugas saat cutover.
Pisahkan ketiga peran alamat
Alamat peer publik membawa pertukaran IPsec luar. Pasangan BGP dalam milik koneksi logis terlindungi yang berjalan di atasnya. Prefiks LAN dan VPC yang diiklankan menjelaskan beban kerja di balik koneksi itu. Menyalin alamat internal VM ke bidang peer eksternal mencampur dua peran pertama, dan kegagalannya tampak seperti masalah negosiasi alih-alih kesalahan entri data.
Rencanakan dua tunnel peer yang sesuai, satu untuk setiap antarmuka HA VPN. Menggunakan kedua antarmuka cloud tidak dengan sendirinya menghilangkan titik kegagalan lokal, karena kedua tunnel masih dapat mendarat di chassis yang sama.
Tulis peran alamat di samping setiap nilai di lembar kerja. Satu kebiasaan itu mencegah sebagian besar pencampuran.
Terjemahkan lembar kerja ke rilis Cisco
Mulailah dari dokumentasi peer yang didukung atau templat konfigurasi Google yang sesuai untuk platform Anda, lalu selaraskan setiap placeholder dengan lembar kerja. Periksa autentikasi IKEv2, proposal ESP, PFS, serta model tunnel dan perutean secara bersamaan, karena ketidakcocokan pada salah satunya biasanya muncul sebagai ketidakcocokan pada yang lain. Gunakan platform dan rilis perangkat lunak yang sebenarnya untuk memilih apa yang didukung, karena resep Classic VPN adalah titik awal yang berbeda.
Jauhkan rahasia bersama dari tangkapan layar, lampiran tiket, dan catatan dukungan. Kunci yang dibagikan sebelumnya dan ditempelkan ke komentar kasus adalah pengungkapan kredensial, bukan artefak pemecahan masalah.
Jika templat dan lembar kerja tidak setuju, berhentilah dan selesaikan di atas kertas. Perangkat tidak akan menengahi untuk Anda.
Terima setiap tunnel berdasarkan buktinya sendiri
HA VPN membutuhkan sesi BGP, dan negosiasi IKE yang berhasil hanya menetapkan tahap pertama. Sesi dalam harus naik, prefiks yang dimaksud harus diiklankan dan diterima, dan rute yang berguna serta izin firewall harus ada sebelum lalu lintas beban kerja bergerak. Mencatatnya sebagai satu lampu hijau menyembunyikan tahap mana yang sebenarnya gagal.
Catat bukti penerimaan per tunnel: asosiasi keamanan yang dinegosiasikan, status tetangga BGP, prefiks yang dipelajari yang diharapkan, dan jalur beban kerja yang dimaksud. Lalu jalankan pemeriksaan kegagalan dan pemulihan yang terkendali, karena tunnel yang tidak pernah gagal adalah tunnel yang jalur pemulihannya belum diuji.
Catatan itu dapat digunakan kembali saat desain berubah berikutnya, dan itulah perbedaan antara interoperasi dan fragmen perintah yang asumsinya hilang.