Alamat BGP Cloud VPN berada di dalam tunnel, bukan di kartu jaringan

Buka halaman Cloud Router untuk VPN dan sebuah sesi BGP dengan alamat di 169.254.0.0/16 menatap Anda. Reaksi alami adalah menaruh alamat itu di suatu tempat pada VM dan menunggu sesi naik. Reaksi itu salah dengan cara tertentu: pasangan tersebut milik tautan logis yang dibuat tunnel IPsec, bukan milik antarmuka jaringan biasa mesin. Tidak ada yang Anda tambahkan ke NIC membuat tunnel membawa BGP.

Ikuti pasangan itu ke bawah tumpukan alih-alih menambahkannya ke host.

Mulailah dari tempat konsol menampilkan pasangan itu

Halaman sesi mencantumkan alamat BGP Cloud Router dan alamat peer, keduanya link-local untuk HA VPN IPv4. Di sampingnya ada alamat gateway luar yang menerminasi tunnel. Itu objek yang berbeda: pasangan link-local hidup di dalam, dan alamat gateway hidup di luar serta harus dapat dirutekan sebelum hal lain berfungsi.

Tuliskan ketiganya sebelum membuka berkas konfigurasi, karena mencampur adukkannya adalah seluruh mode kegagalan.

Turunlah ke tunnel yang membawanya

Pasangan link-local baru bermakna setelah ada asosiasi keamanan IPsec antara kedua gateway. Di sisi Google tunnel HA VPN membuatnya pada kedua antarmuka; di sisi Anda itu adalah apa yang dinegosiasikan peer. Periksa dulu asosiasi data dengan swanctl --list-sas dan catat tunnel mana yang aktif di antarmuka mana, karena sesi BGP yang sehat di atas tunnel mati mustahil dan tunnel mati dengan konfigurasi penuh harapan adalah hal biasa.

Paket BGP adalah lalu lintas IP dalam. Jaringan luar tidak pernah melihatnya, jadi tidak ada switch yang membutuhkan kedua alamat pada satu VLAN.

Sekarang konfigurasikan peer Linux agar sesuai

Pilih desain tunnel yang didukung dan biarkan itu menentukan alamat dalam. Dengan antarmuka berbasis rute, entri perutean dan pemilih lalu lintas yang dinegosiasikan harus sepakat, karena nama antarmuka saja tidak mengizinkan apa pun. Arahkan BIRD ke alamat lokal dalam dan alamat dalam Cloud Router, setel nomor AS dari halaman sesi, dan izinkan TCP 179 di dalam jalur yang dilindungi. Pertahankan rute ke alamat luar jauh pada uplink fisik agar tunnel tidak menangkap transportnya sendiri.

Tunnel yang merutekan dirinya sendiri adalah loop dengan jabat tangan, dan selama satu jam akan tampak seperti masalah firewall.

Periksa setiap tahap secara berurutan, bukan semuanya sekaligus

Jalani tahapannya: asosiasi keamanan naik, peer dalam dapat dijangkau dari alamat tunnel, sesi BGP terbentuk, prefiks diterima, lalu prefiks beban kerja benar-benar dipakai. birdc show protocols menjawab pertanyaan ketiga dan tidak yang lain, itulah sebabnya orang menyatakan kemenangan lebih awal.

Tetangga yang terbentuk tidak menjanjikan bahwa kedua sisi mengumumkan prefiks yang Anda butuhkan, atau bahwa rute itu dipasang sebagai rute pilihan.

Jika sesi sudah terbentuk dan lalu lintas tetap mengambil jalur yang salah, bandingkan prefiks yang diumumkan dengan apa yang dilakukan tabel perutean terhadapnya. Rute yang lebih spesifik di tempat lain, atau preferensi untuk jalur lain, memberi Anda sesi BGP yang berfungsi dan tidak ada penerusan yang berguna.

Berhentilah sebelum menerapkan ini ke Router Appliance

Network Connectivity Center Router Appliance adalah model keterikatan yang berbeda. Peer Cloud Router-nya memakai alamat internal dari tataan VPC dan subnet, bukan pasangan link-local HA VPN. Jika tujuan sebenarnya adalah BGP dengan VM perutean, ikuti persyaratan antarmuka produk itu alih-alih menyalin sesi link-local.

Cakupan link-local tetap berarti apa yang dikatakannya. Tunnel logis menyediakan ketetanggaan ini, dan itu tidak melisensikan perutean tujuan link-local sembarangan melintasi VPC.