Зошто AWS Client VPN го отфрла сообраќајот без соодветна рута

Крајната точка препраќа пакет само кога нејзината табела со рути ја покрива дестинацијата. Прочитајте ги рутите, декларирајте префикси со for_each, проверете го повратниот пат.

Client VPN му дава адреса на клиентот, ракувањето завршува, а врската сепак не оди никаде. Пред да ги допрете сертификатите или верзиите на клиентот, погледнете ја сопствената табела со рути на крајната точка. Крајна точка на AWS Client VPN препраќа пакет само кога една од нејзините рути го покрива префиксот на дестинацијата; ако ништо не се совпаѓа, пакетот се отфрла на крајната точка и целниот домаќин никогаш не гледа SYN.

Тоа е одлука за препраќање, а не за автентикација. Се случува откако тунелот ќе се подигне и откако ќе се оценат правилата за авторизација, затоа валиден сертификат и валидна група сепак можат да дадат мртва врска.

Крајната точка препраќа само тоа што го покрива нејзината табела со рути

Секоја рута е CIDR на дестинацијата плус подмрежата што треба да го прими сообраќајот. Крајната точка ја споредува дестинацијата на клиентот со тој список, ја избира соодветната ставка и го испраќа пакетот во поврзаната подмрежа. Нема ставка значи нема следен скок.

Обрнете внимание што рутата не е. Таа не е ставка во табелата со рути на VPC и не авторизира ништо. Правилата за авторизација одлучуваат дали групата може да стигне до дестинација; рутите одлучуваат дали крајната точка има каде да го испрати пакетот. Двете мора да се совпаднат, а тие откажуваат со различни симптоми, па погодувањето која е расипана троши цело попладне.

Класичното несовпаѓање е VPC со peer. Некој додава рута за 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, потоа прочитајте го списокот со рути повторно и запишете ги заедно дестинацијата, правилото што авторизира и повратниот пат. Следниот човек што ќе отстранува дефект на одбиена врска треба да почне од тој список, а не од теорија за сертификати.

Поврзани статии