Pse AWS Client VPN hedh trafikun pa një rrugë përputhëse

Pika fundore përcjell një paketë vetëm kur tabela e rrugëve mbulon destinacionin. Lexoni rrugët, deklaroni prefikset me for_each, verifikoni rrugën e kthimit.

Client VPN i jep klientit një adresë, shtrëngimi i duarve përfundon, dhe lidhja ende nuk shkon askund. Përpara se të prekni certifikatat ose versionet e klientit, shikoni tabelën e rrugëve të vetë pikës fundore. Një pikë fundore AWS Client VPN përcjell një paketë vetëm kur njëra nga rrugët e saj mbulon prefiksin e destinacionit; nëse asgjë nuk përputhet, paketa hidhet në pikën fundore dhe hosti i synuar nuk sheh kurrë SYN.

Ky është një vendim përcjelljeje, jo autentikimi. Ndodh pasi tuneli të jetë ngritur dhe pasi rregullat e autorizimit të vlerësohen, prandaj një certifikatë e vlefshme dhe një grup i vlefshëm mund të prodhojnë ende një lidhje të vdekur.

Pika fundore përcjell vetëm atë që mbulon tabela e saj e rrugëve

Çdo rrugë është një CIDR destinacioni plus nënrrjeti që duhet të marrë trafikun. Pika fundore krahason destinacionin e klientit me atë listë, zgjedh hyrjen përputhëse dhe e dërgon paketën në nënrrjetin e lidhur. Pa hyrje nuk ka kërcim tjetër.

Vini re çfarë nuk është rruga. Nuk është hyrje në tabelën e rrugëve të VPC-së dhe nuk autorizon asgjë. Rregullat e autorizimit vendosin nëse një grup mund të arrijë një destinacion; rrugët vendosin nëse pika fundore ka ku ta dërgojë paketën. Të dyja duhet të përputhen, dhe dështojnë me simptoma të ndryshme, prandaj hamendësimi se cila është prishur harxhon një pasdite.

Mospërputhja klasike është një VPC me peering. Dikush shton një rrugë për 10.20.0.0/24 ndërsa hosti jeton në 10.20.4.0/24, kështu që adresa bie jashtë çdo hyrjeje. Një kapje në anën e klientit tregon SYN të përsëritura pa përgjigje, dhe regjistrat e synimit nuk tregojnë absolutisht asgjë.

Lexoni listën e rrugëve përpara certifikatës

Rrugët e pikës fundore janë një objekt më vete, prandaj pyesni ato drejtpërdrejt në vend që të lexoni tabelën e VPC-së:

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

Merrni adresën e saktë dhe gjatësinë e prefiksit nga klienti që dështon, pastaj kontrolloni mbulimin karakter për karakter. Zbatohet përputhja e prefiksit më të gjatë, prandaj një rrugë më e gjerë nuk ju shpëton kur një më e ngushtë tregon diku tjetër.

Një burim për destinacion me for_each

Blloqet e rrugëve të shkruara me dorë largohen në momentin kur dikush shton një prefiks në konsolë. Mbani destinacionet në një hartë dhe krijoni një burim për çdo çelës, që çdo shtim ose heqje të mbetet i izoluar.

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

Ruani varësinë nga shoqërimi i rrjetit. Një rrugë ka nevojë për një nënrrjet të shoqëruar, prandaj një apply që krijon të dyja duhet të rendisë shoqërimin së pari, dhe pa atë referencë Terraform është i lirë të provojë rrugën së pari. Më pas lexoni planin: numri i shtimeve të rrugëve duhet të përputhet me prefikset që keni shtuar. Nëse plani zëvendëson edhe pikën fundore, burimi i pikës fundore është shkruar gabimisht, dhe zbatimi i tij shkëput çdo klient të lidhur.

Miratimi i një pike fundore që nuk e krijuat

Shumica e ekipeve trashëgojnë një pikë fundore të ndërtuar në konsolë, prandaj nuk ekziston kod rrugësh. Mos ngrini një pikë të dytë fundore vetëm për të futur rrugët në Terraform.

Në vend të kësaj importoni, ose kaloni id-të si variabla dhe lini objektet e trashëguara pa menaxhim. Importi kërkon formatin e identifikuesit që ofruesi dokumenton për çdo lloj burimi; ai kodon pikën fundore, prefiksin e destinacionit dhe nënrrjetin e synuar. Kopjoni atë varg nga dokumentacioni i burimit në vend që ta hartoni nga kujtesa, ekzekutoni një plan dhe prisni që nuk ka ndryshime përpara se të shtoni diçka të re.

Ndjekni paketën në rendin që udhëton

Kur rruga ekziston dhe lidhja ende dështon, ecni rrugën me radhë në vend që të hamendësoni në shtresën e sipërme.

  1. Rruga: një prefiks mbulon destinacionin dhe tregon një nënrrjet të shoqëruar me pikën fundore.
  2. Autorizimi: një rregull autorizimi lejon atë destinacion për grupin e përdoruesit. Vetëm rruga nuk jep kurrë akses.
  3. Rruga e kthimit: tabela e rrugëve e nënrrjetit të synuar i dërgon përgjigjet mbrapsht drejt pikës fundore, dhe grupi i sigurisë lejon portin nga pishina e adresave të klientit.
  4. Aplikacioni: hapni një lidhje të vërtetë TCP nga klienti, pastaj konfirmoni që regjistrat e synimit tregojnë adresën e pritur të burimit nga pishina.

Ndryshoni një prefiks për apply, pastaj rilexoni listën e rrugëve dhe shkruani së bashku destinacionin, rregullin që autorizon dhe rrugën e kthimit. Personi tjetër që do të korrigjojë një lidhje të refuzuar duhet të nisë nga ai inventar, jo nga një teori mbi certifikatat.

Artikuj të ngjashëm