Terraform Client VPN მარშრუტები ქვექსელებზე მეტი CIDR-ით

ლეპტოპი უკავშირდება Client VPN ენდპოინტს და terraform apply კვლავ მარცხდება მარშრუტის რესურსზე. კონფიგურაციაში ჩვეულებრივ უფრო მეტი დანიშნულების CIDR არის, ვიდრე ასოცირებული ქვექსელი, და მარშრუტის ბლოკი სამიზნეს ინდექსით ირჩევს. ეს ვარაუდობს, რომ ორი კოლექცია პარალელურია. ისინი არ არიან და შეცდომა გამოყენების დროს ჩნდება და არა განხილვისას.

დაასახელეთ ობიექტი, რომელიც მარცხდება

სამი რესურსი მონაწილეობს და თითოეული სხვადასხვა კითხვას პასუხობს. ასოციაცია ენდპოინტის ქსელურ ინტერფეისს ქვექსელში ათავსებს. მარშრუტი ამბობს, რომელი დანიშნულების პრეფიქსი მიეწოდება სამიზნე ქვექსელს. ავტორიზაციის წესი ამბობს, რომელი მომხმარებლები შეიძლება მივიდნენ რომელ პრეფიქსამდე. მარშრუტი, რომელიც ქვექსელზე მიუთითებს, რომელიც არასოდეს ასოცირებულა, მარცხდება მაშინაც კი, როცა ორივე ობიექტი არსებობს, რადგან სამიზნე ამ ენდპოინტს უნდა ეკუთვნოდეს.

ჯერ ჩამოთვალეთ ასოციაციები: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

გაიხსენეთ VPC-ის ლოკალური მარშრუტი

პირველი ასოციაცია ლოკალურ მარშრუტს ამატებს მთელი VPC-ისთვის, ამიტომ ამ VPC-ის ყველა ქვექსელი უკვე ხელმისაწვდომია მარშრუტის რესურსის გარეშე. დამატებითი მარშრუტები არსებობს დაწყვილებული VPC-ებისთვის, Transit Gateway კავშირებისთვის და on-premises პრეფიქსებისთვის, რომლებიც VPC-ს არ ეკუთვნის. ამიტომ სამი ასოციაციის მქონე ენდპოინტს კანონიერად შეუძლია შვიდი დანიშნულების ჩანაწერის ტარება.

სანამ მარშრუტებს დაამატებთ, დაითვალეთ VPC-ის გარეთ მდებარე დანიშნულებები. თუ ეს რაოდენობა CIDR-ების სიაზე ნაკლებია, სია აღწერს ქვექსელებს, რომლებსაც საერთოდ არ სჭირდებათ მარშრუტი.

შეცვალეთ ინდექსი რუკით

ინდექსის მოდულო ოპერატორში გახვევა აჩუმებს შეცდომას და ინარჩუნებს მოდელირების შეცდომას. დანიშნულება, რომელსაც არჩეული სამიზნის გავლით ვერ მივაღწევთ, კვლავ არ ატარებს ტრაფიკს, რაც არ უნდა სუფთად გამოიყენებოდეს გეგმა. სამაგიეროდ შეინახეთ კავშირი და მიეცით Terraform-ს მისი შემოწმების საშუალება, სანამ რაიმეს შექმნის. ქვემოთ მოცემული ბლოკი საილუსტრაციოა და იყენებს პროვაიდერის ენდპოინტის მარშრუტის არგუმენტებს.

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."
    }
  }
}

როცა რუკა ასოციაციების სიის გვერდითაა, დანიშნულების დამატება აიძულებს გადაწყვეტილებას, რომელი ქვექსელი ატარებს მას. ეს არის ის საუბარი, რომელსაც ინდექსი მალავდა.

სხვა მარცხი ინდექსის შეცდომის ნაცვლად უაზრო მნიშვნელობებს წარმოქმნის. დაბალი დონის კონსტრუქციის გადაცემა იქ, სადაც უფრო მაღალი დონის ინტერფეისი მოსალოდნელია, API-ის მიერ წაკითხულ ველებს აუვსებელს ტოვებს და მიღებული CIDR გამოუსადეგარია. Terraform იგივე ფორმას აჩვენებს, როცა სტრიქონი მოდის იქ, სადაც ობიექტი მოსალოდნელია. შეამოწმეთ პროვაიდერის სქემა არგუმენტის ტიპისთვის.

დაამტკიცეთ კლიენტიდან

გამოყენებამდე გაუშვით terraform validate და გეგმა რეალურ მდგომარეობასთან. შემდეგ შეადარეთ ენდპოინტის სამიზნე ქსელების სია რუკას, ნაცვლად წარმატებული apply-ის ნდობისა.

მიღების ტესტი არის დაკავშირებული კლიენტი, რომელიც აღწევს ყველა განზრახ პრეფიქსამდე.

ავტორიზაციის წესი არის ადგილი, სადაც ბევრი კონფიგურაცია ადრე ჩერდება. ის შემოიფარგლება დანიშნულების CIDR-ით და ჯგუფით, და მარშრუტი შესაბამისი ავტორიზაციის გარეშე ქმნის დაკავშირებულ კლიენტს, რომელიც ვერ აღწევს პრეფიქსამდე. შეამოწმეთ ორივე ობიექტი ყოველი პრეფიქსისთვის, რადგან apply, რომელიც მარშრუტს ქმნის და წესს ივიწყებს, სრულად გამოიყურება. გამოსცადეთ ჯგუფში ერთი და მის გარეთ ერთი მომხმარებლით.

როცა ერთი პრეფიქსი მარცხდება, შეადარეთ მისი მარშრუტის ჩანაწერი ავტორიზაციის წესს. დაკარგული ავტორიზაცია და დაკარგული მარშრუტი კლიენტის ჟურნალში მსგავსად ჩანს და სხვადასხვა რესურსში სწორდება.