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 што ја создава рутата и го заборава правилото изгледа целосно. Тестирајте со еден корисник внатре во групата и еден надвор.

Кога еден префикс не успева, споредете го неговиот запис за рута со правилото за авторизација. Недостатокот на авторизација и недостатокот на рута изгледаат слично во дневникот на клиентот и се поправаат во различни ресурси.