Защо 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.

Вместо това импортирайте или подайте идентификаторите като променливи и оставете наследените обекти неуправлявани. Импортът изисква формата на идентификатора, който доставчикът документира за всеки тип ресурс; той кодира крайната точка, префикса на дестинацията и целевата подмрежа. Копирайте този низ от документацията на ресурса, вместо да го съставяте по памет, пуснете план и очаквайте липса на промени, преди да добавите нещо ново.

Проследете пакета в реда, в който пътува

Когато маршрутът съществува, а връзката все още се проваля, извървете пътя по ред, вместо да гадаете на горния слой.

  1. Маршрут: префикс покрива дестинацията и сочи подмрежа, свързана с крайната точка.
  2. Оторизация: правило за оторизация разрешава тази дестинация за групата на потребителя. Само маршрут никога не дава достъп.
  3. Обратен път: таблицата с маршрути на целевата подмрежа изпраща отговорите обратно към крайната точка, а групата за сигурност разрешава порта от пула с адреси на клиентите.
  4. Приложение: отворете истинска TCP връзка от клиента, после потвърдете, че журналите на целта показват очаквания адрес на източника от пула.

Променяйте по един префикс на apply, след това прочетете отново списъка с маршрути и запишете дестинацията, оторизиращото правило и обратния път заедно. Следващият човек, който отстранява отказана връзка, трябва да започне от този опис, а не от теория за сертификатите.

Подобни статии