Маршрути на 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 вече е достъпна без ресурс за маршрут. Допълнителни маршрути съществуват за peered 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, който създава маршрута и забравя правилото, изглежда завършен. Тествайте с един потребител в групата и един извън нея.

Когато един префикс се провали, сравнете неговия запис за маршрут с правилото за оторизация. Липсваща оторизация и липсващ маршрут изглеждат сходно в клиентския журнал и се поправят в различни ресурси.