Terraform Client VPN marşrutları: subnetlərdən çox CIDR ilə

Noutbuk Client VPN son nöqtəsinə qoşulur, amma terraform apply hələ də marşrut resursunda uğursuz olur. Konfiqurasiyada adətən əlaqəli subnetlərdən daha çox təyinat CIDR-i olur və marşrut bloku hədəfi indekslə seçir. Bu, iki kolleksiyanın paralel olduğunu fərz edir. Onlar deyil və nasazlıq baxış zamanı deyil, tətbiq zamanı üzə çıxır.

Uğursuz olan obyektin adını verin

Üç resurs iştirak edir və hər biri fərqli suala cavab verir. Assosiasiya son nöqtənin şəbəkə interfeysini bir subnete yerləşdirir. Marşrut hansı təyinat prefiksinin hədəf subnete çatdırıldığını bildirir. Avtorizasiya qaydası hansı istifadəçilərin hansı prefiksə çata biləcəyini bildirir. Heç vaxt əlaqələndirilməmiş subnete işarə edən marşrut, hər iki obyekt mövcud olsa da uğursuz olur, çünki hədəf bu son nöqtəyə aid olmalıdır.

Əvvəlcə assosiasiyaları sadalayın: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

VPC-nin yerli marşrutunu unutmayın

İlk assosiasiya bütün VPC üçün yerli marşrut əlavə edir, ona görə də həmin VPC-dəki hər subnet artıq marşrut resursu olmadan əlçatandır. Əlavə marşrutlar peered VPC-lər, Transit Gateway qoşmaları və VPC-yə aid olmayan on-premises prefiksləri üçün mövcuddur. Buna görə üç assosiasiyası olan son nöqtə qanuni olaraq yeddi təyinat qeydi daşıya bilər.

Marşrutlar əlavə etməzdən əvvəl VPC-dən kənarda qalan təyinatları sayın. Əgər bu say CIDR siyahısından kiçikdirsə, siyahı heç bir marşruta ehtiyacı olmayan subnetləri təsvir edir.

İndeksi xəritə ilə əvəz edin

İndeksi modul operatoruna bükmək xətanı susdurur və modelləşdirmə səhvini saxlayır. Seçilmiş hədəf vasitəsilə çatmaq mümkün olmayan təyinat, plan nə qədər təmiz tətbiq olunsa da, yenə heç bir trafik daşımır. Bunun əvəzinə əlaqəni saxlayın və Terraform heç nə yaratmazdan əvvəl onu yoxlasın. Aşağıdakı blok nümunə xarakteri daşıyır və provayderin son nöqtə marşrut arqumentlərindən istifadə edir.

variable "client_vpn_destinations" {
  description = "Destination CIDR mapped to an associated subnet key"
  type        = map(string)
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_destinations
  client_vpn_endpoint_id = aws_ec2_client_vpn_endpoint.this.id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = aws_subnet.private[each.value].id

  lifecycle {
    precondition {
      condition     = contains(keys(aws_subnet.private), each.value)
      error_message = "Route target must be a subnet key in the associated map."
    }
  }
}

Xəritə assosiasiya siyahısının yanında olduqda, təyinat əlavə etmək onu hansı subnetin daşıyacağı barədə qərar tələb edir. Bu, indeksin gizlətdiyi söhbətdir.

Fərqli bir nasazlıq indeks xətası yerinə mənasız dəyərlər yaradır. Yüksək səviyyəli interfeys gözlənilən yerdə aşağı səviyyəli konstruksiya ötürmək API-nin oxuduğu sahələri doldurulmamış qoyur və nəticədə yaranan CIDR istifadəsiz olur. Obyekt gözlənilən yerdə sətir gəldikdə Terraform eyni forması göstərir. Arqument növü üçün provayder sxemini yoxlayın.

Bunu bir müştəridən sübut edin

Tətbiqdən əvvəl terraform validate və real vəziyyətə qarşı plan işə salın. Sonra uğurlu apply-a güvənmək əvəzinə son nöqtənin hədəf şəbəkə siyahısını xəritə ilə müqayisə edin.

Qəbul testi hər nəzərdə tutulan prefiksə çatan qoşulmuş müştəridir.

Avtorizasiya qaydası bir çox qurğunun erkən dayandığı yerdir. O, təyinat CIDR-i və qrupla məhdudlaşır və uyğun avtorizasiyası olmayan marşrut prefiksə çata bilməyən qoşulmuş müştəri yaradır. Hər prefiks üçün hər iki obyekti yoxlayın, çünki marşrutu yaradan və qaydanı unudan apply tam görünür. Qrupun içində bir istifadəçi və ondan kənarda bir istifadəçi ilə sınaqdan keçirin.

Bir prefiks uğursuz olduqda, onun marşrut qeydini avtorizasiya qaydası ilə müqayisə edin. Çatışmayan avtorizasiya və çatışmayan marşrut müştəri jurnalında oxşar görünür və fərqli resurslarda düzəldilir.