Terraform'da GCP Classic VPN: tüneli rota tabanlı yapın

Classic VPN'de etiket davranışı belirlemez. Rota tabanlı, 0.0.0.0/0 yerel seçici, eşleşen uzak seçiciler ve açık bir rota demektir.

Plan temiz uygulanıyor, tünel ayağa kalkıyor ve konsol onu ilke tabanlı olarak adlandırıyor. Trafik yine de geçmiyor ve Terraform kaynağında rota tabanlı bir anahtar aramak hiçbir yere varmıyor çünkü öyle bir alan yok. Classic VPN'de rota tabanlı davranış seçtiğiniz bir mod değildir. Yerel trafik seçicisi 0.0.0.0/0 olduğunda, uzak seçiciler gerçekten istediğiniz ağları listelediğinde ve bir rota tünele işaret ettiğinde elde ettiğiniz şey budur. Üç şey, ve etiket de peşinden gelir.

Mit: tünel modu alanı

Konsol etiketi API'nin seçicilerde gördüğünü yansıtır. Kaynakta hiçbir şey rota tabanlı demiyor, dolayısıyla doğru değerine ayarlanacak bir şey yok.

O alanı aramak sorunun ilk saatini yer, seçici değerlerini okumak ise son beş dakikayı alır.

Burada rota tabanlı ne demek

Google, Classic VPN'in rota tabanlı tünellerini yerel seçicisi 0.0.0.0/0 olan ilke tabanlı tüneller olarak belgeler. Yalnızca uzak aralıklar adlandırılır ve yerel taraf herhangi bir adres gibi ele alınır. Bu yüzden yapılandırmanızdaki işaret bir değerdir, mod değil. İki seçiciyi de açıkça yazın ve plan çıktısında okuyun:

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

O parçadaki eş öneki örnektir; önemli olan biçimdir.

Rota ayrı bir nesnedir

Tünel nesnesi bir rota kurmaz. Paketler tünelin ilkesiyle eşleşip yine de gidecek yer bulamayabilir, çünkü sonraki atlamayı VPC yönlendirme tablosu belirler. Rota için hedef aralığı, ağ, sonraki atlama olarak tünel ve daha geniş her şeyi yenen bir öncelik gerekir. Bunu unutursanız, bağlantı kuruldu bildiren bir tünel ve VPC'den hiç çıkmayan bir ping kalır.

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
}

Rotayı tünelle aynı modülde oluşturun, böylece ikisi incelemede birbirinden ayrılmasın.

Seçicileri eşte yansıtın

Uzak cihaz ayna görüntüsüyle yapılandırılmalıdır: yerel aralığı sizin uzak seçicinizdir ve uzak aralığı kullanmayı beklediğiniz GCP alt ağlarını kapsamalıdır. Taraflardan biri daralırsa, faz 1 başarılı olsa bile faz 2 başarısız olur. Konsolda doğru görünen ama trafik taşımayan bir yapılandırmanın en yaygın biçimi budur.

Değişiklik incelemesi sırasında iki tarafın seçicilerini yan yana yazdırın.

Statik adresi iki uygulamaya bölün

Ayrılmış adresi ve ona başvuran tüneli tek bir uygulamada oluşturmak, bilinen bir kararsızlık kaynağıdır çünkü adres, yönlendirme kuralı onu kullanabilmeden önce var olmalıdır. Önce yalnızca adres kaynağını uygulayın, sonra ağ geçidini, yönlendirme kurallarını ve tüneli ekleyip yeniden uygulayın. Terraform ikinci çalıştırmada mevcut adresi durumdan okur ve yeniden kullanır. Bunu atlarsanız tünel her uygulamada yeni bir genel adres alabilir ve bu her seferinde eş yapılandırmasını bozar.

Şimdi iki uygulama her sürümde eş değişikliğinden daha ucuz.

Etiketi değil, anlaşmayı doğrulayın

Uygulamadan sonra üç ayrı olguyu denetleyin: tünel bağlantı kuruldu bildiriyor, rota amaçlanan sonraki atlamayla var ve eş faz 1 ile faz 2'nin ikisinin de açık olduğunu bildiriyor.

Tünel açıkken faz 2 kapalıysa iki taraf seçiciler konusunda anlaşmıyor demektir:

  • Bir taraf diğerinin listelemediği bir alt ağı listeliyor.
  • Bir taraf diğerinin daralttığı bir toplu bloğu kullanıyor.
  • Rota var ama başka bir tünele işaret ediyor.

Classic VPN, HA VPN'den daha düşük SLA'ya sahip tek bir tüneldir ve HA VPN iki arabirim, iki tünel ve farklı kaynak türlerine sahip BGP kullanır. Klasik bir örneği HA yapılandırmasına kopyalayıp seçici alanlarının aynı davranacağını beklemek, kaçınılması gereken ayrı bir hatadır. Tünel alanlarının kendisi şurada belgelenmiştir: google_compute_vpn_tunnel başvurusu.

İlgili makaleler