Hvorfor AWS Client VPN dropper trafik uden en matchende rute

Endepunktet videresender kun en pakke, når dets rutetabel dækker destinationen. Læs ruterne, deklarér præfikser med for_each, verificér returvejen.

Client VPN giver klienten en adresse, håndtrykket fuldføres, og forbindelsen fører stadig ingen steder hen. Før du rører ved certifikater eller klientversioner, så kig på endepunktets egen rutetabel. Et AWS Client VPN-endepunkt videresender kun en pakke, når en af dets ruter dækker destinationspræfikset; hvis intet matcher, kasseres pakken ved endepunktet, og målværten ser aldrig et SYN.

Det er en videresendelsesbeslutning, ikke en autentificeringsbeslutning. Den træffes, efter tunnelen er oppe, og efter autorisationsreglerne er evalueret, og derfor kan et gyldigt certifikat og en gyldig gruppe stadig give en død forbindelse.

Endepunktet videresender kun det, dets rutetabel dækker

Hver rute er et destinations-CIDR plus det undernet, der skal modtage trafikken. Endepunktet holder klientens destination op mod listen, vælger den matchende post og sender pakken ind i det tilknyttede undernet. Ingen post betyder intet næste hop.

Læg mærke til, hvad ruten ikke er. Den er ikke en post i VPC'ens rutetabel, og den autoriserer intet. Autorisationsregler afgør, om en gruppe må nå en destination; ruter afgør, om endepunktet har et sted at sende pakken hen. Begge skal passe sammen, og de fejler med forskellige symptomer, så at gætte på, hvilken der er i stykker, spilder en eftermiddag.

Den klassiske uoverensstemmelse er en peered VPC. Nogen tilføjer en rute til 10.20.0.0/24, mens værten ligger i 10.20.4.0/24, så adressen falder uden for hver post. En optagelse på klientsiden viser gentagne SYN'er uden svar, og målets logfiler viser intet som helst.

Læs ruttelisten før certifikatet

Endepunktets ruter er deres eget objekt, så forespørg dem direkte i stedet for at læse VPC-tabellen:

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

Tag den præcise adresse og præfikslængde fra den fejlende klient, og kontrollér derefter dækningen tegn for tegn. Længste præfiks-match gælder, så en bredere rute redder dig ikke, når en smallere peger et andet sted hen.

Én ressource pr. destination med for_each

Håndskrevne rutetabeller driver, i samme øjeblik nogen tilføjer et præfiks i konsollen. Hold destinationerne i et map, og opret én ressource pr. nøgle, så hver tilføjelse eller fjernelse forbliver isoleret.

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 afhængigheden af netværkstilknytningen. En rute kræver et tilknyttet undernet, så et apply, der opretter begge, skal ordne tilknytningen først, og uden den reference står Terraform frit til at prøve ruten først. Læs derefter planen: antallet af rutetilføjelser skal svare til de præfikser, du tilføjede. Hvis planen også erstatter endepunktet, er endepunktets ressource skrevet forkert, og at anvende den afbryder hver tilsluttet klient.

At overtage et endepunkt, du ikke selv har oprettet

De fleste teams arver et endepunkt bygget i konsollen, og derfor findes der ingen rutekode. Rejs ikke et ekstra endepunkt bare for at få ruter ind i Terraform.

Importer i stedet, eller send id'erne ind som variabler og lad de arvede objekter være uden for styring. Import kræver det id-format, udbyderen dokumenterer for hver ressourcetype, og som indkoder endepunktet, destinationspræfikset og målundernettet. Kopiér den streng fra ressourcedokumentationen i stedet for at sammensætte den fra hukommelsen, kør en plan, og forvent ingen ændringer, før du tilføjer noget nyt.

Følg pakken i den rækkefølge, den rejser

Når ruten findes, og forbindelsen stadig fejler, så gå vejen igennem i rækkefølge i stedet for at gætte på det øverste lag.

  1. Rute: et præfiks dækker destinationen og peger på et undernet tilknyttet endepunktet.
  2. Autorisation: en autorisationsregel tillader destinationen for brugerens gruppe. En rute alene giver aldrig adgang.
  3. Returvej: målundernettets rutetabel sender svar tilbage mod endepunktet, og sikkerhedsgruppen tillader porten fra klientens adressepulje.
  4. Applikation: åbn en rigtig TCP-forbindelse fra klienten, og bekræft derefter, at målets logfiler viser den forventede kildeadresse fra puljen.

Ændr ét præfiks pr. apply, læs ruttelisten igen bagefter, og notér destinationen, den autoriserende regel og returvejen sammen. Den næste, der fejlfinder en afvist forbindelse, bør starte fra den oversigt, ikke fra en certifikatteori.

Relaterede artikler