Hvorfor AWS Client VPN slipper trafikk uten en samsvarende rute

Endepunktet videresender bare en pakke når rutetabellen dekker destinasjonen. Les rutene, deklarer prefikser med for_each, verifiser returveien.

Client VPN gir klienten en adresse, håndtrykket fullføres, og forbindelsen fører fortsatt ingen steder. Før du rører sertifikater eller klientversjoner, se på endepunktets egen rutetabell. Et AWS Client VPN-endepunkt videresender bare en pakke når en av rutene dekker destinasjonsprefikset; hvis ingenting samsvarer, forkastes pakken ved endepunktet, og målverten ser aldri et SYN.

Det er en videresendingsbeslutning, ikke en autentiseringsbeslutning. Den tas etter at tunnelen er oppe og etter at autorisasjonsreglene er evaluert, og derfor kan et gyldig sertifikat og en gyldig gruppe fortsatt gi en død forbindelse.

Endepunktet videresender bare det rutetabellen dekker

Hver rute er et destinasjons-CIDR pluss subnettet som skal motta trafikken. Endepunktet sammenligner klientens destinasjon med listen, velger den samsvarende oppføringen og sender pakken inn i det tilknyttede subnettet. Ingen oppføring betyr ingen neste hopp.

Legg merke til hva ruten ikke er. Den er ikke en oppføring i VPC-ens rutetabell, og den autoriserer ingenting. Autorisasjonsregler avgjør om en gruppe kan nå en destinasjon; ruter avgjør om endepunktet har et sted å sende pakken. Begge må stemme, og de feiler med ulike symptomer, så å gjette hvilken som er ødelagt koster en ettermiddag.

Det klassiske misforholdet er en peeret VPC. Noen legger til en rute for 10.20.0.0/24 mens verten bor i 10.20.4.0/24, så adressen faller utenfor hver oppføring. En opptak på klientsiden viser gjentatte SYN uten svar, og loggene på målet viser ingenting i det hele tatt.

Les ruteoversikten før sertifikatet

Endepunktets ruter er et eget objekt, så spør dem direkte i stedet 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 adressen og prefikslengden fra klienten som feiler, og sjekk deretter dekningen tegn for tegn. Lengste prefiks gjelder, så en bredere rute redder deg ikke når en smalere peker et annet sted.

Én ressurs per destinasjon med for_each

Håndskrevne rutelokk driver i samme øyeblikk som noen legger til et prefiks i konsollen. Hold destinasjonene i et kart og opprett én ressurs per nøkkel, så hver tilføyelse eller fjerning holder 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]
}

Behold avhengigheten til nettverkstilknytningen. En rute trenger et tilknyttet subnett, så et apply som oppretter begge må ordne tilknytningen først, og uten den referansen står Terraform fritt til å prøve ruten først. Les deretter planen: antall rutetilføyelser skal samsvare med prefiksene du la til. Hvis planen også erstatter endepunktet, er endepunktressursen skrevet feil, og å bruke den kobler fra hver tilkoblet klient.

Å overta et endepunkt du ikke har opprettet

De fleste team arver et endepunkt bygget i konsollen, og derfor finnes det ingen rutekode. Ikke reis et ekstra endepunkt bare for å få ruter inn i Terraform.

Importer i stedet, eller send id-ene inn som variabler og la de arvede objektene være uten styring. Import krever id-formatet leverandøren dokumenterer for hver ressurstype; det koder endepunktet, destinasjonsprefikset og målsubnettet. Kopier den strengen fra ressursdokumentasjonen i stedet for å sette den sammen fra hukommelsen, kjør en plan, og forvent ingen endringer før du legger til noe nytt.

Følg pakken i den rekkefølgen den reiser

Når ruten finnes og forbindelsen fortsatt feiler, gå veien i rekkefølge i stedet for å gjette på det øverste laget.

  1. Rute: et prefiks dekker destinasjonen og peker på et subnett tilknyttet endepunktet.
  2. Autorisasjon: en autorisasjonsregel tillater destinasjonen for brukerens gruppe. En rute alene gir aldri tilgang.
  3. Returvei: målsubnettets rutetabell sender svar tilbake mot endepunktet, og sikkerhetsgruppen tillater porten fra klientens adressepool.
  4. Applikasjon: åpne en ekte TCP-forbindelse fra klienten, og bekreft deretter at loggene på målet viser den forventede kildeadressen fra poolen.

Endre ett prefiks per apply, les ruteoversikten på nytt etterpå, og noter destinasjonen, den autoriserende regelen og returveien sammen. Den neste som feilsøker en avvist forbindelse, bør starte fra den oversikten, ikke fra en sertifikatteori.

Relaterte artikler