Bakit Binabalewala ng AWS Client VPN ang Trapik na Walang Tugmang Ruta

Nagpapasa lang ang endpoint ng packet kapag sakop ng route table nito ang destinasyon. Basahin ang mga ruta, ideklara ang mga prefix gamit ang for_each, i-verify ang daan pabalik.

Nagbibigay ang Client VPN ng address sa client, natapos ang handshake, at wala pa ring patutunguhan ang koneksyon. Bago mo hawakan ang mga certificate o bersyon ng client, tingnan ang sariling route table ng endpoint. Nagpapasa lang ng packet ang isang AWS Client VPN endpoint kapag sakop ng isa sa mga ruta nito ang prefix ng destinasyon; kung walang tugma, itinatapon ang packet sa endpoint at hindi kailanman makikita ng target host ang SYN.

Desisyon ito sa pagpapasa, hindi sa pagpapatotoo. Nangyayari ito pagkatapos bumangon ang tunnel at pagkatapos masuri ang mga tuntunin sa awtorisasyon, kaya kahit may wastong certificate at wastong grupo, maaari pa ring maging patay ang koneksyon.

Ang endpoint ay nagpapasa lamang ng sakop ng route table nito

Ang bawat ruta ay isang destinasyong CIDR at ang subnet na dapat tumanggap ng trapik. Inihahambing ng endpoint ang destinasyon ng client sa listahang iyon, pinipili ang tugmang entry, at ipinapadala ang packet sa kaugnay na subnet. Walang entry, walang susunod na hop.

Pansinin kung ano ang hindi ruta. Hindi ito entry sa route table ng VPC, at wala itong awtorisadong anuman. Ang mga tuntunin sa awtorisasyon ang nagpapasya kung makakaabot ang isang grupo sa destinasyon; ang mga ruta ang nagpapasya kung may mapagpadalhan ang endpoint ng packet. Dapat magtugma ang dalawa, at nabigo sila sa magkaibang sintomas, kaya ang paghula kung alin ang sira ay nagsasayang ng isang hapon.

Ang klasikong diperensya ay isang peered na VPC. May nagdaragdag ng ruta para sa 10.20.0.0/24 samantalang nasa 10.20.4.0/24 ang host, kaya nahuhulog ang address sa labas ng bawat entry. Ang capture sa panig ng client ay nagpapakita ng paulit-ulit na SYN na walang sagot, at wala talagang ipinapakita ang mga log ng target.

Basahin ang listahan ng ruta bago ang certificate

Ang mga ruta ng endpoint ay hiwalay na object, kaya tanungin sila nang direkta sa halip na basahin ang talahanayan ng VPC:

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

Kunin ang eksaktong address at haba ng prefix mula sa bumabagsak na client, pagkatapos suriin ang saklaw titik-titik. Umiiral ang tugma ng pinakamahabang prefix, kaya hindi ka maililigtas ng mas malawak na ruta kapag ang mas makitid ay tumuturo sa ibang lugar.

Isang resource bawat destinasyon gamit ang for_each

Ang mga bloke ng rutang isinulat sa kamay ay lumilihis sa sandaling may magdagdag ng prefix sa console. Itago ang mga destinasyon sa isang mapa at gumawa ng isang resource bawat key, upang manatiling hiwalay ang bawat dagdag o tanggal.

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]
}

Panatilihin ang dependency sa network association. Kailangan ng ruta ang kaugnay na subnet, kaya ang apply na gumagawa ng pareho ay dapat iayos muna ang association, at kung wala ang reference na iyon, malaya ang Terraform na subukan muna ang ruta. Pagkatapos basahin ang plano: dapat tumugma ang bilang ng mga dagdag na ruta sa mga prefix na idinagdag mo. Kung pinapalitan din ng plano ang endpoint, mali ang pagkakasulat ng endpoint resource, at ang paglalapat nito ay pumuputol sa bawat konektadong client.

Pag-adopt ng endpoint na hindi mo ginawa

Karamihan ng team ay nagmamana ng endpoint na ginawa sa console, kaya walang code ng ruta. Huwag magtayo ng pangalawang endpoint para lang mapasok ang mga ruta sa Terraform.

I-import sa halip, o ipasa ang mga id bilang variable at iwanang hindi pinamamahalaan ang mga minanang object. Kailangan ng import ang format ng identifier na dokumentado ng provider para sa bawat uri ng resource; ine-encode nito ang endpoint, prefix ng destinasyon, at target subnet. Kopyahin ang string na iyon mula sa dokumentasyon ng resource sa halip na buuin mula sa memorya, magpatakbo ng plano, at asahan ang walang pagbabago bago ka magdagdag ng bago.

Sundan ang packet sa pagkakasunod-sunod ng paglalakbay nito

Kapag may ruta na at bumabagsak pa rin ang koneksyon, lakarin ang daan nang sunod-sunod sa halip na manghula sa pinakataas na layer.

  1. Ruta: sakop ng prefix ang destinasyon at tumuturo sa subnet na kaugnay ng endpoint.
  2. Awtorisasyon: pinapayagan ng tuntunin sa awtorisasyon ang destinasyong iyon para sa grupo ng user. Ang ruta lamang ay hindi kailanman nagbibigay ng access.
  3. Daan pabalik: ipinapadala ng route table ng target subnet ang mga sagot pabalik sa endpoint, at pinapayagan ng security group ang port mula sa pool ng address ng client.
  4. Aplikasyon: magbukas ng tunay na TCP connection mula sa client, pagkatapos tiyakin na ipinapakita ng mga log ng target ang inaasahang source address mula sa pool.

Baguhin ang isang prefix bawat apply, pagkatapos basahin muli ang listahan ng ruta, at itala nang sabay ang destinasyon, ang tuntuning nagbibigay ng awtorisasyon, at ang daan pabalik. Ang susunod na magde-debug ng tinanggihang koneksyon ay dapat magsimula sa imbentaryong iyon, hindi sa teorya tungkol sa certificate.

Kaugnay na mga artikulo