Kvifor AWS Client VPN slepp trafikk utan ei samsvarande rute

Endepunktet sender berre ein pakke vidare når rutetabellen dekkjer destinasjonen. Les rutene, erklær prefiks med for_each, stadfest returvegen.

Client VPN gir klienten ein adresse, handtrykket blir fullført, og sambandet fører framleis ingen stad. Før du rører sertifikat eller klientversjonar, sjå på rutetabellen til endepunktet sjølv. Eit AWS Client VPN-endepunkt sender berre ein pakke vidare når ei av rutene dekkjer destinasjonsprefikset; viss ingenting passar, blir pakken kasta ved endepunktet, og målverten ser aldri eit SYN.

Det er eit vidaresendingsval, ikkje eit autentiseringsval. Det blir teke etter at tunnelen er oppe og etter at autorisasjonsreglane er vurderte, og difor kan eit gyldig sertifikat og ei gyldig gruppe framleis gi eit daudt samband.

Endepunktet sender berre vidare det rutetabellen dekkjer

Kvar rute er eit destinasjons-CIDR pluss subnettet som skal ta imot trafikken. Endepunktet samanliknar destinasjonen til klienten med lista, vel den samsvarande oppføringa og sender pakken inn i det tilknytte subnettet. Inga oppføring tyder ingen neste hopp.

Legg merke til kva ruta ikkje er. Ho er ikkje ei oppføring i rutetabellen til VPC-en, og ho autoriserer ingenting. Autorisasjonsreglar avgjer om ei gruppe kan nå ein destinasjon; ruter avgjer om endepunktet har ein stad å sende pakken. Begge må stemme, og dei feilar med ulike symptom, så å gjette kva som er øydelagt kostar ein ettermiddag.

Den klassiske misforten er ein peera VPC. Nokon legg til ei rute for 10.20.0.0/24 medan verten bur i 10.20.4.0/24, så adressa fell utanfor kvar oppføring. Eit opptak på klientsida viser gjentekne SYN utan svar, og loggane på målet viser ingenting i det heile.

Les ruteoversikta før sertifikatet

Rutene til endepunktet er eit eige objekt, så spør dei direkte i staden for å lese VPC-tabellen:

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

Ta den nøyaktige adressa og prefikslengda frå klienten som feilar, og sjekk så dekninga teikn for teikn. Lengste prefiks gjeld, så ei breiare rute bergar deg ikkje når ei smalare peikar ein annan stad.

Éin ressurs per destinasjon med for_each

Handskrivne rutelokk driv i same augneblunken som nokon legg til eit prefiks i konsollen. Hald destinasjonane i eit kart og lag éin ressurs per nøkkel, så kvar tilføying eller fjerning held seg isolert.

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

Hald på avhengnaden til nettverkstilknytinga. Ei rute treng eit tilknytt subnett, så ein apply som lagar begge må ordne tilknytinga først, og utan den referansen står Terraform fritt til å prøve ruta først. Les så planen: talet på rutetilføyingar skal samsvare med prefiksa du la til. Viss planen også byter ut endepunktet, er endepunktressursen skriven feil, og å bruke han koplar frå kvar tilkopla klient.

Å ta over eit endepunkt du ikkje har laga

Dei fleste team arvar eit endepunkt bygd i konsollen, og difor finst det ingen rutekode. Ikkje reis eit ekstra endepunkt berre for å få ruter inn i Terraform.

Importer i staden, eller send id-ane inn som variablar og lat dei arva objekta vere utan styring. Import krev id-formatet leverandøren dokumenterer for kvar ressurstype; det kodar endepunktet, destinasjonsprefikset og målsubnettet. Kopier den strengen frå ressursdokumentasjonen i staden for å setje han saman frå minnet, køyr ein plan, og vent ingen endringar før du legg til noko nytt.

Følg pakken i den rekkjefølgja han reiser

Når ruta finst og sambandet framleis feilar, gå vegen i rekkjefølgje i staden for å gjette på det øvste laget.

  1. Rute: eit prefiks dekkjer destinasjonen og peikar på eit subnett som er tilknytt endepunktet.
  2. Autorisasjon: ein autorisasjonsregel tillèt destinasjonen for gruppa til brukaren. Ei rute åleine gir aldri tilgang.
  3. Returveg: rutetabellen til målsubnettet sender svar tilbake mot endepunktet, og tryggingsgruppa tillèt porten frå adressepoolen til klienten.
  4. Applikasjon: opne ein ekte TCP-samband frå klienten, og stadfest så at loggane på målet viser den venta kjeldeadressa frå poolen.

Endre eitt prefiks per apply, les ruteoversikta på nytt etterpå, og noter destinasjonen, den autoriserande regelen og returvegen saman. Den neste som feilsøkjer eit avvist samband, bør starte frå den oversikta, ikkje frå ein sertifikatteori.

Relaterte artiklar