Plan təmiz tətbiq olunur, tunel qalxır və konsol onu siyasət əsaslı adlandırır. Trafik yenə də keçmir və Terraform resursunda marşrut əsaslı açar axtarışı heç yerə aparmır, çünki belə sahə mövcud deyil. Classic VPN-də marşrut əsaslı davranış seçdiyiniz rejim deyil. Bu, yerli trafik selektorunun 0.0.0.0/0 olması, uzaq selektorların həqiqətən istədiyiniz şəbəkələri sadalaması və marşrutun tunelə işarə etməsi ilə əldə olunur. Üç şey və etiket arxasınca gəlir.

Mif: tunel rejimi sahəsi

Konsol etiketi API-nin selektorlarda gördüyünü əks etdirir. Resursda heç nə marşrut əsaslı demir, ona görə də doğru dəyərə qurulacaq bir şey yoxdur.

Bu sahəni axtarmaq problemin ilk saatını alır, selektor dəyərlərini oxumaq isə son beş dəqiqəni alır.

Marşrut əsaslı burada nə deməkdir

Google Classic VPN-in marşrut əsaslı tunellərini yerli selektoru 0.0.0.0/0 olan siyasət əsaslı tunellər kimi sənədləşdirir. Yalnız uzaq diapazonlar adlanır və yerli tərəf istənilən ünvan kimi qəbul edilir. Buna görə konfiqurasiyanızdakı marker rejim deyil, dəyərdir. Hər iki selektoru açıq şəkildə yazın və plan çıxışında oxuyun:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

Bu fraqmentdəki qarşı tərəf prefiksi nümunə üçündür; vacib olan formadır.

Marşrut ayrı obyektdir

Tunel obyekti marşrut quraşdırmır. Paketlər tunelin siyasətinə uyğun gələ və yenə də gedəcək yer tapa bilməz, çünki növbəti hopu VPC marşrut cədvəli müəyyən edir. Marşrut üçün təyinat diapazonu, şəbəkə, növbəti hop kimi tunel və daha geniş hər şeyi üstələyən prioritet lazımdır. Bunu unutmaq qurulmuş vəziyyət bildirən tunel və VPC-dən heç vaxt çıxmayan yoxlama sorğusu verir.

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

Marşrutu tunellə eyni modulda yaradın ki, ikisi baxış zamanı bir-birindən uzaqlaşmasın.

Selektorları qarşı tərəfdə əks etdirin

Uzaq cihaz güzgü təsviri ilə konfiqurasiya olunmalıdır: onun yerli diapazonu sizin uzaq selektorunuzdur və uzaq diapazonu istifadə etməyi gözlədiyiniz GCP alt şəbəkələrini əhatə etməlidir. Hər hansı tərəf daralsa, faza 1 uğur qazansa da faza 2 uğursuz olur. Bu, konsolda doğru görünən və heç bir trafik daşımayan konfiqurasiyanın ən çox rast gəlinən formasıdır.

Dəyişiklik baxışı zamanı hər iki tərəfin selektorlarını yan-yana çap edin.

Statik ünvanı iki tətbiqə bölün

Qorunan ünvanı və ona istinad edən tuneli bir tətbiqdə yaratmaq tanınmış qeyri-sabitlik mənbəyidir, çünki ünvan yönləndirmə qaydası ondan istifadə etməzdən əvvəl mövcud olmalıdır. Əvvəlcə yalnız ünvan resursunu tətbiq edin, sonra şlüzü, yönləndirmə qaydalarını və tuneli əlavə edib yenidən tətbiq edin. Terraform ikinci işə salmada mövcud ünvanı vəziyyətdən oxuyur və təkrar istifadə edir. Bunu atsanız, tunel hər tətbiqdə yeni ictimai ünvan ala bilər və bu, qarşı tərəfin konfiqurasiyasını hər dəfə pozar.

İndi iki tətbiq hər buraxılışda qarşı tərəfi dəyişməkdən ucuzdur.

Etiketi deyil, razılaşmanı yoxlayın

Tətbiqdən sonra üç ayrı faktı yoxlayın: tunel qurulmuş vəziyyət bildirir, marşrut nəzərdə tutulan növbəti hopla mövcuddur və qarşı tərəf həm faza 1, həm də faza 2-nin işlədiyini bildirir.

Faza 2 söndüyü halda işləyən tunel iki tərəfin selektorlar barədə razılaşmadığını bildirir:

  • Bir tərəf digərinin sadalamadığı alt şəbəkəni sadalayır.
  • Bir tərəf digərinin daraltdığı aqreqatdan istifadə edir.
  • Marşrut mövcuddur, lakin başqa tunelə işarə edir.

Classic VPN HA VPN-dən aşağı SLA-ya malik tək tuneldir və HA VPN iki interfeys, iki tunel və fərqli resurs növləri olan BGP istifadə edir. Klassik nümunəni HA konfiqurasiyasına köçürüb selektor sahələrinin eyni cür davranacağını gözləmək ayrıca və qaçınılmalı səhvdir. Tunel sahələri özləri isə bu istinadda sənədləşdirilib: google_compute_vpn_tunnel istinadı.

Əlaqəli məqalələr