GCP HA VPN: BGP oturumu Waiting for peer'da takılı kalıyor, adres çiftinin yer değiştirmesi

Cloud VPN tünelinde hiçbir zaman Established durumuna ulaşmayan bir BGP oturumu genellikle bir yönlendirme sorunu değildir. Bu bir kablolama sorunudur: birbirini yansıtması gereken iki adres yanlış sırayla girilmiş ya da ilk tünelin çifti ikincisinde yeniden kullanılmıştır. Tünelin kendisi tamamen sağlıklı olabilirken oturum Waiting for peer'da kalır, çünkü IPsec ve BGP aynı iki uç nokta arasındaki ayrı müzakerelerdir. Herhangi bir şeyi yeniden kurmadan önce bu ikisinden hangisinin bozuk olduğuna karar verin.

Tek bir soru çoğu durumu çözer: eş cihaz Cloud Router'ın adresini hiç görüyor mu?

Tünel durumu ve oturum durumu farklı kontrollerdir

Önce IKE ve ESP gelir. Tünel kurulmamışsa içindeki hiçbir şey önemli değildir ve BGP adresi tartışması erkendir. Tünelin durumunu ve ayrıntılı durumunu, ardından aynı tünel için yönlendiricinin BGP eş durumunu okuyun.

Tünel ayaktayken BGP eşi kapalıysa bu, arızayı oturuma daraltır: eş adresi, ASN veya iç adrese ulaşan TCP 179. Tünel ayakta, oturum ayakta ve hâlâ VPC'de rota yok bu üçüncü durumdur. Adresleri değiştirmek orada işe yaramaz, çünkü oturum zaten çalışıyor ve önek yalnızca duyurulmuyor ya da tercih edilmiyor. Bu üç durumu ayrı tutmak işin büyük kısmıdır.

Her tünelin iki ucu da doldurulmuş kendi /30'una ihtiyacı var

Her HA VPN tüneli 169.254.0.0/16 içinden bir link-local /30 alır; bir adres Cloud Router arayüzünde, diğeri sizin eşinizde olur. Eş alanı uzak ucu adlandırmalıdır, asla yönlendiricinin kendi adresini değil.

İki tünel, Cloud Router üzerinde her biri farklı /30'a sahip iki arayüz demektir. Tünel 0'ın çiftini tünel 1'de yeniden kullanmak, özet tabloda derli toplu görünen ve OPEN paketinde ölen hatadır.

Çifti konsol özetinden değil, yönlendirici kaynağından okuyun. Özet, eş adresini yanlış okunması kolay bir sütunda listeler ve arayüzün ipRange'i ile eşin peerIpAddress'i aynı /30'un karşıt uçlarını tanımlamalıdır.

Yer değiştirme genellikle yeniden kurulum sırasında olur

Çiftler tam da tünel yeniden kurulurken çaprazlanır. Eski tünelin eş adresi yeni tünelin arayüz alanına kopyalanır ya da yeni oturum önceki oturumun eşine yönlendirilir. Her iki durumda da Cloud Router OPEN paketlerini artık kendisi olan bir adrese ya da arkasında tünel olmayan bir adrese gönderir.

Çiftleri konsolu açmadan önce yazın: tünel adı, arayüz, yönlendirici adresi, eş adresi, eş ASN'i. Sonra iki tüneli tek seferde oluşturun, böylece ikincisi birincinin artıklarıyla dolmasın.

Bir oturumun beklemesinin üç nedeni daha

Birincisi eş ASN'i: her taraf diğer tarafın ASN'i ile yapılandırılmalıdır ve uyuşmazlık eşe ulaşır ama asla kurulmaz. İkincisi eşin kendi güvenlik duvarıdır; tünel arayüzünde TCP 179'a izin vermelidir, bir IKE veya ESP kuralı bunu kapsamaz. Üçüncüsü, komşusu olarak yapılandırılan adresten farklı bir kaynak adresten yanıt veren bir eştir.

Eşin kendi günlüğü ayırt edicidir. BGP özeti o adres için hiç komşu listelemiyorsa paketler gelmiyor demektir ve çift ya da yol yanlıştır. Komşu Active veya Connect durumundaysa paketler geliyor ama oturum parametreleri uyuşmuyor demektir.

Paketlerin izlediği sırayla doğrulayın

Dışa doğru çalışın: tünel durumu, sonra yönlendiricinin BGP eş durumu, sonra eşin BGP özeti, sonra rotalar. İlk ikisi sağlıklıysa Cloud VPN tarafını düzenlemeyi bırakın ve eş cihazda çalışın. Yönlendirici eşi kapalı bildiriyorsa ve cihazınızda hiç komşu yoksa çift yanlıştır ya da BGP portu filtreleniyordur. Eşin tünel arayüzünde paket yakalamak bunu tek bakışta çözer, çünkü OPEN paketleri ya oraya ulaşır ya da hiç ulaşmaz.

gcloud compute routers get-status ROUTER --region=REGION eş durumunu kullandığı adresin yanında yazdırır ve karşılaştırmanız gereken çift tam olarak budur.

Oturum kurulduğunda, öğrenilen önekin VPC rota tablosunda göründüğünü ve her iki tarafta birer ana bilgisayarın yanıt verdiğini doğrulayın. Ardından son çiftleri tünel adlarının yanına kaydedin, böylece bir sonraki yeniden kurulum konsol özetinden değil doğrulanmış bir tablodan başlar.