Маршрути Terraform Client VPN з більшою кількістю CIDR, ніж підмереж
Зіставлення, маршрут і авторизація — окремі об'єкти. Зіставте кожен цільовий 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, який створює маршрут і забуває правило, виглядає завершеним. Перевірте з одним користувачем у групі й одним поза нею.
Коли один префікс зазнає збою, порівняйте запис його маршруту з правилом авторизації. Відсутня авторизація й відсутній маршрут виглядають схоже в журналі клієнта й виправляються в різних ресурсах.