Чаму 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, пасля гэтага перачытайце спіс маршрутаў і запішыце прызначэнне, правіла аўтарызацыі і зваротны шлях разам. Наступны чалавек, які будзе адладжваць адхіленае злучэнне, павінен пачаць з гэтага інвентару, а не з тэорыі пра сертыфікаты.

Падобныя артыкулы