GCP HA VPN: sesi BGP tertahan di Waiting for peer, pertukaran pasangan alamat

Sesi BGP yang tidak pernah mencapai Established pada tunnel Cloud VPN biasanya bukan masalah routing. Ini masalah pengkabelan: dua alamat yang harus saling mencerminkan dimasukkan dalam urutan terbalik, atau pasangan tunnel pertama dipakai ulang di tunnel kedua. Tunnel itu sendiri bisa sepenuhnya sehat sementara sesi tetap di Waiting for peer, karena IPsec dan BGP adalah negosiasi terpisah antara dua titik akhir yang sama. Tentukan mana dari keduanya yang rusak sebelum membangun ulang apa pun.

Satu pertanyaan menyelesaikan sebagian besar kasus: apakah perangkat peer melihat alamat Cloud Router sama sekali?

Status tunnel dan status sesi adalah pemeriksaan yang berbeda

IKE dan ESP lebih dulu. Jika tunnel tidak terbentuk, apa pun di dalamnya tidak penting dan pembahasan alamat BGP terlalu dini. Baca status dan status rinci tunnel, lalu baca status peer BGP router untuk tunnel yang sama.

Tunnel yang hidup sementara peer BGP-nya mati mempersempit kesalahan ke sesi: alamat peer, ASN, atau TCP 179 yang tiba di alamat dalam. Tunnel hidup, sesi hidup, dan tetap tidak ada rute di VPC adalah kasus ketiga. Mengubah alamat tidak akan membantu di situ, karena sesinya sudah bekerja dan prefiksnya memang tidak diumumkan atau tidak dipilih. Memisahkan ketiga kasus itu adalah sebagian besar pekerjaannya.

Setiap tunnel perlu /30 sendiri, dengan kedua ujung terisi

Setiap tunnel HA VPN mendapat /30 link-local dari 169.254.0.0/16, satu alamat di antarmuka Cloud Router dan satu lagi di peer Anda. Kolom peer harus menyebut ujung jauh, jangan pernah alamat router itu sendiri.

Dua tunnel berarti dua antarmuka di Cloud Router, masing-masing dengan /30 berbeda. Memakai ulang pasangan tunnel 0 pada tunnel 1 adalah kesalahan yang terlihat rapi di tabel ringkasan dan mati di paket OPEN.

Baca pasangannya dari resource router, bukan dari ringkasan konsol. Ringkasan mencantumkan alamat peer di kolom yang mudah salah dibaca, dan ipRange antarmuka ditambah peerIpAddress peer harus menggambarkan ujung berlawanan dari satu /30.

Pertukaran biasanya terjadi saat pembangunan ulang

Saat membangun ulang tunnel-lah pasangan menjadi tertukar. Alamat peer tunnel lama disalin ke kolom antarmuka tunnel baru, atau sesi baru diarahkan ke peer sesi sebelumnya. Bagaimanapun, Cloud Router mengirim paket OPEN ke alamat yang kini dirinya sendiri atau ke alamat yang tidak punya tunnel di belakangnya.

Tuliskan pasangannya sebelum membuka konsol: nama tunnel, antarmuka, alamat router, alamat peer, ASN peer. Lalu buat kedua tunnel dalam satu kali jalan, agar tunnel kedua tidak diisi dengan sisa tunnel pertama.

Tiga alasan lain sebuah sesi menunggu

ASN peer adalah yang pertama: setiap sisi harus dikonfigurasi dengan ASN sisi lain, dan ketidakcocokan sampai ke peer tetapi tidak pernah terbentuk. Yang kedua adalah firewall peer itu sendiri, yang harus mengizinkan TCP 179 di antarmuka tunnel; aturan IKE atau ESP tidak mencakupnya. Yang ketiga adalah peer yang menjawab dari alamat sumber berbeda dari yang dikonfigurasi sebagai tetangganya.

Log peer itu sendiri adalah pembedanya. Jika ringkasan BGP-nya tidak mencantumkan tetangga untuk alamat itu, paket tidak tiba dan pasangan atau jalurnya salah. Jika tetangga berada di Active atau Connect, paket tiba dan parameter sesi tidak cocok.

Periksa sesuai urutan perjalanan paket

Bekerjalah ke luar: status tunnel, lalu status peer BGP router, lalu ringkasan BGP peer, lalu rutenya. Jika dua yang pertama sehat, berhenti mengedit sisi Cloud VPN dan bekerja pada perangkat peer. Jika router melaporkan peer mati dan perangkat Anda tidak punya tetangga, pasangannya salah atau port BGP difilter. Penangkapan paket di antarmuka tunnel peer menyelesaikannya dengan satu kali lihat, karena paket OPEN entah tiba di sana atau tidak pernah tiba.

gcloud compute routers get-status ROUTER --region=REGION mencetak status peer di samping alamat yang digunakannya, dan itulah tepatnya pasangan yang perlu Anda bandingkan.

Setelah sesi terbentuk, pastikan prefiks yang dipelajari muncul di tabel rute VPC dan satu host di setiap sisi menjawab. Lalu catat pasangan akhir di samping nama tunnel, agar pembangunan ulang berikutnya dimulai dari tabel yang sudah teruji, bukan dari ringkasan konsol.