Чому AWS Client VPN відкидає трафік без відповідного маршруту

Кінцева точка передає пакет лише тоді, коли її таблиця маршрутів покриває призначення. Прочитайте маршрути, оголосіть префікси через for_each, перевірте зворотний шлях.

Client VPN видає клієнту адресу, рукостискання завершується, а з'єднання все одно нікуди не веде. Перш ніж чіпати сертифікати або версії клієнта, подивіться на власну таблицю маршрутів кінцевої точки. Кінцева точка AWS Client VPN передає пакет лише тоді, коли один із її маршрутів покриває префікс призначення; якщо нічого не збігається, пакет відкидається на кінцевій точці, і цільовий хост ніколи не бачить SYN.

Це рішення про пересилання, а не про автентифікацію. Воно ухвалюється після підняття тунелю й після оцінки правил авторизації, тому чинний сертифікат і чинна група все одно можуть дати мертве з'єднання.

Кінцева точка пересилає лише те, що покриває її таблиця маршрутів

Кожен маршрут — це CIDR призначення плюс підмережа, яка має отримати трафік. Кінцева точка порівнює призначення клієнта з цим списком, вибирає відповідний запис і надсилає пакет у пов'язану підмережу. Немає запису — немає наступного стрибка.

Зверніть увагу, чим маршрут не є. Це не запис у таблиці маршрутів VPC, і він нічого не авторизує. Правила авторизації вирішують, чи може група дістатися призначення; маршрути вирішують, чи має кінцева точка куди надіслати пакет. Обидва мають збігатися, а відмовляють вони з різними симптомами, тож вгадування, що саме зламано, витрачає півдня.

Класична невідповідність — це VPC з пірингом. Хтось додає маршрут для 10.20.0.0/24, тоді як хост живе в 10.20.4.0/24, тому адреса опиняється поза кожним записом. Запис на боці клієнта показує повторювані SYN без відповіді, а журнали цілі не показують геть нічого.

Прочитайте список маршрутів раніше за сертифікат

Маршрути кінцевої точки — окремий об'єкт, тому запитуйте їх безпосередньо, а не читайте таблицю VPC:

aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 --query 'Routes[].{Dest:DestinationCidr,Target:TargetSubnet,Origin:Origin}'

Візьміть точну адресу й довжину префікса в клієнта, що не працює, потім перевірте покриття символ за символом. Діє збіг найдовшого префікса, тому ширший маршрут не врятує, якщо вужчий указує в інше місце.

Один ресурс на призначення через for_each

Написані вручну блоки маршрутів розходяться тієї ж миті, коли хтось додає префікс у консолі. Тримайте призначення в мапі й створюйте один ресурс на ключ, щоб кожне додавання чи видалення лишалося ізольованим.

variable "client_vpn_routes" {
  type = map(string)
  default = {
    "10.20.0.0/16"  = "subnet-0aa11bb22cc33dd44"
    "172.31.0.0/20" = "subnet-0aa11bb22cc33dd44"
  }
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_routes
  client_vpn_endpoint_id = var.client_vpn_endpoint_id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = each.value
  depends_on             = [aws_ec2_client_vpn_network_association.this]
}

Збережіть залежність від мережевої асоціації. Маршруту потрібна пов'язана підмережа, тому apply, який створює обидва, має спершу впорядкувати асоціацію, і без цього посилання Terraform вільний спробувати маршрут першим. Потім прочитайте план: кількість доданих маршрутів має збігатися з доданими префіксами. Якщо план ще й замінює кінцеву точку, ресурс кінцевої точки написано неправильно, і його застосування від'єднає кожного підключеного клієнта.

Прийняття кінцевої точки, яку ви не створювали

Більшість команд успадковують кінцеву точку, побудовану в консолі, тому коду маршрутів не існує. Не піднімайте другу кінцеву точку лише для того, щоб завести маршрути в Terraform.

Натомість імпортуйте або передайте id як змінні й залиште успадковані об'єкти некерованими. Імпорту потрібен формат ідентифікатора, який провайдер документує для кожного типу ресурсу; він кодує кінцеву точку, префікс призначення й цільову підмережу. Скопіюйте цей рядок із документації ресурсу, а не складайте з пам'яті, запустіть план і очікуйте відсутності змін, перш ніж додавати щось нове.

Прослідкуйте пакет у тому порядку, у якому він рухається

Якщо маршрут є, а з'єднання все одно не працює, пройдіть шлях по порядку, а не вгадуйте на верхньому рівні.

  1. Маршрут: префікс покриває призначення й указує на підмережу, пов'язану з кінцевою точкою.
  2. Авторизація: правило авторизації дозволяє це призначення для групи користувача. Сам маршрут ніколи не дає доступу.
  3. Зворотний шлях: таблиця маршрутів цільової підмережі надсилає відповіді назад до кінцевої точки, а група безпеки дозволяє порт із пулу адрес клієнта.
  4. Застосунок: відкрийте справжнє TCP-з'єднання з клієнта, потім підтвердьте, що журнали цілі показують очікувану адресу джерела з пулу.

Змінюйте по одному префіксу за apply, потім перечитайте список маршрутів і запишіть разом призначення, правило, що авторизує, і зворотний шлях. Наступна людина, яка відлагоджуватиме відхилене з'єднання, має почати з цього переліку, а не з теорії про сертифікати.

Схожі статті