GCP HA VPN: BGP sessiyası Waiting for peer-də ilişib qalır, ünvan cütünün yerdəyişməsi
Cloud VPN BGP sessiyası Waiting for peer vəziyyətində ilişibsə, adətən tunel və peer ünvanları yerdəyişib. Nəyisə yenidən qurmazdan əvvəl cütü yoxlayın.
Cloud VPN tunelində heç vaxt Established vəziyyətinə çatmayan BGP sessiyası adətən marşrutlaşdırma problemi deyil. Bu, naqilləşdirmə problemidir: bir-birini əks etdirməli olan iki ünvan səhv sıra ilə daxil edilib, ya da birinci tunelin cütü ikincidə təkrar istifadə olunub. Tunel özü tamamilə sağlam ola bilər, halbuki sessiya Waiting for peer vəziyyətində qalır, çünki IPsec və BGP eyni iki son nöqtə arasında ayrı-ayrı danışıqlardır. Nəyisə yenidən qurmazdan əvvəl bu ikisindən hansının xarab olduğunu müəyyənləşdirin.
Bir sual halların çoxunu həll edir: peer cihazı Cloud Router ünvanını ümumiyyətlə görürmü?
Tunel vəziyyəti ilə sessiya vəziyyəti fərqli yoxlamalardır
Əvvəlcə IKE və ESP gəlir. Tunel qurulmayıbsa, onun içindəki heç nə əhəmiyyət daşımır və BGP ünvanı müzakirəsi vaxtsızdır. Tunelin statusunu və ətraflı statusunu, sonra marşrutlaşdırıcının həmin tunel üçün BGP peer statusunu oxuyun.
Tunel işlək, BGP peer-i isə söndürülmüş haldadırsa, nasazlıq sessiyaya daralır: peer ünvanı, ASN və ya daxili ünvana gələn TCP 179. Tunel işləkdir, sessiya işləkdir və hələ də VPC-də marşrut yoxdur bu üçüncü haldır. Ünvanları dəyişmək burada kömək etməyəcək, çünki sessiya artıq işləyir və prefiks sadəcə reklam edilmir və ya üstün tutulmur. Bu üç halı bir-birindən ayırmaq işin böyük hissəsidir.
Hər tunel öz /30-una ehtiyac duyur və hər iki ucu doldurulmalıdır
Hər HA VPN tuneli 169.254.0.0/16-dən link-local /30 alır: bir ünvan Cloud Router interfeysində, digəri sizin peer-inizdə. Peer sahəsi uzaq ucu göstərməlidir, heç vaxt marşrutlaşdırıcının öz ünvanını yox.
İki tunel Cloud Router-də iki interfeys deməkdir, hər biri fərqli /30 ilə. Tunel 0-ın cütünü tunel 1-də təkrar istifadə etmək xülasə cədvəlində səliqəli görünüb OPEN paketində ölən səhvdir.
| 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 |
Cütü konsol xülasəsindən deyil, marşrutlaşdırıcı resursundan oxuyun. Xülasə peer ünvanını səhv oxunması asan sütunda göstərir və interfeysin ipRange-i ilə peer-in peerIpAddress-i eyni /30-un əks uclarını təsvir etməlidir.
Yerdəyişmə adətən yenidənqurma zamanı baş verir
Cütlər məhz tunel yenidən qurularkən qarışır. Köhnə tunelin peer ünvanı yeni tunelin interfeys sahəsinə köçürülür, ya da yeni sessiya əvvəlki sessiyanın peer-inə yönəldilir. Hər iki halda Cloud Router OPEN paketlərini artıq özü olan ünvana və ya arxasında tunel olmayan ünvana göndərir.
Konsolu açmazdan əvvəl cütləri yazın: tunel adı, interfeys, marşrutlaşdırıcı ünvanı, peer ünvanı, peer ASN. Sonra hər iki tuneli bir keçiddə yaradın ki, ikincisi birincinin qalıqlarından doldurulmasın.
Sessiyanın gözləməsinin daha üç səbəbi
Birinci peer ASN-dir: hər tərəf qarşı tərəfin ASN-i ilə konfiqurasiya edilməlidir və uyğunsuzluq peer-ə çatır, lakin heç vaxt qurulmur. İkincisi peer-in öz firewall-udur və tunel interfeysində TCP 179-a icazə verməlidir; IKE və ya ESP qaydası bunu əhatə etmir. Üçüncüsü, qonşu kimi konfiqurasiya edilmiş ünvandan fərqli mənbə ünvanından cavab verən peer-dir.
Peer-in öz jurnalı əsas fərqləndiricidir. Əgər onun BGP xülasəsində həmin ünvan üçün qonşu yoxdursa, paketlər gəlmir və cüt ya da yol səhvdir. Qonşu Active və ya Connect vəziyyətindədirsə, paketlər gəlir və sessiya parametrləri uyğun gəlmir.
Paketlərin getdiyi sıra ilə yoxlayın
Bayıra doğru işləyin: tunel statusu, sonra marşrutlaşdırıcının BGP peer statusu, sonra peer-in BGP xülasəsi, sonra marşrutlar. İlk ikisi sağlamdırsa, Cloud VPN tərəfini redaktə etməyi dayandırın və peer cihazında işləyin. Marşrutlaşdırıcı peer-i söndürülmüş kimi göstərirsə və cihazınızda qonşu yoxdursa, cüt səhvdir və ya BGP portu filtrlənir. Peer-in tunel interfeysində paket tutma bunu bir baxışda həll edir, çünki OPEN paketləri ya oraya gəlir, ya da heç gəlmir.
gcloud compute routers get-status ROUTER --region=REGION peer vəziyyətini istifadə etdiyi ünvanın yanında çap edir və bu, müqayisə etməli olduğunuz cütün özüdür.
Sessiya qurulduqdan sonra öyrənilmiş prefiksin VPC marşrut cədvəlində göründüyünü və hər tərəfdə bir hostun cavab verdiyini təsdiqləyin. Sonra yekun cütləri tunel adlarının yanında qeyd edin ki, növbəti yenidənqurma konsol xülasəsindən deyil, yoxlanılmış cədvəldən başlasın.