GCP HA VPN: sesi BGP tersekat pada Waiting for peer, pertukaran pasangan alamat
Sesi BGP Cloud VPN yang tersekat pada Waiting for peer biasanya telah menukar alamat terowong dan rakan sebaya. Semak pasangan itu sebelum membina semula apa-apa.
Sesi BGP yang tidak pernah mencapai Established pada terowong Cloud VPN biasanya bukan masalah penghalaan. Ia masalah pendawaian: dua alamat yang mesti memantulkan satu sama lain dimasukkan dalam susunan yang salah, atau pasangan terowong pertama digunakan semula pada yang kedua. Terowong itu sendiri boleh sihat sepenuhnya sementara sesi kekal pada Waiting for peer, kerana IPsec dan BGP ialah rundingan berasingan antara dua titik akhir yang sama. Tentukan yang mana antara keduanya rosak sebelum membina semula apa-apa.
Satu soalan menyelesaikan kebanyakan kes: adakah peranti rakan sebaya melihat alamat Cloud Router langsung?
Keadaan terowong dan keadaan sesi ialah pemeriksaan berbeza
IKE dan ESP datang dahulu. Jika terowong tidak terbentuk, apa-apa di dalamnya tidak penting dan perbincangan alamat BGP terlalu awal. Baca status dan status terperinci terowong, kemudian baca status rakan sebaya BGP penghala untuk terowong yang sama.
Terowong yang hidup manakala rakan sebaya BGP-nya mati menyempitkan kerosakan kepada sesi: alamat rakan sebaya, ASN, atau TCP 179 yang tiba pada alamat dalam. Terowong hidup, sesi hidup dan masih tiada laluan dalam VPC ialah kes ketiga. Menukar alamat tidak akan membantu di situ, kerana sesi sudah berfungsi dan awalan itu semata-mata tidak diumumkan atau tidak diutamakan. Memisahkan ketiga-tiga kes ini ialah sebahagian besar kerja.
Setiap terowong memerlukan /30 sendiri, dengan kedua-dua hujung diisi
Setiap terowong HA VPN mendapat /30 link-local daripada 169.254.0.0/16, satu alamat pada antara muka Cloud Router dan satu lagi pada rakan sebaya anda. Medan rakan sebaya mesti menamakan hujung jauh, tidak sekali-kali alamat penghala itu sendiri.
Dua terowong bermakna dua antara muka pada Cloud Router, masing-masing dengan /30 berbeza. Menggunakan semula pasangan terowong 0 pada terowong 1 ialah kesilapan yang kelihatan kemas dalam jadual ringkasan dan mati dalam paket OPEN.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
Baca pasangan itu daripada sumber penghala, bukan daripada ringkasan konsol. Ringkasan menyenaraikan alamat rakan sebaya dalam lajur yang mudah salah baca, dan ipRange antara muka serta peerIpAddress rakan sebaya mesti menerangkan hujung bertentangan bagi satu /30.
Pertukaran biasanya berlaku semasa pembinaan semula
Semasa membina semula terowong pasangan menjadi bersilang. Alamat rakan sebaya terowong lama disalin ke medan antara muka terowong baharu, atau sesi baharu dihalakan ke rakan sebaya sesi sebelumnya. Sama ada cara, Cloud Router menghantar paket OPEN ke alamat yang kini dirinya sendiri atau ke alamat tanpa terowong di belakangnya.
Catatkan pasangan sebelum membuka konsol: nama terowong, antara muka, alamat penghala, alamat rakan sebaya, ASN rakan sebaya. Kemudian cipta kedua-dua terowong dalam satu laluan, supaya yang kedua tidak diisi dengan sisa yang pertama.
Tiga sebab lain sesi menunggu
ASN rakan sebaya yang pertama: setiap sisi mesti dikonfigurasikan dengan ASN sisi lain, dan ketidakpadanan sampai ke rakan sebaya tetapi tidak pernah terbentuk. Yang kedua ialah tembok api rakan sebaya itu sendiri, yang mesti membenarkan TCP 179 pada antara muka terowong; peraturan IKE atau ESP tidak meliputinya. Yang ketiga ialah rakan sebaya yang membalas dari alamat sumber berbeza daripada yang dikonfigurasikan sebagai jirannya.
Log rakan sebaya itu sendiri ialah pembeza. Jika ringkasan BGP-nya tidak menyenaraikan jiran untuk alamat itu, paket tidak tiba dan pasangan atau laluannya salah. Jika jiran berada dalam Active atau Connect, paket tiba dan parameter sesi tidak sepadan.
Semak mengikut urutan perjalanan paket
Bekerja ke luar: status terowong, kemudian status rakan sebaya BGP penghala, kemudian ringkasan BGP rakan sebaya, kemudian laluan. Jika dua yang pertama sihat, berhenti menyunting bahagian Cloud VPN dan bekerja pada peranti rakan sebaya. Jika penghala melaporkan rakan sebaya mati dan peranti anda tiada jiran, pasangan itu salah atau port BGP ditapis. Tangkapan paket pada antara muka terowong rakan sebaya menyelesaikannya dengan satu pandangan, kerana paket OPEN sama ada tiba di sana atau tidak pernah tiba.
gcloud compute routers get-status ROUTER --region=REGION mencetak status rakan sebaya di sebelah alamat yang digunakannya, dan itulah tepat pasangan yang perlu anda bandingkan.
Setelah sesi terbentuk, pastikan awalan yang dipelajari muncul dalam jadual laluan VPC dan satu hos pada setiap sisi menjawab. Kemudian catatkan pasangan akhir di sebelah nama terowong, supaya pembinaan semula seterusnya bermula daripada jadual yang telah diuji dan bukan daripada ringkasan konsol.