Cloud VPN-in tənzimləyə bilmədiyiniz hədləri: IKE ömrü və peer NAT

Uzaq cihaza 24 saatlıq mərhələ 1 ömrü verin və Cloud VPN tuneli bağlı qalır, hətta Google tərəfində hər şey düzgün konfiqurasiya olunsa belə. Peer cavabdehin qəbul etməyəcəyi bir dəyər təklif edir, ona görə danışıqlar ya tamamilə uğursuz olur, ya da sonsuz yenidən başlayır. Cloud VPN mərhələ 1-i 36,000 saniyə, yəni on saatla məhdudlaşdırır və bu hədd qaldıra biləcəyiniz bir parametr deyil. Dəyişiklik uzaq cihaza aiddir.

Peer soruşur, cavabdeh qərar verir

IKE iki təklif dəstəsi arasında uyğunlaşdırma məşqidir. Tunel yalnız dəstələrin cavabdehin qəbul etdiyi sərhədlər daxilində üst-üstə düşdüyü yerdə yaranır; buna görə də aralıqdan kənar ömür heç bir qismən tunel yaratmır. Peer konfiqurasiyasına təklif kimi deyil, arzu siyahısı kimi yanaşmaq adi səhvdir. Boş kəsişmə marşrutlaşdırma və seçicilər nə qədər düzgün olsa da tuneli bağlı saxlayır.

Tiket açmazdan əvvəl tunelin öz vəziyyətini oxuyun, çünki ətraflı status adətən uğursuz olan mərhələni göstərir:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Geri qaytarılanı şlüz növünüz və IKE versiyası üçün dəstəklənən dəstlə müqayisə edin və orada olarkən hər iki trafik seçicisini qeyd edin. Seçici uyğunsuzluğu alqoritm uyğunsuzluğu ilə eyni bağlı tunel simptomunu verir və alqoritmdən fərqli olaraq bunu düzəltmək sizin işinizdir.

36,000 saniyə həddir

Mərhələ 1 36,000 saniyədə dayanır. 86,400-ə qurulmuş cihaz cavabdehin heç vaxt razılaşmayacağı bir şey istəyir və yenidən cəhd onun fikrini dəyişmir. Uzaq təklifi aralığın içinə qaytarın və eyni konfiqurasiya qurulur; asimmetriya bütün dərsdir, çünki öz dəyərinizi aşağı sala bilərsiniz, Google-un dəyərini isə yuxarı qaldıra bilməzsiniz.

Seçilmiş dəyəri dizayn qeydlərinə yazın. Əks halda növbəti mühəndis 24 saatlıq təcrübəni təkrar edib eyni divara çatacaq.

Dəstəklənən dəst şlüz növü və IKE versiyası üzrə burada dərc olunur: Cloud VPN icmalı, ona görə ümumi IKE bələdçisi yerinə topologiyanız üçün olan bölməni oxuyun.

Cədvəl üzrə düşən tunel

Mərhələ 2 fərqli davranır: iki tərəf razılaşmadıqda açar yeniləmə daha qısa intervala uyğun gedir. Uyğunsuzluğu fəlakətli sayan peer isə tuneli salır, yəni bir uyğunsuzluq iki ayrı nasazlıq kimi görünə bilər. Yalnız ilk qoşulmaya deyil, açar yeniləmə ritminə baxın. Qalxıb sonra müntəzəm templə düşən tunel daha çox marşrut qüsuru deyil, ömür uyğunsuzluğudur.

Hər hansı dəyişiklik etməzdən əvvəl o düşmə vaxt damğalarını peer-in öz jurnalları ilə əlaqələndirin, çünki seçici və ya marşrut dəyişikliyi eyni ritmi təqlid edə bilər. Templ mərhələ 2 taymerinə uyğundursa, heç bir təklifə toxunmadan səbəb tapılmış olur.

Dəstlər şlüz növündən gəlir

Şifrələmə və bütövlük dəstləri strongSwan-ın icazə verdiyi kimi redaktə etdiyiniz tunel başına profil deyil. Onları şlüz növü və IKE versiyası ilə seçirsiniz və mövcud olmayan profil axtarmaq bir günorta itirir.

Dəstəklənən dəst daxilində heç nə təklif etməyən köhnə cihaz iki dürüst yol buraxır: cihazı dəyişdirin, ya da nəzarət etdiyiniz proqram şlüzündə sonlandırıb oradan VPC-yə marşrutlaşdırın. Başqa hər şey növbəti baxışdan keçməyən bir dolanış yoldur.

Hər cihaz üçün bir xarici ünvan

Peer-in xarici ünvanı onun daxili ünvanına birə-bir uyğunlaşmalıdır. Həddindən artıq yüklənmiş PAT hovuzu işləyə bilməz, çünki tək bir ictimai ünvan arxasındakı bir neçə host cavabdehə onları ayırmağın heç bir yolunu vermir. Bir neçə host ünvanı paylaşmalı olduqda, tunel onları fərqləndirə bilən yerdə bitməlidir.

O xarici ünvanı da sabit saxlayın. Cihazı başqa NAT-ın arxasına köçürün və hər təklif hələ də uyğun olsa da əlaqə pozulur. Hansı dəyərlərin Google-a, hansıların sizə aid olduğunu yazmağa dəyər: ömürlər, dəstlər və birə-bir NAT onların tərəfində sabitdir, təkliflər, seçicilər, marşrutlaşdırma və BGP prioritetləri isə sizindir.