Cloud VPN BGP ünvanları NIC-də deyil, tunelin içində yerləşir

VPN üçün Cloud Router səhifəsini açın və 169.254.0.0/16 daxilində ünvanı olan BGP sessiyası sizə baxır. Təbii reaksiya həmin ünvanı VM-də hansısa yerə qoyub sessiyanın qalxmasını gözləməkdir. Bu reaksiya konkret şəkildə səhvdir: cüt IPsec tunelinin yaratdığı məntiqi bağlantıya aiddir, maşının adi şəbəkə interfeysinə deyil. NIC-ə əlavə etdiyiniz heç nə tunelin BGP daşımasına səbəb olmur.

Cütü hosta əlavə etmək əvəzinə stek boyunca aşağı izləyin.

Konsolun cütü göstərdiyi yerdən başlayın

Sessiya səhifəsi Cloud Router BGP ünvanını və peer ünvanını sadalayır; IPv4 HA VPN üçün hər ikisi link-local-dır. Onların yanında tunelləri sonlandıran xarici şlüz ünvanları var. Bunlar fərqli obyektlərdir: link-local cütü içəridə yaşayır, şlüz ünvanları isə xaricdə yaşayır və başqa hər şey işləməzdən əvvəl marşrutlaşa bilən olmalıdır.

Konfiqurasiya faylını açmazdan əvvəl hər üçünü yazın, çünki onları qarışdırmaq bütün uğursuzluq modelidir.

Onu daşıyan tunelə qədər aşağı enin

Link-local cütü yalnız iki şlüz arasında IPsec təhlükəsizlik assosiasiyası yarandıqdan sonra məna kəsb edir. Google tərəfində HA VPN tunelləri onu iki interfeysdə yaradır; sizin tərəfinizdə bu, peer-in razılaşdırdığı şeydir. Əvvəlcə məlumat assosiasiyasını swanctl --list-sas ilə yoxlayın və hansı tunelin hansı interfeysdə qalxdığını qeyd edin, çünki ölü tunel üzərində sağlam BGP sessiyası mümkün deyil, ümidli konfiqurasiyalı ölü tunel isə adi haldır.

BGP paketi daxili IP trafikidir. Xarici şəbəkə onu heç vaxt görmür, ona görə heç bir switch-in hər iki ünvanı bir VLAN-da saxlamasına ehtiyac yoxdur.

İndi Linux peer-i uyğunlaşdırın

Dəstəklənən tunel dizaynını seçin və daxili ünvanları o müəyyən etsin. Marşrut əsaslı interfeysdə marşrut qeydi və razılaşdırılmış trafik selektorları uyğun olmalıdır, çünki təkcə interfeys adı heç nəyə icazə vermir. BIRD-i daxili lokal ünvana və Cloud Router-in daxili ünvanına yönəldin, AS nömrələrini sessiya səhifəsindən təyin edin və qorunan yol daxilində TCP 179-a icazə verin. Uzaq xarici ünvana marşrutu fiziki uplink-də saxlayın ki, tunel öz transportunu tutmasın.

Özünü marşrutlaşdıran tunel əl sıxma ilə birlikdə bir döngədir və bir saat ərzində firewall problemi kimi görünəcək.

Hər mərhələni sıra ilə yoxlayın, hamısını birdən yox

Mərhələləri gəzin: təhlükəsizlik assosiasiyası qalxdı, daxili peer tunel ünvanından əlçatandır, BGP sessiyası quruldu, prefikslər qəbul edildi, sonra iş yükü prefiksi həqiqətən istifadə olundu. birdc show protocols üçüncü suala cavab verir və başqa heç nəyə, buna görə də insanlar qələbəni erkən elan edirlər.

Qurulmuş qonşu hər iki tərəfin sizə lazım olan prefiksləri elan etdiyinə və ya həmin marşrutların üstünlük verilən kimi quraşdırıldığına zəmanət vermir.

Sessiya qurulubsa və trafik hələ də səhv yolla gedirsə, elan edilən prefiksləri marşrut cədvəlinin onlarla nə etdiyi ilə müqayisə edin. Başqa yerdə daha konkret marşrut və ya başqa yola üstünlük sizə işlək BGP sessiyası və faydalı yönləndirmə olmadan verir.

Bunu Router Appliance-a tətbiq etməzdən əvvəl dayanın

Network Connectivity Center Router Appliance fərqli birləşmə modelidir. Onun Cloud Router peer-ləri HA VPN link-local cütündən deyil, VPC və subnet düzümündən daxili ünvanlar istifadə edir. Əgər əsl məqsəd marşrutlaşdırma VM-i ilə BGP-dirsə, link-local sessiyanı kopyalamaq əvəzinə həmin məhsulun interfeys tələblərinə əməl edin.

Link-local əhatəsi yenə də dediyini bildirir. Məntiqi tunel bu qonşuluğu təmin edir və VPC boyunca ixtiyari link-local təyinatların marşrutlaşdırılmasına icazə vermir.